The test team as an enemy of development? And how can this be avoided? Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?What is the sense of having a monkey tester execute your test script?Testing phase in the developmentHow to test your tests without having the system under test?QA as Scrum MasterHow to write automation when test engineers are constantly pulled to do manual testing?How to handle Idle team members in SprintWhat should Testers do if they are not able to find good defects in the product?Why QA tools aggregate info on “projects” and not “teams”?What should tester do when user stories/documentation is outdated or simply wrong?How to deal with or prevent idle in the test team?
Random body shuffle every night—can we still function?
Tannaka duality for semisimple groups
Trademark violation for app?
Draw 4 of the same figure in the same tikzpicture
macOS: Name for app shortcut screen found by pinching with thumb and three fingers
Is it fair for a professor to grade us on the possession of past papers?
1-probability to calculate two events in a row
What is the difference between a "ranged attack" and a "ranged weapon attack"?
Do I really need to have a message in a novel to appeal to readers?
How does Belgium enforce obligatory attendance in elections?
Why are vacuum tubes still used in amateur radios?
What is an "asse" in Elizabethan English?
Is there public access to the Meteor Crater in Arizona?
What does this say in Elvish?
The test team as an enemy of development? And how can this be avoided?
What does 丫 mean? 丫是什么意思?
Misunderstanding of Sylow theory
How many morphisms from 1 to 1+1 can there be?
Google .dev domain strangely redirects to https
What does Turing mean by this statement?
Can a Beast Master ranger change beast companions?
Intuitive explanation of the rank-nullity theorem
Semigroups with no morphisms between them
Does "shooting for effect" have contradictory meanings in different areas?
The test team as an enemy of development? And how can this be avoided?
Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?What is the sense of having a monkey tester execute your test script?Testing phase in the developmentHow to test your tests without having the system under test?QA as Scrum MasterHow to write automation when test engineers are constantly pulled to do manual testing?How to handle Idle team members in SprintWhat should Testers do if they are not able to find good defects in the product?Why QA tools aggregate info on “projects” and not “teams”?What should tester do when user stories/documentation is outdated or simply wrong?How to deal with or prevent idle in the test team?
Details
Forming a Scrum team should include all the skills necessary to develop a user story in order to deliver a potentially deliverable product increment with each sprint.
In traditional organizations, however, I always encounter a fundamental mistrust of the integration of testers in the Scrum teams. Instead, a separate test team is to remain, which is then responsible for regression tests, load and performance tests and the test automation. The rationale for this type of organization is the so-called independence of the testers.
I have several problems with this view of things. Scrum makes the team fully responsible for the results. The establishment of an "independent" test team assumes that the Scrum team does not live up to its responsibilities and would turn a blind eye to errors in the product increment.
Another danger associated with the independent test team is that the testers become test report reporters who are not involved in the elimination of the problem.
In the scrum sense, we prefer problem solvers. The tester in the Scrum team, as well as all developers responsible for the delivery of a flawless product increment and will make every effort to fix it or have it fixed when uncovering an error. Another advantage of the tester in the team is the simple possibility to develop automated tests in step with the implementation of the user stories.
The Problem:
the procedure described already shows a part of the problem: the lead time for a new Product Backlog Item increases to several Sprints: 1 Sprint implementation plus 1 Sprint deferred test (plus possibly another Sprint error correction, if unfortunately this is no longer possible, without the commitment to break the current sprint, and considered less important). This results in further problems: does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
How to change this problem?
automated-testing manual-testing test-management test-design scrum
add a comment |
Details
Forming a Scrum team should include all the skills necessary to develop a user story in order to deliver a potentially deliverable product increment with each sprint.
In traditional organizations, however, I always encounter a fundamental mistrust of the integration of testers in the Scrum teams. Instead, a separate test team is to remain, which is then responsible for regression tests, load and performance tests and the test automation. The rationale for this type of organization is the so-called independence of the testers.
I have several problems with this view of things. Scrum makes the team fully responsible for the results. The establishment of an "independent" test team assumes that the Scrum team does not live up to its responsibilities and would turn a blind eye to errors in the product increment.
Another danger associated with the independent test team is that the testers become test report reporters who are not involved in the elimination of the problem.
In the scrum sense, we prefer problem solvers. The tester in the Scrum team, as well as all developers responsible for the delivery of a flawless product increment and will make every effort to fix it or have it fixed when uncovering an error. Another advantage of the tester in the team is the simple possibility to develop automated tests in step with the implementation of the user stories.
The Problem:
the procedure described already shows a part of the problem: the lead time for a new Product Backlog Item increases to several Sprints: 1 Sprint implementation plus 1 Sprint deferred test (plus possibly another Sprint error correction, if unfortunately this is no longer possible, without the commitment to break the current sprint, and considered less important). This results in further problems: does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
How to change this problem?
automated-testing manual-testing test-management test-design scrum
add a comment |
Details
Forming a Scrum team should include all the skills necessary to develop a user story in order to deliver a potentially deliverable product increment with each sprint.
In traditional organizations, however, I always encounter a fundamental mistrust of the integration of testers in the Scrum teams. Instead, a separate test team is to remain, which is then responsible for regression tests, load and performance tests and the test automation. The rationale for this type of organization is the so-called independence of the testers.
I have several problems with this view of things. Scrum makes the team fully responsible for the results. The establishment of an "independent" test team assumes that the Scrum team does not live up to its responsibilities and would turn a blind eye to errors in the product increment.
Another danger associated with the independent test team is that the testers become test report reporters who are not involved in the elimination of the problem.
In the scrum sense, we prefer problem solvers. The tester in the Scrum team, as well as all developers responsible for the delivery of a flawless product increment and will make every effort to fix it or have it fixed when uncovering an error. Another advantage of the tester in the team is the simple possibility to develop automated tests in step with the implementation of the user stories.
The Problem:
the procedure described already shows a part of the problem: the lead time for a new Product Backlog Item increases to several Sprints: 1 Sprint implementation plus 1 Sprint deferred test (plus possibly another Sprint error correction, if unfortunately this is no longer possible, without the commitment to break the current sprint, and considered less important). This results in further problems: does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
How to change this problem?
automated-testing manual-testing test-management test-design scrum
Details
Forming a Scrum team should include all the skills necessary to develop a user story in order to deliver a potentially deliverable product increment with each sprint.
In traditional organizations, however, I always encounter a fundamental mistrust of the integration of testers in the Scrum teams. Instead, a separate test team is to remain, which is then responsible for regression tests, load and performance tests and the test automation. The rationale for this type of organization is the so-called independence of the testers.
I have several problems with this view of things. Scrum makes the team fully responsible for the results. The establishment of an "independent" test team assumes that the Scrum team does not live up to its responsibilities and would turn a blind eye to errors in the product increment.
Another danger associated with the independent test team is that the testers become test report reporters who are not involved in the elimination of the problem.
In the scrum sense, we prefer problem solvers. The tester in the Scrum team, as well as all developers responsible for the delivery of a flawless product increment and will make every effort to fix it or have it fixed when uncovering an error. Another advantage of the tester in the team is the simple possibility to develop automated tests in step with the implementation of the user stories.
The Problem:
the procedure described already shows a part of the problem: the lead time for a new Product Backlog Item increases to several Sprints: 1 Sprint implementation plus 1 Sprint deferred test (plus possibly another Sprint error correction, if unfortunately this is no longer possible, without the commitment to break the current sprint, and considered less important). This results in further problems: does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
How to change this problem?
automated-testing manual-testing test-management test-design scrum
automated-testing manual-testing test-management test-design scrum
asked 3 hours ago
MornonMornon
15310
15310
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest about these ScrumBut Mini Waterfalls (eg testing after the Sprint) to management. Good Scrum leadership should work on fixing it. I think your thinking is spot on, but trust has still to be earned. See if you can find one team who dares to help prove that your thinking works. Maybe ask dev and test team for 2-3 Sprints to Experiment with your ideas.
The rationale for this type of organization is the so-called
independence of the testers.
The counter-argument is that having an independent test team is that development teams can take shortcuts to make their Sprints because the testers will find their mistakes. Leading to dev-test ping-pong and lower quality because the test team is also under pressure to release and will skip low risks tests over high-risk area's. Leading to a slower release cycle and overall lower quality.
Scrum Testers should create a quality culture in the Scrum team, coaching team members to understand how to produce a well-tested increment at the end of the Sprint.
Load and performance testing could be a separate Product Backlog Item to improve performance. Although automating this type of testing in build pipelines is becoming more and more common.
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
add a comment |
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
stop it
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
plus ones that I would add such as:
How to keep the code bases branched correctly? How to keep code in sync with environments? How to manage deployment through multiple environments and tests and processes? How to record the bugs?
When I find I am writing the words above I pause and go back to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
particularly
- Individuals and interactions over processes and tools
Testing is sprint+1 is introducing a whole lot of process instead of individuals doing the work now and talking to each other. This sort of set up will inevitably lead to "The test team as an enemy of development" and that is what you have found. Exactly that
You need to keep stressing the importance of changing this. It is an investment. It will slow development down this week... and speed it up in X months. Leadership for the long term view is needed and can come come from any self-empowered person in the organization.
If you cannot change the setup I recommend the following actions:
- Write failing tests first (BDD)
- Pay equitably for automation engineers
- Communicate the benefit of testing to developers
- Work on relationships between application and automation engineers
- Embed automation engineers within the application development teams
- Truly empower automation engineers to 'pull the cord' and say no, don't deploy
- Talk openly about second class citizen syndrome for testers and how to avoid it
- Ensure social events - lunches, parties, lunch and learns, etc. include both parties
- Refer to folks as application and automation engineers instead of 'devs and testers'
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "244"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f38832%2fthe-test-team-as-an-enemy-of-development-and-how-can-this-be-avoided%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest about these ScrumBut Mini Waterfalls (eg testing after the Sprint) to management. Good Scrum leadership should work on fixing it. I think your thinking is spot on, but trust has still to be earned. See if you can find one team who dares to help prove that your thinking works. Maybe ask dev and test team for 2-3 Sprints to Experiment with your ideas.
The rationale for this type of organization is the so-called
independence of the testers.
The counter-argument is that having an independent test team is that development teams can take shortcuts to make their Sprints because the testers will find their mistakes. Leading to dev-test ping-pong and lower quality because the test team is also under pressure to release and will skip low risks tests over high-risk area's. Leading to a slower release cycle and overall lower quality.
Scrum Testers should create a quality culture in the Scrum team, coaching team members to understand how to produce a well-tested increment at the end of the Sprint.
Load and performance testing could be a separate Product Backlog Item to improve performance. Although automating this type of testing in build pipelines is becoming more and more common.
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
add a comment |
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest about these ScrumBut Mini Waterfalls (eg testing after the Sprint) to management. Good Scrum leadership should work on fixing it. I think your thinking is spot on, but trust has still to be earned. See if you can find one team who dares to help prove that your thinking works. Maybe ask dev and test team for 2-3 Sprints to Experiment with your ideas.
The rationale for this type of organization is the so-called
independence of the testers.
The counter-argument is that having an independent test team is that development teams can take shortcuts to make their Sprints because the testers will find their mistakes. Leading to dev-test ping-pong and lower quality because the test team is also under pressure to release and will skip low risks tests over high-risk area's. Leading to a slower release cycle and overall lower quality.
Scrum Testers should create a quality culture in the Scrum team, coaching team members to understand how to produce a well-tested increment at the end of the Sprint.
Load and performance testing could be a separate Product Backlog Item to improve performance. Although automating this type of testing in build pipelines is becoming more and more common.
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
add a comment |
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest about these ScrumBut Mini Waterfalls (eg testing after the Sprint) to management. Good Scrum leadership should work on fixing it. I think your thinking is spot on, but trust has still to be earned. See if you can find one team who dares to help prove that your thinking works. Maybe ask dev and test team for 2-3 Sprints to Experiment with your ideas.
The rationale for this type of organization is the so-called
independence of the testers.
The counter-argument is that having an independent test team is that development teams can take shortcuts to make their Sprints because the testers will find their mistakes. Leading to dev-test ping-pong and lower quality because the test team is also under pressure to release and will skip low risks tests over high-risk area's. Leading to a slower release cycle and overall lower quality.
Scrum Testers should create a quality culture in the Scrum team, coaching team members to understand how to produce a well-tested increment at the end of the Sprint.
Load and performance testing could be a separate Product Backlog Item to improve performance. Although automating this type of testing in build pipelines is becoming more and more common.
Get a good Scrum Master who can convince the organization that Scrum teams should not be depended on other teams to deliver shippable software. It is an impediment he/she should resolve.
Traditional Organisations want the benefits of Scrum without changing their ways. Even for great coaches, this could be a process of years. Don't give up. Be bluntly honest about these ScrumBut Mini Waterfalls (eg testing after the Sprint) to management. Good Scrum leadership should work on fixing it. I think your thinking is spot on, but trust has still to be earned. See if you can find one team who dares to help prove that your thinking works. Maybe ask dev and test team for 2-3 Sprints to Experiment with your ideas.
The rationale for this type of organization is the so-called
independence of the testers.
The counter-argument is that having an independent test team is that development teams can take shortcuts to make their Sprints because the testers will find their mistakes. Leading to dev-test ping-pong and lower quality because the test team is also under pressure to release and will skip low risks tests over high-risk area's. Leading to a slower release cycle and overall lower quality.
Scrum Testers should create a quality culture in the Scrum team, coaching team members to understand how to produce a well-tested increment at the end of the Sprint.
Load and performance testing could be a separate Product Backlog Item to improve performance. Although automating this type of testing in build pipelines is becoming more and more common.
edited 3 hours ago
answered 3 hours ago
Niels van ReijmersdalNiels van Reijmersdal
21.6k23172
21.6k23172
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
add a comment |
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
This answers the question well, so I hope it's ok that I tack on a small detail. The change that you're pointing out is based in the lean principle of building quality in rather than checking for it afterward. For an org that is really concerned about separation of responsibilities, you can actually keep this at first, but you have both dev and test in that team working in the same sprint with the test expert working hand in hand to help developers build quality in. In short order the org usually sees the lack of value in the extra hierarchical separation, but it might be an ok bridge.
– Daniel
2 hours ago
add a comment |
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
stop it
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
plus ones that I would add such as:
How to keep the code bases branched correctly? How to keep code in sync with environments? How to manage deployment through multiple environments and tests and processes? How to record the bugs?
When I find I am writing the words above I pause and go back to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
particularly
- Individuals and interactions over processes and tools
Testing is sprint+1 is introducing a whole lot of process instead of individuals doing the work now and talking to each other. This sort of set up will inevitably lead to "The test team as an enemy of development" and that is what you have found. Exactly that
You need to keep stressing the importance of changing this. It is an investment. It will slow development down this week... and speed it up in X months. Leadership for the long term view is needed and can come come from any self-empowered person in the organization.
If you cannot change the setup I recommend the following actions:
- Write failing tests first (BDD)
- Pay equitably for automation engineers
- Communicate the benefit of testing to developers
- Work on relationships between application and automation engineers
- Embed automation engineers within the application development teams
- Truly empower automation engineers to 'pull the cord' and say no, don't deploy
- Talk openly about second class citizen syndrome for testers and how to avoid it
- Ensure social events - lunches, parties, lunch and learns, etc. include both parties
- Refer to folks as application and automation engineers instead of 'devs and testers'
add a comment |
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
stop it
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
plus ones that I would add such as:
How to keep the code bases branched correctly? How to keep code in sync with environments? How to manage deployment through multiple environments and tests and processes? How to record the bugs?
When I find I am writing the words above I pause and go back to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
particularly
- Individuals and interactions over processes and tools
Testing is sprint+1 is introducing a whole lot of process instead of individuals doing the work now and talking to each other. This sort of set up will inevitably lead to "The test team as an enemy of development" and that is what you have found. Exactly that
You need to keep stressing the importance of changing this. It is an investment. It will slow development down this week... and speed it up in X months. Leadership for the long term view is needed and can come come from any self-empowered person in the organization.
If you cannot change the setup I recommend the following actions:
- Write failing tests first (BDD)
- Pay equitably for automation engineers
- Communicate the benefit of testing to developers
- Work on relationships between application and automation engineers
- Embed automation engineers within the application development teams
- Truly empower automation engineers to 'pull the cord' and say no, don't deploy
- Talk openly about second class citizen syndrome for testers and how to avoid it
- Ensure social events - lunches, parties, lunch and learns, etc. include both parties
- Refer to folks as application and automation engineers instead of 'devs and testers'
add a comment |
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
stop it
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
plus ones that I would add such as:
How to keep the code bases branched correctly? How to keep code in sync with environments? How to manage deployment through multiple environments and tests and processes? How to record the bugs?
When I find I am writing the words above I pause and go back to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
particularly
- Individuals and interactions over processes and tools
Testing is sprint+1 is introducing a whole lot of process instead of individuals doing the work now and talking to each other. This sort of set up will inevitably lead to "The test team as an enemy of development" and that is what you have found. Exactly that
You need to keep stressing the importance of changing this. It is an investment. It will slow development down this week... and speed it up in X months. Leadership for the long term view is needed and can come come from any self-empowered person in the organization.
If you cannot change the setup I recommend the following actions:
- Write failing tests first (BDD)
- Pay equitably for automation engineers
- Communicate the benefit of testing to developers
- Work on relationships between application and automation engineers
- Embed automation engineers within the application development teams
- Truly empower automation engineers to 'pull the cord' and say no, don't deploy
- Talk openly about second class citizen syndrome for testers and how to avoid it
- Ensure social events - lunches, parties, lunch and learns, etc. include both parties
- Refer to folks as application and automation engineers instead of 'devs and testers'
I've tested in the sprint + 1 system under the SAFe framework. The framework does not specific this but lends itself to doing it for organizations coming from waterfall.
Mu suggestion is:
stop it
Your questions of
Does one need 2 Definition of Done? When does the PO take the item? Does he take it off twice? How much buffer does the deployment team need to keep in fix to fix the returned bugs? Not to mention the context switch that becomes necessary. Pull testers and developers together and try to avoid mistakes instead of finding (with 1 sprint offset)? etc etc
plus ones that I would add such as:
How to keep the code bases branched correctly? How to keep code in sync with environments? How to manage deployment through multiple environments and tests and processes? How to record the bugs?
When I find I am writing the words above I pause and go back to:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
particularly
- Individuals and interactions over processes and tools
Testing is sprint+1 is introducing a whole lot of process instead of individuals doing the work now and talking to each other. This sort of set up will inevitably lead to "The test team as an enemy of development" and that is what you have found. Exactly that
You need to keep stressing the importance of changing this. It is an investment. It will slow development down this week... and speed it up in X months. Leadership for the long term view is needed and can come come from any self-empowered person in the organization.
If you cannot change the setup I recommend the following actions:
- Write failing tests first (BDD)
- Pay equitably for automation engineers
- Communicate the benefit of testing to developers
- Work on relationships between application and automation engineers
- Embed automation engineers within the application development teams
- Truly empower automation engineers to 'pull the cord' and say no, don't deploy
- Talk openly about second class citizen syndrome for testers and how to avoid it
- Ensure social events - lunches, parties, lunch and learns, etc. include both parties
- Refer to folks as application and automation engineers instead of 'devs and testers'
edited 37 mins ago
answered 53 mins ago
Michael DurrantMichael Durrant
14.8k22165
14.8k22165
add a comment |
add a comment |
Thanks for contributing an answer to Software Quality Assurance & Testing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f38832%2fthe-test-team-as-an-enemy-of-development-and-how-can-this-be-avoided%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown