Heuristic Test Strategy Model for Custom Software Development Project: "You have joined the development team in a company that is doing custom software development, writing this program to a specification that was negotiated and incorporated into the development contract. Your objective is to test the program in a way that lets you determine whether it will be acceptable to the customer (as indicated by conformity with the specification). "

1. Project Environment:
Stakeholders:
Company Head - wants the process more automated to save time and spoilage
Soda Making Division - they would want to be notified if any particular flavor/brand is low so that they
could either make more or import more from another warehouse. They will be responsible for inventory
control as well and could be a big spread sheet user.
Billing Department - they are going to need to bill out any product leaving the warehouse or account for
where it is going. I expect these will be our spread sheet users more than the others.
Delivery Drivers - they are going to want to know that their orders will be filled and that they can pick
up orders from the warehouse when they are ready.
IT Department - the person in charge of running the software will want to make sure that it is easy to
run, control access, stable and data will not be destroyed
Customer Service - they may be tasked with verifying orders, ensuring that enough product is on hand in
the case of special/rush orders and tracking any service or delivery issues including spoilage or recalls.
Information:
We will need to understand the data set up of the underlying system. This could mean interaction with
one or more legacy systems.
Test Team:
As we are doing customer acceptance testing, or our internal version of it, we expect that this is not the
only testing that has been done. Additional testing should have been completed by the developers in
the guise of unit tests, and possibly other testers. We are most concerned with meeting the specifics of
the contract, as it is written.
Equipment and Tools:
A test list containing the requirements as set forth in the contract will be used to design Happy Path
tests.
Some automated software will be used to check the format of incoming and outgoing data.
We will require back ups of the existing database in use to simulate pulling data and updating data in the
existing system without impacting the system, since it is currently being used.
Schedule:

2. We have a reasonable amount of time to complete our testing, what we feel we will need to do full
Happy Path testing and some additional testing.
Test Items:
We will test the following items:
1. Incoming data from legacy database (to a reasonable degree, knowing that we cannot check
every field of every database.)
2. Data that is updated in the spreadsheet and then exported back to the legacy database. We will
test for location and data format to ensure we are not introducing any new issues.
• Database backups of legacy systems will be used for testing to simulate real life conditions
3. GUI testing will be completed
Deliverables:
A test report with supporting documentation will be supplied to the customer. We aim to deliver the
following documents in support of our testing.
• Spec for the spreadsheet program
• Test strategy
• Mindmap showing high level project view
• Test Report
• A report detailing how the specific requirements were met
• Existing anomalies of concern will be documented
Product Elements
Structure:
Interfaces to the legacy data systems will need to be created to allow for data retrieval and data update
Code will be handled according to the contract and it will be the responsibility of the development team
how it is delivered.
Functions:
Users must be able to import data from legacy databases to populate the requested spreadsheet
Depending on the requested use, different information could be produced for the base spreadsheet
• Delivery reports (for delivery and delivered)
• Products for delivery by warehouse

3. • In process reports showing what is getting completed and expected completion as well as
scheduled product
• Billing reports with edit abilities
• Location reports showing stored product
• Product reports showing all available product
• Warehouse reports showing current stock on hand
• Historical reports showing past sales of specific products
• Notification report for low/out of stock products
• Production and sales reports with current and historical data
Update existing legacy database with changes as dicated by the billing department
Business rules implemented based on clients request
Data:
Data from legacy systems as input
Data saved back to legacy systems to update or create new records
Data formatted in spreadsheet
Platform:
• Legacy databases
• Existing computer systems
• Exiting Printers
Operations:
Users: See section on Stakeholders
Environment will be from standard office to warehouse
Common use will include import of existing data to a spreadsheet format for review, updating and
printing
Extreme use will include the typical business fluctuations around holidays and specific seasons which
require heavier use of the system than normal.
Time:

4. Data must be immediately available as it will change frequently throughout the business and
manufacturing day
Quality Criteria
Capability:
All functions available
Multiple functions perform at the same time
Reliability:
Data verification for numerics to prevent invalid data in data fields
Error handling to prevent invalid actions
Data masking to ensure incoming data and outgoing data
Stress testing to ensure software operates with peak + loads
Usability:
Preformatted spreadsheets available for widely used functions
Custom spreadsheet options for select users
View ability for select users
Edit ability for select users
Print ability for all users
Security:
Since data is being stored in existing legacy databases, additional data security will be built around user
permissions.
User authentication will be required for any level of use
Only Administrators will have ability to create users
Scalability:
System must perform well under standard use and peak use
Must be portable to allow new currently undefined users to be added
Test to account for the possibility of X additional users, based on growth

5. Performance:
All data must be accessible with X seconds
Installability:
Requires access to network
Printing may require specific hardware
No additional hardware required
Compatibility:
Software must work with specified operating system
Does not require backwards compatibility
Test Techniques
The following testing techniques will be used to test the spreadsheet features and integration with the
legacy system:
Function Testing: spreadsheet inputs, format, data inputs/outputs
Domain Testing:
Scenario Testing: data processed by the spreadsheet. Read and write to the legacy system
Automated Testing- automate part of the testing to run various edge case scenarios to test the inputs to
numeric field
User Testing: To run user defined test cases that are important