Latest revision as of 15:42, 2 February 2019

.................................................................................................................Main Page / 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.

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

@@ Line 9: / Line 9: @@
 <span style="font-size: 16px">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.</span>
 =<span style="font-size: 16px">'''Implementation'''</span>=
-<span style="font-size: 16px">If you are doing agile development, you should already have a whole-team approach in place for software development, testing and test automation. </span><br /> <span style="font-size: 16px">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.</span>
+<span style="font-size: 16px">If you are doing agile development, you should already have a whole-team approach in place for software development, testing and test automation. </span><br /> <span style="font-size: 16px">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.</span>
 =<span style="font-size: 16px">'''Potential problems'''</span>=
 <span style="font-size: 16px">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.</span><br /> <span style="font-size: 16px">Another possible problem occurs when many DevOps teams develop test automation independently (look up the issue ''[[LOCALISED REGIMES]]''*)</span>
@@ Line 15: / Line 15: @@
 ''<span style="font-size: 16px">[[HARD-TO-AUTOMATE RESULTS]]</span>''<br /> <span style="font-size: 16px">''[[HIGH ROI EXPECTATIONS]]''</span><br /> ''<span style="font-size: 16px">[[INADEQUATE COMMUNICATION]]</span>''<br /> ''<span style="font-size: 16px">[[ INADEQUATE TEAM]]</span>''<br /> ''<span style="font-size: 16px">[[INCONSISTENT DATA]]</span>''<br /> ''<span style="font-size: 16px">[[ LATE TEST CASE DESIGN]]</span>''<br /> ''<span style="font-size: 16px">[[ NO INFO ON CHANGES]]</span>''<br /> ''<span style="font-size: 16px">[[ NO PREVIOUS TEST AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[SCHEDULE SLIP]]</span>''<br /> ''<span style="font-size: 16px">[[STALLED AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[SUT REMAKE]]</span>''<br /> ''<span style="font-size: 16px">[[TOO EARLY AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[TOOL-DRIVEN AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[ UNAUTOMATABLE TEST CASES]]</span>''<br /> ''<span style="font-size: 16px">[[ UNFOCUSED AUTOMATION]]</span>''<br /> ''<span style="font-size: 16px">[[UNMOTIVATED TEAM]]</span>''
 =<span style="font-size: 16px">'''Experiences:'''</span>=
-<span style="font-size: 16px">Thanks to Lisa Crispin for suggesting this pattern!</span><br /> <br /> <span style="font-size: 16px">''Jochim Van Dorpe'' writes:</span><br /> <br /> <span style="font-size: 16px">We use the 'whole team approach' since we've been put on an agile project.</span><br /> <span style="font-size: 16px">The project team consists of 1 Project Lead (PL), 2 functional analysts, 1 java architect, 3 developers and 1 tester / test analyst / test coordinator.</span><br /> <span style="font-size: 16px">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).</span><br /> <br /> <span style="font-size: 16px">* This problem has been pointed out by Vincent Wijnen</span><br /> <br /> <span style="font-size: 16px">Note:</span><br /> <span style="font-size: 16px">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!</span><br /> <br /> <span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span>
+<span style="font-size: 16px">Thanks to Lisa Crispin for suggesting this pattern!</span><br /> <br /> <span style="font-size: 16px">''Jochim Van Dorpe'' writes:</span><br /> <br /> <span style="font-size: 16px">We use the 'whole team approach' since we've been put on an agile project.</span><br /> <span style="font-size: 16px">The project team consists of 1 Project Lead (PL), 2 functional analysts, 1 java architect, 3 developers and 1 tester / test analyst / test coordinator.</span><br /> <span style="font-size: 16px">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).</span><br /> <br /> <span style="font-size: 16px">* This problem has been pointed out by Vincent Wijnen</span><br /> <br />
+<span style="font-size: 16px">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.</span><br /> <br />
+<span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span>

Difference between revisions of "WHOLE TEAM APPROACH"

Latest revision as of 15:42, 2 February 2019

Contents