Documenting a Software Test Project

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.

    .