The Software Test Plan (STP) is the typical document that defines the life cycle of a software testing experience. It should include a description of the software application that is to be developed, the make-up of the teams that will be performing the testing and the location and schedule of the tests to be conducted. It should also contain a statement that it is a “living” document, one that is subject to change as the project evolves. A major portion of it should be a description of the chronology of events that will take place. In other words, the testing life cycle.
Stage 1: Analysis
In the early days, software testing typically began during the latter stages of the development life cycle. It didn’t take long to determine that this was much too late to start something as important as testing. Ideally, the development of the test plan should coincide with the planning stage of the software application itself. Test developers need to be included in the requirements analysis along with the code developers.
The end-goal of the testers’ analysis differs from the code developers’, however. Testers will be interpreting the requirements from an end-user’s point of view. The goal here is to establish techniques that will ensure the application achieves the purpose desired by the customer. Testers must keep in mind the users’ skill levels and the environment in which they will be utilizing the application.
Stage 2: Planning
Once the requirements are sufficiently understood, preliminary test planning can begin. At this stage, the tests will be fairly generic and possibly even somewhat vague. It must be kept in mind that requirements may change with time; this is known as “requirements creep” and, hopefully, will be kept as minimal as possible. The idea is to develop an overall strategy that can be modified and improved as the project progresses.
Testing concepts such as test data requirements (both quantity and quality), parametric limits (minimums and maximums) and “negative” test conditions should be considered. “Negative” testing involves determining that the application can detect and deal with information that is erroneous, duplicitous or outside established boundaries. The detection of required data that has been omitted also fits into this category.
Another important step that should be implemented at this level is the agreement to have an independent testing environment established at the proper time. Just as developers need a development system, testers need to have their own testing arrangement. Executing tests utilizing the same system in which development is occurring can cause many problems including project delays. It should be avoided at all costs.
Stage 3: Test Design
The design and development of test cases can now begin. The format of the test cases should be consistent. Each test case should be a separate document containing an introduction explaining what characteristic is being examined and the overall expected results. It should also include a listing of any needed prerequisites and assumptions (for example, the user has already logged in and navigated to the proper page). A reference section should list all of the project requirements that are being satisfied by the successful accomplishment of this test case.
The bulk of the test case will contain the actual test steps to be performed. Each test step should numbered and contain explicit instructions as to what action needs to occur. The expected results should be clearly defined. During the execution phase, space should also be included to record the actual results achieved.
Each test step should perform only one action that can achieve a specific result. Keeping it simple in this manner prevents having test steps that are long, convoluted and have the potential for partial failures, something that should be avoided if at all possible. For example, Test Step 1: turn on computer. Expected results: computer boots up. Actual results: as expected. Nothing else would be expected to occur during this test step.
Formalizing the procedure in this manner provides a documentation trail for the testing process and allows others to perform the tests without having to recreate the methodology needed. Customers also like to know the techniques used and the level of in-depth testing that has been accomplished.
Stage 4: Test Execution, Correction and Re-Testing
Once the code development has progressed to a sufficient state, test execution can begin. A system of risk evaluation should be in place. A high risk (typically, Level 1) is one that can prevent the application from functioning properly, Level 2 risks may require some sort of work-around to obtain the desired results. Levels 3 and 4 are progressively lower risks that should be fixed before delivery and Level 5 are usually cosmetic improvements.
During the early portion of this stage, communication between testers and developers can frequently solve problems quickly and informally. Frequent retesting may occur as corrections are made. As the test execution progresses, though, a more formal and well-documented system of defect recording should be implemented.
Stage 5: Test Reporting and Closure
When all formal testing has come to an end, a test report should be created recapping the entire testing process. It should include all the major difficulties that were encountered, defects that were discovered and corrected as well as those that continue to exist. An assessment of the level of risk involved in releasing the product should be thoroughly explained.
Other than providing a finalized test report, the test team may not be extensively involved with the customer acceptance but project managers usually want to keep them around to answer any testing questions that may arise.
Stage 6: Post Installation
Testing does not end with the delivery of the product. Unexpected fallouts may occur that had not been anticipated. Developers may make periodic updates which opens up a completely new bucket of worms. Now the tester is concerned not only with the successful installation of an improvement, but must also verify that nothing in the existing code was damaged in the upgrading process.
Of course, each project is unique and has specific needs all its own. What I have tried to present here is a summary, a starting point if you will, to give the reader an insight to the many possibilities and opportunities that awaits the diligent software tester.
Labyrinth image via Shutterstock
Bill HollandBachelor of Arts, Computer Information Systems Master of Science, Management of Technology Over thirty years experience in test engineering, both hardware and software Desigined automated test equipment from the ground up Taught Intro to Microcomputers at Northwest Vista Community College Enjoy programming as a hobby, keeping abreast of latest technology and amateur photography Avid reader and aspiring writer.
