.................................................................................................................Home / Back to Process Patterns / Back to Test Automation Patterns
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 (SHARE INFORMATION) 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.

Issues addressed by this pattern
HARD-TO-AUTOMATE RESULTS
HIGH ROI EXPECTATIONS
INADEQUATE COMMUNICATION
INADEQUATE TEAM
INCONSISTENT DATA
LATE TEST CASE DESIGN
NO PREVIOUS TEST AUTOMATION
SCHEDULE SLIP
STALLED AUTOMATION
SUT REMAKE
TOO EARLY 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).


Note:
If you have also used this pattern, please add your name and a brief story of how you used this pattern: your context, what you did, and how well it worked - or how it didn't work!

.................................................................................................................Home / Back to Process Patterns / Back to Test Automation Patterns
B6 11