Upload
vishalsuman4u
View
215
Download
0
Embed Size (px)
Citation preview
8/8/2019 Documenting a Software Test Project
1/3
Documenting your software test project
The test project is the technical effort of estimating work, planning the test scope and
strategy, effectively managing test execution, and reporting on status and risk. Everyproject involves tradeoffs between features, time, quality and costs. It's the test manager's
responsibility to manage the details of the test project by possibly providing informationto stakeholders in terms of project estimates for the amount of work required, actively
managing the test effort, and providing information about product quality. This tip
focuses on the documents that might help when managing the testing project.
In our webcast on "How to plan your software test project" we outline some common testplanning artifacts that one might find useful. These include the following:
Test strategy document
Test plan document Test estimates
Test project plan
Other documents based on your context
Test strategy document
We have used the test strategy document to define the strategic plan for what aspects of
the system we plan to test, our approach to testing, and to capture the details around
constraints, assumptions and risks for our testing.
The test strategy document might capture the following information:
Scope of the testing Quality criteria
Feature context
o Technical architecture
o Operating environment
o Interaction with other features and systems
o Other content items as appropriate to your project
Testing dependencies, assumptions and constraints
Testing objectives
Testing approacho
Types of testingo Testing methods and procedures
o Testing tools
o Test data
o Traceability
o Other content items as appropriate to your project
Deliverables
Resources
8/8/2019 Documenting a Software Test Project
2/3
Timelines
Risks and contingencies
As you develop the test strategy document, the creation of the document and workingthrough the process of gathering information can help you assess and determine the
strategy. The test strategy document can also be useful to convey the strategy tostakeholders to gain their agreement to your testing approach.
Test plan document
We use the test plan document to defines the goals and objectives of testing within the
scope of an iteration, or if the project is small, for the entire project. For smaller projects,
our test plan and strategy document may be the same document.
The test plan document might capture the following information:
Preparations
Staffing Test coverage
Any testing requirements (technical or otherwise)
Test environments
Entry criteria
Exit criteria
Delegation of responsibilities
Facility acquisition
Task planning
Scheduling Documentation on coordination and collaboration with other teams
Risks and issues that may impact testing Specific deliverables of the test project
The purpose is to outline and communicate the details of the testing effort for a specific
period of time. It can be used to direct and guide the test effort. It may or may not contain
the details found in the test project plan or test estimates (described below). Whether or
not those documents are separate or contained under the plan again depends on the size ofthe project and the context in which we are working.
Test estimates and detailed plans
We sometimes find we need to do formal estimating when we plan our projects. To do
this, we like to use bottom-up estimation. Working backwards from our test objectives,we can define all the tasks necessary to complete the objective. When finished, we have a
work breakdown structure defined for many of our objectives. We can then take the
various work breakdown structures and estimate the work for each of the tasks.
Once we have the estimates for the work, we lay out those estimates against a high-level
schedule to understand what our resource needs are going to be. At the end of this
8/8/2019 Documenting a Software Test Project
3/3
process we have estimates in terms of work effort (hours, days, etc.) and resources (a
number of people for a period of time).
Depending on the project, this information might be transferred into a formal project plan(most likely using Microsoft Project). This allows us to integrate the various work
breakdown structures, consolidate the estimates, assign the resources planned and trackthe changes to the plan over time as the project unfolds. Maintaining a project plan
always has the potential to be a distraction, so be sure that you need that kind of formalityor that you truly find it helpful before you make the investment.
Other documents based on your context
Depending on the context you're working in, there might be other documents you need or
want to produce. These can include models, lists, checklists, standards, templates, processdocuments, charters or contracts. For a specific example, Mike once included a site map
for a Web site as part of his test planning documents, including details around each of the
pages.
There's really no limit to what might be helpful when planning your project. From a
documentation perspective, we suggest finding a balance between what's required, what's
helpful in driving your understanding of the work, and what's helpful in communicating
the testing to the various stakeholders on the project.
.