Tips for Creating Solid Test Designs
 
  July 2003 - Pragmatic Software Newsletters 
 
 
Reduce Software Defects by Creating Solid Test Designs
In this month's newsletter, we discuss tips for creating solid test designs. Standish Group research shows 52.7 percent of IT projects cost 189 percent of their original estimates.  A key component of reducing costs is to find defects before they make it to production, when the cost of fixing defects are much higher.  This newsletter will aid you in creating solid test designs as to reduce time and cost overruns.
 

Newsletter Sponsored by Software Planner

This newsletter is sponsored by Software Planner: http://www.SoftwarePlanner.com

Software Planner is a project collaboration tool that allows you to manage all phases of your software development. In the initial stages of the project, it allows you to post functional specifications and post project related documents (like meeting minutes, client proposals, etc.). As the project progresses, it allows you to post baseline documents (like detailed designs and project plans). As development proceeds, it allows your project managers and developers to track project deliverables.

The developers can update the percentage complete for all items assigned to them. Once testing begins, it allows your testers to create test cases and track software defects. Developers are automatically alerted, by email, as defects are assigned to them. Team members are alerted as new documents are uploaded or re-uploaded (like project plan updates, etc.). And each person has the ability to control the email alerts they wish to receive. Use the discussion forums to communicate all issues with clients and project team members. Keep your appointments and to do list on-line and updated at all times. Try Software Planner FREE for 2 weeks.

 

Tips for Creating Solid Test Designs

To deliver software on-time and on-budget, project managers must be able to understand the testing effort to adequately estimate the project.   Once solid customer requirements have been created (see our prior newsletter for tips on collecting solid requirements) and a solid detail design has been done (see last month's newsletter for tips on creating solid detail designs), the test team leader should create a test plan that explains the testing strategy.  The most reliable way to do this is to create a "Test Design" document. 

The test design document allows your testing team to thoroughly think through the testing approach, and to determine the effort involved in providing adequate test coverage for each functional specification item.   Below are the keys to successfully creating test designs (see next section for a template to get you started):

  1. Specify background information - Gives the tester a brief background of the project so that they can understand more about why the project is being undertaken.  This will help as you bring new testers to the team during the testing phase, allowing you to communicate a consistent message and decreasing the amount of time it takes to get the tester started. 
  2. Specify Code Freeze Date - Many projects have cost overruns because of "gold plating".  Gold plating is when project managers allow customers and programmers to continue adding bells and whistles to the software that are outside of the project scope.  At first they seem innocent, under the guise of making the product more robust.  Many seem to take only a few hours, but it has a ripple effect on the project because it affects your test plans, documentation, release requirements, support requirements, and many other things.  The best way to prevent this is for the project manager and testing team to hold the customers and programmers to the specification and enforce a date in which no new programming is done.  That date is the "code freeze date" and after that point, only defect repair is done.  Without a code freeze date, the testing team is testing a product that is in constant change.
  3. Create a Test Case Matrix - This is a traceability matrix that ensures that you have adequate test coverage of the functional specifications.  To create the matrix, simply list each functional specification and then list all test cases you have created for each functional specification item.  Once this is created, you can easily determine if you have enough test coverage for each functional specification item.  Many times you will discover that you missed some functional specification items or did not have enough test cases for a specific area.
  4. Specify Features Excluded from Testing - Just as important as the items you will test, it is wise to list what features will not be tested as to ensure that everyone agrees with this.  For example, you may be planning to test the software with Internet Explorer 6.0 and Netscape 6.0.  If this is not specified, your project manager may expect you to test with all versions of IE and Netscape, increasing your testing effort significantly, as this will cause you to build additional test machines with those versions.  Having this specified in your test plan will reduce the chance of these cost and effort overruns.
  5. Specify Release Criteria - The "Release Criteria" describes the procedures for allowing the project to enter the production phase.  It specifies:
    A) Smoke test criteria -  The "smoke test" is a series of standard test cases that your testing team runs when a new build is created, used to ensure that the release is solid enough to begin testing.  If any of those test cases fail, the build is sent back to the programmers for repair before major testing begins. 
    B) User acceptance test criteria - This specifies the criteria for moving the code to an area in which your users can test it.  For example, you may specify that all severity 1 or 2 defects must be fixed before moving it to user acceptance testing.
    C) Release to Production Criteria - This specifies your criteria for ensuring that the code is production ready.
  6. Break the Test Design into Tasks and Provide Estimates - As the test leader specifies the test design, a list of tasks that must be performed to complete each test function must be identified, along with an estimate of how long (in hours) each task will take to complete.
  7. Have a Team Design Review - Once the test design is complete, have the testing team review the design (and estimates) to ensure that the tester covered all the bases.  Many times these design reviews bring up ideas that allow you to reduce the effort and increase testing coverage with minimal effort. 
  8. Get Test Lead and Project Manager Signoff - Have your test lead and project manager sign the test design document so that you can later refer back to it, showing that both parties agree to the approach.

As you can see, creating solid test designs can ensure that your projects are delivered on-time and on-budget, allowing your project manager to document the tasks needed to test each customer requirement.  Below are some helpful templates to aid you in developing software solutions on-time and on-budget:


 

Pragmatic Software Co., Inc.
383 Inverness Parkway
Suite 280
Englewood, CO 80112

 

Phone: 303.768.7480
Fax: 303.768.7481
Web site:
http://www.pragmaticsw.com
E-mail:
info@pragmaticsw.com