Work Breakdown Structure for Software Testing

Introduction to Work Breakdown Structure Software Testing

In the PMI world, the processes (or phases) of a project are: Initiating, Planning, Executing, Monitoring and Controlling and Closing. In software development, QA can contribute to high level risks list during Initiating, as do all stakeholders, but their real work begins during the Planning process. Regardless of the software development lifecycle (SDLC) in use, from Agile to Waterfall, QA’s efforts will correspond to Development plans and will need to be sequenced based upon your chosen approach.

Planning: Requirements (Product Development Specification)

QA, along with the rest of the team, must review and provide feedback while the product is being identified. Everyone has a responsibility to ensure the product is viable in the marketplace. The same is true for design specs and functional specs. Repeat the review cycles as many times as needed.

WBS:

Planning

Product Management:

Write Requirements Draft 1(Prod. Mgr)

Review and update PRD Draft 1 (QA, DEV….ALL)

Write Requirements Draft 2….etc.

Requirements Approved Milestone

Development:

Write Software Design Spec. Draft 1 (DEV)

Review and Update SDS Draft 1 (QA, others)

SDS Approved

Write Software Requirements Spec (SRS) /Functional Spec (FS), Draft 1 (DEV)

Review and update SRS/FS Draft 1 (QA, others)

FS Approved

QA WBS

As the SRS / Functional spec. begins to stabilize, usually post Draft 2, QA then produces work while other become the reviewers.

QA

Write Test and Configuration Management Draft 1

(this document identifies primary test equipment setups, specifies resources,determines how progress will be reported, links to other QA docs such as glossary, automation plans, work flow, etc)

Review Test and Configuration Management Draft 1 (DEV, Prod Mgr, Corp Quality, others)

Design New Test Cases (Cycle 1)

Review New Test Cases (DEV, others)

Update Test Cases (QA)

Review and Update Existing Test Cases (QA)

Test Case Design Complete Milestone

Create Planned Testing

(select test cases and corresponding setups assigned to testers) — this is your ‘Planned Testing" (not to be confused with Test Plan which depicts all possible testing) and we’ll just call them Test Sets for ease of reference. This is your based line for planned vs. actual metrics.

Test Set 1:

Test Set 2:….etc.

Planned Testing Approved

Write Automation Spec. Draft 1 (QA)

(this document identifies how testing will be automated – what framework will be used, what scripting language, where repository will reside, what hardware setups will be used, how where and when results get reported etc.

While QA is doing this work, Development is off coding, creating unit tests, and creating a build schedule that shows what will be delivered when, up through Functional Complete (all new functionality coded)

QA Execution

Once builds are forthcoming, QA enters into the execution phase and begins to expose all tests at least once. Test Sets are simply test cases tied to their respective hardware setup. The Execution WBS looks like this:

Execution:

Build 1:

Test Set 1:

Test Set 2:

Test Set 3:

Build 2

Test Set 4

Test Set 5

First Pass Complete Milestone

Regression Testing

Golden Run

Testing Complete

….until all test cases for that build are run. Repeat the cycle as needed for each subsequent build until all tests have been run. Following Functional Complete by DEV and all tests exposed once by QA, the team together enters into the Code Complete phase where bug fixes for failed tests are implemented and retested. Then Code Freeze where no new code can be implemented without buddy checks to ensure no regressions. QA then executes ’the golden run’….on gold bits (final build).

Conclusion

QA has as important a role as development in producing work. If your QA team is taking a passive approach and only inspecting what’s thrown over the wall, then there’s no way to really tell how their efforts are improving over time or how the coding and/or product are improving. Take time to plan out testing and use or modify the above steps to create your own QA WBS. Don’t forget to add a Closing Phase with a task for creating a Lessons Learned document. Remember, anyone can be an enterprising PM!

The Enterprising PM

Image Credit: Francesco Marino / FreeDigitalPhotos.net