Organizations concern themselves with development activities in minutia yet for some reason fail to demand equally detailed planning from Quality Assurance. The following article details the work breakdown structure of software testing, including discrete deliverables that make up the SQA WBS.

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.

slide 2 of 5

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.

(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)

slide 4 of 5

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

slide 5 of 5

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!