Difference between revisions of "WHOLE TEAM APPROACH"
Jump to navigation
Jump to search
(Created page with "<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.........................................................................................") |
m (Topic titles in capital letters) |
||
| Line 1: | Line 1: | ||
<div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span> | <div id="content_view" class="wiki" style="display: block"><span style="font-size: 14px">.................................................................................................................[[Main Page]] / Back to [[Process Patterns]] / Back to [[Test Automation Patterns]]</span> | ||
| − | =<span style="font-size: 16px">Pattern summary</span>= | + | =<span style="font-size: 16px">'''Pattern summary'''</span>= |
<span style="font-size: 16px">Testers, coders and other roles work together on one team to develop test automation along with production code.</span> | <span style="font-size: 16px">Testers, coders and other roles work together on one team to develop test automation along with production code.</span> | ||
| − | =<span style="font-size: 16px">Category</span>= | + | =<span style="font-size: 16px">'''Category'''</span>= |
<span style="font-size: 16px">Process</span> | <span style="font-size: 16px">Process</span> | ||
| − | =<span style="font-size: 16px">Context</span>= | + | =<span style="font-size: 16px">'''Context'''</span>= |
<span style="font-size: 16px">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.</span> | <span style="font-size: 16px">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.</span> | ||
| − | =<span style="font-size: 16px">Description</span>= | + | =<span style="font-size: 16px">'''Description'''</span>= |
<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">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">'''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 ([[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">Potential problems</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> | <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> | ||
| − | =<span style="font-size: 16px">Issues addressed by this pattern</span>= | + | =<span style="font-size: 16px">'''Issues addressed by this pattern'''</span>= |
''<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">[[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">'''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><br /> <span style="font-size: 14px">B6 11</span></div> | <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><br /> <span style="font-size: 14px">B6 11</span></div> | ||
Revision as of 13:10, 28 April 2018
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
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
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!
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
B6 11
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.
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
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!
.................................................................................................................Main Page / Back to Process Patterns / Back to Test Automation Patterns
B6 11