Your SlideShare is downloading. ×
Test plan
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

Test plan


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. How to Write a Test Plan? A Case Study 1
  • 2. What Must be Included? Goal Introduction ScopeTest SpecTest Spec Test Plan Unit Test Integration Test Validation Test High-Order Test Test Procedure 2
  • 3. 3
  • 4. 4
  • 5. 5
  • 6. 6
  • 7. 7
  • 8. Case StudyWMITS (Waste Management Inspection Tracking (System) Software RequirementsSpecifications1.1 Goals and ObjectivesThe main purpose of WMITS is to helpautomate the entire process that theDepartment of Environmental Quality (DEQ)Waste Management Division (WMD) staffmembers perform throughout an inspection. 8
  • 9. The goals of WMITS are:· To minimize the time span of any inspection· To minimize the amount of paper workrequired· To provide a searchable database of allpast inspections· To provide an automated channel for thepublic to request information (under Freedomof Information Act) 9
  • 10. System ContextEventually, multiple users will be using the productsimultaneously. Therefore, concurrent connection willbe an issue for implementation. In addition, this is apilot product that hopefully, if successful, can be usedin other locations as well. This leads to issues aboutfuture support for a larger user base. 10
  • 11. 1.0 IntroductionThis section gives a general overview of the TestSpecification for the Waste ManagementInspection Tracking System (WMITS). 11
  • 12. 1.1 Goals and ObjectsPut it in a simple way, a good product will be workperfectly, doing the right thing at the right time. To dothat, the software has to go through a series of testsbefore its final release. Error free software isextremely difficult to achieve. After all, nothing isperfect. Especially for software developed in a shorttime frame. But high quality can be achieved with adetailed test specification. All (or least most) of thetest case will be listed, the development team willfollow it step by step, item by item, to test all thenecessary objects, data flows, limits, boundaries, andconstraints of the software. 12
  • 13. 1.1 Goals and ObjectsCyber Rovers would like to have a test specification tocounter any difficulties that may impact thedevelopment and the future performance of thesoftware. The team’s goal is to assist the projectteam in developing a strategy to deal with anyerrors. For this, the team will take a look at the mostcommon errors to some very uncommon errors aswell. 13
  • 14. 1.3 Major ConstraintsIn this section we will talk about the business,technical or resource related constraint thatmay keep us from performing all testsnecessary.1. The team has limitation on time to testthe product at the client’s facility. We haveaccess to the facility only during the regularoffice hours. We also have to set us schedulearound the available time of the inspectorthat is to help us, so time schedule will be amajor constraint when we talk about testingat the site. 14
  • 15. 1.3 Major Constraints2. The team also has got funding for onlyone hand held PC. This means that wecannot test the software using the PC fromsome other brand or PC that is of lesser priceand lower hardware.3. The team does not know any hacker thatcan help us test the security problems. So wehave to rely on our own knowledge andhave to trust the software for the security. 15
  • 16. 1.3 Major Constraints4. The team also does not have largeenough group to have many people use theapplications at the same time to perform realstress related testing. So we have will not beable to test the product for the larger userbase.Critique: Each of these constraints represents asignificant product quality risk. .The team shouldconsider risk mitigation strategies. 16
  • 17. 2.0 Testing PlanWe want the product to be bug free. We alsowant to make sure that there are no defectsin the product. So we will be spending largeamount of the total software developmenttime on the testing. Below is the descriptionof the testing procedure and strategy. We willalso be presenting the timing and scheduledof the tests to be carried out. 2.1 Software to be tested 17
  • 18. 2.1.1 InterfacesLogin WindowWe will make use of several different names to log into the system, so will be testing login window. Wewill also test OK and Cancel buttons on this windowby performing test above.DEQ – Microsoft Visual Basic [Design] WindowThis is the main window that we will use to access the databaseusing Visual Basic. We will have several different drop-downmenus in this window. File, Facility, Inspection, approve,Reports, Maintenance and Help are the drop down menu that willbe available in this window we will try to use all the menus andthan different options available in each of the window. 18
  • 19. 2.2 Testing StrategyIn the following section we will describe thetesting strategy. We will user four differentmethods to test our product. 19
  • 20. 2.2.1 Unit TestingIn the unit test case we will be testing theseparate modules of the software. We willcarry out white box testing where eachmodule or component of the software istested individually. We will test thecomponents by passing data through it andwe will be monitoring data to find the errors. We will be looking for entry and exit conditionsof the data. We will make sure that all the componentswork without any troubles. The test primarily becarried out by the programmer who designed andimplemented the module. Lead tester will than carryout test on the modules to finalise the testing. 20
  • 21. 2.2.2 Integration TestingIn this method of testing we will implementthe software at the clients location and willrun it. So we will be testing the product onclients network. As part of testing, will belooking for any signs of the collision betweenour software components and those of theclients. We want to make sure there is noconfusion among the application on thenetwork when they are runningsimultaneously. 21
  • 22. 2.2.2 Integration TestingWe will install the software at the clentes siteand will run it. We will have several differentother applications open as well. Thisapplications will be the once that have tointeract with our software on normal bases.We will make sure that all the data is savedcorrectly and there is no loss of data or database anomalies in the product.We will start from the login window and willgo through all the all the software functionsand will test the. We will be carefully lookingfor any sort of collision between severaldifferent applications 22
  • 23. 2.2.3 Validation TestingIn this method of the test we will be working with thecustomer to find out if the software developed in validfor the clients. We want to make sure that the client isgetting what he asked for. We will look at the softwarerequirement document in the case of conflict ormisunderstanding with client regarding softwarecomponents.We will perform the black box testing where thesoftware is completed and we test all the softwarecomponents together. We will have several input dataor test data that we will derive results for. We will insertthis data in the software and will get results form thesoftware. We will compare the results from thesoftware with the results that we derived. This way willcheck for the validation of the software. 23
  • 24. 2.2.3 Validation TestingIn case there are problems with the softwarewe will create a deficiency list and willrecord all the problems in there. We will testall the components and subcomponents ofthe software to perform validation test.We have and will try our best so that we don’thave to create deficiency list. This isnecessary because if the errors are found atthis stage of the software development wecannot fix them by the time we reach thesoftware deliverance date. In this case wehave to negotiate with the customer to giveus extension on the project. 24
  • 25. 2.2.4 High-order TestingIn this test method we will combine severaldifferent other types of the testing. We will test forseveral different conditions by following severaldifferent test methods.• Recovery testing Here we are concerned with ability of the software to retrieve lost data. We want to make sure that the software is fault tolerance and does not loose data in case of system shutdown or if the system ceases. 25
  • 26. 2.2.4 High-order Testing• Security Testing In this method of the test we want to make sure that the security checks are working and no one is able to temper with the data. This is crucial since our software is design to track the activity that is not legal.• Stress Testing In this test method we want to monitor stress caused to system and the software due to simultaneous use. We want to make sure that the system does not breack down under the extreme use conditions.• Performance Testing Performance bounds are set during the design part of the software development. These bounds will help us in determining the effectiveness of the software. It will also help us to minimize stress level that is caused to user because of our software. 26
  • 27. 2.6 Test ScheduleFollowing is the tentative schedule for the testingof the WMITS.Project Test Plan–2/9/2000 – 2/15/2000This part is straightly theory stage. No any real actionswill be performing.System Testing–3/6/2000 – 3/10/2000Generate Testing Report–3/7/2000 – 4/7/2000 27
  • 28. 1.3 Testing Resources and Staffing We need to have large number of resources available to us in order for us to test the entire software properly. We will use help form several different people to be able to Resources We will take help of the DEQ staff of the Waste Management Devision to help us test the product. We are to allow DEQ staff member or members to test the product as part of validation testing. We will have the DEQ staff record any errors found in the software and will correct them before the delivery of the software. 28
  • 29. Bug Resource ReportsWe will use Bug Resource Report where wewill identify the bugs found during the testingand will try to identify the reasons for theiroccurrence. This will help teams that maywork on the product latter to identify the softspots for the bugs and will help them tocome up with way to design products so thatbugs are avoided. 29
  • 30. StaffingWe have decided to use simple method forstaffing people for the testing. Each programwill test the components or functions createdby him separately and will hand them over tolead tester. Lead tester will test eachcomponent and will make a note of theresult in test result table. Once the product iscompletely developed we all the member ofthe software project team will test thesoftware with combined effort. DEQ staff willalso assist in testing the software. 30
  • 31. 1.3 Test Record Keeping and Log We will use table created in excel to log all the test, describe them and to record the results of the tests. Below is the example of such table. The table will also be out test work product. 31
  • 32. 32