Pin Me

Work Breakdown Structure (WBS) of Software Testing

written by: The Enterprising PM • edited by: Ginny Edwards • updated: 11/30/2010

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.

  • slide 1 of 5

    Introduction to Work Breakdown Structure Software Testing

    Work Breakdown Structure of 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.

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

    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

  • slide 3 of 5

    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)

  • 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!

    The Enterprising PM

    Image Credit: Francesco Marino / FreeDigitalPhotos.net