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