We are currently having multiple scrum teams with 3 to 6 developers and 1 dedicated tester in each team.
Should we have scrum team like this OR have all the developers and they can share testing responsibility mutually?
0
-
Is this opinion related, or is it possible to provide an authoritative answer? – Mark C. Wallace Jul 8 at 19:31
4
In a Scrum team it is best to distinguish between roles and capabilities.
Every Scrum team needs a testing capability, but it does not necessarily need tester roles.
The whole Scrum team takes responsibility for quality. This means more than just testing, it also means:
- Automated regression tests
- Maintaining code quality
- Use of continuous integration
- Exploratory testing
There are undoubted skills to being a good tester and some will be better at it than others. However, we can look to share this knowledge around the Scrum team using mentoring and training. This is why we talk about having t-shaped skill profiles in a Scrum team.
answered Dec 24 '17 at 10:03
-
Good article. So you suggest to have a tester with in depth knowledge of various testing methods and other developers to learn from them or help them? – maverick Dec 24 '17 at 10:48
-
A mixture of both. Remember there will be times when the tester is not available (holidays, sickness), so it is worth transferring as much of the knowledge as possible. But if your tester is gifted at finding problems, look for the team to support them when possible. – Barnaby Golden Dec 24 '17 at 14:49
0
Agile methodology looks to the development process as a "Collaborative Process", so every role has to participate in development process.
The testers look at the product in a different way that the developers look: in general, the testers try to make the software product fail. In contrast, developers try to make the software product pass. This difference in the methodology of thinking increase possibility of discovering bugs early.
Sharing dedicated testing members from the beginning life of the product gives them a good understanding about the business and technical aspects of the product.
-1
While sharing testing responsibility across the team is important, Agile teams still need dedicated testers, especially now with broader focuses on automation. Not having a dedicated person solely focused on quality could spell disaster for your team.
-
1I agree that automation should be focus. But what could be downside of making developers responsible for automation testing as well? – maverick Dec 23 '17 at 17:16
-
The downside is you are committing them to maintaining assets that do nothing to enhance and grow the product. Automation is great but it adds nothing to the front facing customer experience. Having devs be responsible for all of these assets seems like overkill. And again, code coverage is a tricky thing, especially when you have the 'guards guarding the guards,' scenario, and you most likely will see a drop in test quality. – Jon Luzader Dec 23 '17 at 17:21
-
Which also means a decrease in ROI on your automation library as well as decreasing velocity of feature development. Remember, devs care mostly about one thing: building out the product by introducing small changes to the code base regularly. Test engineers care mostly about having declarative tests that validate the boundaries or 'edges' of a software component. E.g., when an automated test is ran, most lines of code in a software module are executed. Leaving this up to developers to ensure coverage (n # of scenarios), is not the greatest idea – Jon Luzader Dec 23 '17 at 17:28
-
Got it. This idea came as we don't get quality people for testing so doing automation testing is getting difficult. So we thought of this idea. – maverick Dec 23 '17 at 17:32
-
2Having one person solely focused on quality implies that the rest of the team doesn't need to bother (too much)... It also opens the door to the blame game: "you should have ...." which is all bad in my book. – Ray Oei Dec 29 '17 at 11:57
-1
The only solution is to hire a one-armed project manager. That way he can't say "on the other hand..."
Obviously having "developers" also being "testers" leads to a conflict of interest.
On the other hand, let's assume a big release has now finished coding. The "developers" have no work and the "testers" are overloaded. So should the developers play solitaire on their computers until the testers are done?
So there just isn't absolute solution to the dilemma.
-
There is no conflict of interest on a healthy team. The entire team is responsible for quality. That doesn’t preclude having a quality expert on the team, but yeah. If you have a healthy team of professionals, they’ll all want to deliver a quality product. – RubberDuck Dec 24 '17 at 15:52
-
"Conflict of interest" might be the wrong way to put it. But it is hard to test your own code since you viewing it a certain way. People are in general reluctant to admit their mistakes (which is unhealthy for a good team). We got around the problem by first having a different develop do a code review, then also a different developer would test rather that section rather than the one who wrote the code. – MaxW Dec 24 '17 at 15:59
-
Now those are all things I can agree with. One team I was on got excellent results from white box testing. The peer reviewer was also responsible for pulling the proposed change & testing it. Gave them a unique perspective on “how I can break this”? – RubberDuck Dec 24 '17 at 16:01
