Testing is often looked upon by many as an unmanageable, unpredictable, unorganized practice with little structure. It is common to hear questions or complaints from development including:
- What are test teams doing?
- Testing takes too long
- Testers have negative attitudes
Testers know that these complaints and questions are often unfair and untrue. Setting aside the development/testing debate, there can always be room for improvement. The first step in improving strategy and turning a test team into a higher performance test team is getting a grasp on where you are now. You want to address the following:
- What type of testing is effective?
- Are we testing the right things at the right time?
- Do we need a staffing upgrade?
- What training does our team need?
How does the product team value the test effort?
In this article, we provide a framework for assessing your team: planning your assessment, executing the assessment and judging your current performance, using the information, and charting an improvement plan towards higher performance.
The Test Process Assessment
The goal of doing a test process assessment is to get a clear picture of what is going on in testing: the positive aspects, the problems, and the possible paths to improvement. Fundamentally, a test assessment is a data gathering process. To make effective decisions we need data about the current test process. If done properly, the assessment will probably cross many organizational and management boundaries.
It is important to note when embarking upon such an assessment that this effort is much larger than the test team alone. Issues will arise over who owns quality as well as what is the goal of testing? It is also important to note that a possible result of the assessment is that work may actually increase. Some issues that may arise are:
- More demands for documentation
- More metrics
- More responsibility for communication and visibility into testing.
For such an assessment process to succeed requires:
- Executive sponsorship
- A measurement program
- Tools to support change
- An acceptance of some level of risk
- Avoidance of blaming testing for project-wide failures
- Commitment about the goal of testing
- An understanding of testing or quality assurance across the product team
- Responsibility for quality
Components of a Test Strategy – SP3
A test strategy has three components that need to work together to produce an effective test effort. We developed a model called SP3, based on a framework developed by Mitchell Levy of the Value Framework Institute. The strategies (S) components consist of:
- People (P1) – everyone on your team
- Process (P2) – the software development and test process
- Practice (P3) – the methods and tools your team employs to accomplish the testing task
Phase 1: Pre-Assessment Planning
The goals for this phase are to set expectations, plan the project, set a timeline, and obtain executive sponsorship. The actions that occur in phase one include meeting with the management of various groups, laying out expectations for the results of the process, describing the plan, and establishing a timeline.
The intended result is to obtain agreement on expectations and buy-in on the assessment process and the follow-up commitment for improvement. The phase one deliverable is a schedule and a project plan. It is important at this stage to:
- Get executive buy-in
- Create a schedule and adhere to it
- Give a presentation of your plans discussing the objectives
- State goals or outline work as a commitment
- Make a scope document a pre-approval/budget deliverable
It is important to note up front that assessment is only the beginning of the process.
Phase 2: Information Gathering
The goal of phase two is to develop interview questions and surveys which become the backbone of your findings. Actions in phase two include gathering documentation, developing interview questions, and developing a test team survey.
The result of this phase is that you will be ready to begin your assessment of the materials.
Examples of the documentation to be collected include: SDLC, engineering requirements, and testing documents (e.g. test plan templates and examples, test case templates and examples, status reports, and test summary reports).
Interview questions need to cover a wide range of issues including (but not limited to): the development process, test process, requirements, change control, automation, tool use, developer unit testing, opinions about the test team from other groups, expectation of the test effort, political problems, communication issues, and more.
Phase 3: Assessment
The goal of phase three is to conduct the interviews and develop preliminary findings. Actions include gathering and reviewing documentation, conducting interviews, and distribution and collection of surveys. As a result of this phase there will be a significant amount of material and information for review.
Phase 4: Post-Assessment
Synthesize all information into a list of findings in phase four. Actions include reviewing, collating, analyzing, and making postulations. The result of this phase is that you will develop a list of findings from all of the gathered information, reviewed documentation, interviews, and the survey. Phase four deliverable is a package of collated survey answers, interview responses, a staff assessment, and a test group maturity ranking.
The findings can be categorized into:
- People
- Technical skills
- Interpersonal skills
- Process
- Documentation
- Test process
- SDLC
- Practice
- Strategy
- Automation
- Environment
- Tools
More subcategories may also be developed to suit your needs.
Phase 5: Presentation of Findings with Project Sponsor, Executive Sponsor and Team
Phase five presents preliminary findings to executives and the project sponsor, and to obtain agreement on the highest priority improvement areas.
It is important in this phase to be prepared for a very different interpretation of the findings than you perceived. The deliverable for phase five is an improvement roadmap.
Phase 6: Implementation of Roadmap
Phase six establishes goals with timelines and milestones and sub tasks to accomplish the tasks agreed upon for improvement. The action of phase six is to develop a schedule for implementation of the improvement plan.
It is helpful at this point to get some aspect of the project implemented immediately so people can see tangible results right away─even if they are the smallest or easiest improvement tasks. The deliverable for phase six is implementation of items in the roadmap according to the developed schedule.
Phase 7: Is it different for Agile?
Yes.
Process improvement is built into most agile processes. Scrum, for example, has sprint retrospectives. If you are not doing sprint retrospectives, you are not doing Scrum. This practice serves to foster very regular self-examination to quickly fail and immediately fix any efficiency. Remember the Scrum Master’s primary objective is removing obstacles from people’s work.
An Agile approach to product development relies on self-forming teams, always optimizing a dynamic process.
With a regular and quick process improvement built into most agile practices, large scale assessment and improvement processes do happen, however less frequently than in traditional projects. The new name for a “process consultant” is a scrum coach.
Conclusion
A test strategy is a holistic plan that starts with a clear understanding of the core objective of testing, from which we derive a structure for testing by selecting from many testing styles and approaches available to help us meet our objectives.
Performing an assessment helps to provide “clear comprehension” and “understanding of the core objective of testing.” Implementing the resulting roadmap for improvement can help to substantially improve the performance of your software testing organization and help to solidify your test strategy.
