Last month, we focused on the Design
Phase, specifically Detailed Designs. This month,
we will continue our focus on the
Design
Phase,
the second phase of the Iterative Software Lifecycle.
Since the design phase has many deliverables, we will focus
this month on the test design deliverables. In the
coming months, we will explain the other deliverables of the
Design Phase as well as the remaining phases of the Iterative
Software Lifecycle and provide you with step-by-step
instructions on implementing it. To see newsletters from
prior months, click here.
This newsletter is
sponsored by Software Planner (http://www.SoftwarePlanner.com).
Design
Phase
The Design Phase is used to determine the
technical solution and to provide preliminary estimates for
delivering the solution. For the project manager to
provide correct estimates, the development team must spend
time architecting a technical solution that meet the demands
of the functional specification. Additionally, the
testing team must develop a Master Test Plan as to allow them
to estimate their effort.
Upon completion of this
phase, a project plan may be developed which details the
costs, effort and timeframes in which the solution may be
delivered. As a final step, the client may decide to
add, omit or delay functionality to fit within their timeframe
and budget.
Deliverables
Below
are the deliverables for the Planning Phase:
Since we discussed the Detailed Design last
month, this month we will discuss the Test
Design. In coming months, we will explain the other
deliverables in detail.
Test Design
Document
Once all the functional specification items
have been defined and a Detailed Design has been created, it
is imperative to understand the effort needed to test the
application. The most reliable way to do this is to
create a "Test Design".
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. The
test design document should contain the following sections
(you may consider skipping some of these sections for smaller
projects):
-
Introduction - The
introduction should explain a why you are testing
the product including with these items:
1.
Background – Gives the tester a brief background on the
project so that they can understand more about why the
project is being undertaken.
2. References –
Lists the major reference materials you used when creating
the plan. This could be books on testing, company
standards, or any other reference material that may be
pertinent for the tester to use when testing the
product.
3. Code Freeze Date – This specifies
the production code freeze date. This is important to
know because it can affect your regression test
plans.
4. Change Control - This details the
change control procedures that are followed for changes to
the functional specification
items.
Items to be Tested -
This section identifies not only the items to be tested, but
also the level of testing in different functional
areas. It includes the following sections:
1.
Level of Testing - This section contains the desired
level of testing (high, medium, low) for each type of
testing activity. Some clients may want all of these
items tested while others may only want a select few of
these items tested, and in different degrees. Testing
activities may include:
* Performance
Testing
* Windows/Internet GUI
Standards
* Platform
Testing
* Localization
Testing
* Stress
Testing
* Conversion
Testing
* Parallel
Testing
* Regression
Testing
* Automated
Testing
* Installation
Testing
* End-to-End / Interface
Testing
* Usability
Testing
* User Guide
Testing
* Guerilla
Testing
* Security
Testing
* Network
Testing
* Hardware
Testing
* Temporal
Testing
* Disaster Recovery
Testing
* Input/Boundary
Testing
* Out of Memory
Testing
2. Features to be Tested - This is a
list of functional specifications that will be
tested.
3. Test Case Matrix - This is a
traceability matrix that ensures that you have adequate test
coverage of the functional specifications. It lists
each functional specification and the associated test
cases.
4. 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.
Testing Approach -
This section defines the overall testing strategy and
iterates the deliverables for each phase of the
project. It also specifies the tools that you plan to
use for defect tracking and issue management.
Release Criteria -
This section describes the procedures for allowing the
project to enter the production phase. It
contains:
1. Test Case Pass/Fail Criteria - It
is important that the development team understand what
causes a test case to pass or fail. The criteria is
listed here.
2. Suspension Criteria for failed
Smoke Test - It is wise to list what constitutes a good
build. There should be some simple criteria for
determining whether enough items are testable before you
begin a full scale testing effort, as to maximize the use of
the tester's time.
3. Resumption Requirements
- If the Smoke Test fails, you should specify the criteria
for resuming testing activities.
4. Release to
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 bugs must be fixed before moving it to user
acceptance testing.
5. Release to Production
Criteria - This specifies your criteria for ensuring
that the code is production ready.
Hardware - This
defines the hardware in which the testing will be performed
on. This includes your client and server
configurations.
Project Plan -
Defines the deliverables, budget and dates for the testing
activities.
Once you have defined the
items above, the testing team must estimate each item so that
you can get an idea of the cost of testing. Next month,
we will discuss the formulation of the object and data
models. Upon completion of the detailed design and test
plan, your project manager can estimate the other project
related activities so that you have a fully estimated
project.
Summary
During the Design Phase, the project manager
works with the development team to create detailed
designs. Detailed Designs explain the technical approach
and estimated effort for delivering each functional
specification item. Once this is done, the project manager
works with the testing team to create the Test Plan. The
Test Plan details the testing approach and estimated
effort. Once this is done, the project manager can fully
estimate the entire project.
Free
Templates
Click the
link below for some free templates to get you started with the
Iterative Software Lifecycle. These templates cover all areas
of the lifecycle, from the planning to production
phases. You will also find the test
design template at that site.
Templates for the Iterative Software
Lifecycle
Software
Planner
Software
Planner is a web-based software lifecycle management tool that
fully supports the Iterative Software Lifecycle. It
allows you to store test documents in a central location for
your entire team to review. To learn more about Software
Planner, click the link below.
Software
Planner