Your SlideShare is downloading. ×
Heuristic Test Strategy Model For "Soda Co"
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Heuristic Test Strategy Model For "Soda Co"

679

Published on

Heuristic Test Strategy Model for Custom Software Development Project: …

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). "

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
679
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Project Environment:Stakeholders:Company Head - wants the process more automated to save time and spoilageSoda Making Division - they would want to be notified if any particular flavor/brand is low so that theycould either make more or import more from another warehouse. They will be responsible for inventorycontrol 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 forwhere 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 pickup 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 torun, control access, stable and data will not be destroyedCustomer Service - they may be tasked with verifying orders, ensuring that enough product is on hand inthe 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 withone 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 theonly testing that has been done. Additional testing should have been completed by the developers inthe guise of unit tests, and possibly other testers. We are most concerned with meeting the specifics ofthe 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 Pathtests.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 theexisting 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 fullHappy 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 completedDeliverables:A test report with supporting documentation will be supplied to the customer. We aim to deliver thefollowing 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 ElementsStructure:Interfaces to the legacy data systems will need to be created to allow for data retrieval and data updateCode will be handled according to the contract and it will be the responsibility of the development teamhow it is delivered.Functions:Users must be able to import data from legacy databases to populate the requested spreadsheetDepending 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 dataUpdate existing legacy database with changes as dicated by the billing departmentBusiness rules implemented based on clients requestData:Data from legacy systems as inputData saved back to legacy systems to update or create new recordsData formatted in spreadsheetPlatform: • Legacy databases • Existing computer systems • Exiting PrintersOperations:Users: See section on StakeholdersEnvironment will be from standard office to warehouseCommon use will include import of existing data to a spreadsheet format for review, updating andprintingExtreme use will include the typical business fluctuations around holidays and specific seasons whichrequire heavier use of the system than normal.Time:
  • 4. Data must be immediately available as it will change frequently throughout the business andmanufacturing day Quality CriteriaCapability:All functions availableMultiple functions perform at the same timeReliability:Data verification for numerics to prevent invalid data in data fieldsError handling to prevent invalid actionsData masking to ensure incoming data and outgoing dataStress testing to ensure software operates with peak + loadsUsability:Preformatted spreadsheets available for widely used functionsCustom spreadsheet options for select usersView ability for select usersEdit ability for select usersPrint ability for all usersSecurity:Since data is being stored in existing legacy databases, additional data security will be built around userpermissions.User authentication will be required for any level of useOnly Administrators will have ability to create usersScalability:System must perform well under standard use and peak useMust be portable to allow new currently undefined users to be addedTest to account for the possibility of X additional users, based on growth
  • 5. Performance:All data must be accessible with X secondsInstallability:Requires access to networkPrinting may require specific hardwareNo additional hardware requiredCompatibility:Software must work with specified operating systemDoes not require backwards compatibility Test TechniquesThe following testing techniques will be used to test the spreadsheet features and integration with thelegacy system:Function Testing: spreadsheet inputs, format, data inputs/outputsDomain Testing:Scenario Testing: data processed by the spreadsheet. Read and write to the legacy systemAutomated Testing- automate part of the testing to run various edge case scenarios to test the inputs tonumeric fieldUser Testing: To run user defined test cases that are important

×