WHOLE TEAM APPROACH
Pattern summary
Testers, coders and other roles work together on one team to develop test automation along with production code.
Category
Process
Context
This pattern is most appropriate in agile development, but is effective in many other contexts as well. This pattern is not appropriate if your team consists of just you.
Description
Everyone collaborates to do test automation. Developers build unit test automation along with production code. Testers know what tests to specify, automators or coders help to write maintainable automated tests. Other roles on the team also contribute, eg, DBAs, system administrators.
Implementation
If you are doing agile development, you should already have a whole-team approach in place for software development, testing and test automation.
If you are not doing agile, it is still very helpful to get a team together from a number of disciplines to work on the automation. In this way you will get the benefit of a wider pool of knowledge which will make the automation better, and you will also have people from different areas of the organisation who understand the automation.
Potential problems
If people are not working on the automation as a FULL TIME JOB, there may be problems as other priorities may take their time away from the automation effort.
Another possible problem occurs when many DevOps teams develop test automation independently (look up the issue LOCALISED REGIMES*)
Issues addressed by this pattern
HARD-TO-AUTOMATE RESULTS
HIGH ROI EXPECTATIONS
INADEQUATE COMMUNICATION
INADEQUATE TEAM
INCONSISTENT DATA
LATE TEST CASE DESIGN
NO INFO ON CHANGES
NO PREVIOUS TEST AUTOMATION
SCHEDULE SLIP
STALLED AUTOMATION
SUT REMAKE
TOO EARLY AUTOMATION
TOOL-DRIVEN AUTOMATION
UNAUTOMATABLE TEST CASES
UNFOCUSED AUTOMATION
UNMOTIVATED TEAM
Experiences:
Thanks to Lisa Crispin for suggesting this pattern!
Jochim Van Dorpe writes:
We use the 'whole team approach' since we've been put on an agile project.
The project team consists of 1 Project Lead (PL), 2 functional analysts, 1 java architect, 3 developers and 1 tester / test analyst / test coordinator.
Due to the two-week interval between sprints, I can't keep up with the pace of what the developers produce. So instead of automating all the tests cases myself, I shifted my work towards designing the high level test cases and reviewing the low level test cases which are written by the developers themselves (but reflect my high level test design).
* This problem has been pointed out by Vincent Wijnen
If you have also used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns