2. Approach
When the team locks in the high-level and more generic parts of the plan, the next step is to get closer to the project at hand and to find answers to questions such as:
- How do I go about breaking this project down into more manageable components?
- What types of testing do I want carried out and at what stages of the SDLC?
- What types of documentation do I need?
- How often do we plan to release?/Are the milestones in place?
- Do I plan to automate, if so, when?
Getting these answers can be time consuming and this is where it pays to have testers with the right "people skills." Test leads and their groups need to reach out to Business Analysts, Development Mangers, Release Managers, and Project Managers to get development timelines, release structures, dependencies and milestones which will eventually help in creating the right testing process. In the end, the team should have a fair idea of the requirements and the effort needed for testing them. Again, it is always advisable to put in a "buffer" or a contingency factor in to the Level of Effort (LOE) calculations.
Another aspect that should be formalized and finalized are the types of testing that will be carried out. Typically, the types of testing, in sequence, would include:
- Unit Testing
- Integration Testing
- System Testing
- User Acceptance Testing
The need for further details on each testing piece is not required since the extent, usage, and form of each type varies from company to company and industry to industry. Then there is also the concept of blackbox, greybox, and whitebox testing which help define how technical the testing is going to be. It's common to have more ground-level testing as development begins and tend become more high level (or scenario specific) as teams move towards the software deployment date. If a team does plan to use specific tools to carry out testing, this is a good time to lay them out and make those critical decisions regarding which tool is the right one for application needs. This process can be shortened as well provided a testing team has the right combination of experiences with various tools. One thing to always remember no matter what is to start small, experiment with the chosen tool, play with a demo license if unsure, before choosing it for the entire project.
Lastly, the team leader needs to work towards creating a Work Breakdown Structure (also referred to as "WBS" or "Testing Project Plan") that maps the resources and the types of testing being done to the release milestones. In this step, project managers need to make sure that the timeline is feasible, ultimately approving, changing or rejecting the timeline depending on their experiences in the past. When finalizing the plan, don't forget to state the potential risks involved. It is the responsibility of the team lead or QA manager to define the testing windows and ensure adequate amount of time is allocated for testing. This may also involve explaining and disseminating information to Senior Management. Make sure that the entire team keeps all thoughts straight and facts handy.
This is also the right stage to formulate what the final testing sign off would constitute and the final sign off dates. Most importantly, all of this should be made available to the entire Project team and approval should be obtained from key players.
