It was generally considered that developers develop and testers test. Is it right for an Agile team?

For example, in Scrum, should developers take tester's tasks in the end of a Sprint to help complete all the Stories the team has committed to during the Sprint Planning.

Or in Kanban, should developers take tester's tasks when, for example, DEVELOPMENT WIP limit is reached?

  • 1
    The direct answer to your question is that Scrum says that no one but the team members may tell the team how they organize around the work. Kanban, similarly, has nothing to say on the matter except that you should manage the work, not the people. A vast amount of evidence shows that silo'ing is problematic, but the broader conversation on who should do what testing is large and nuanced. Is there a particular area of it you have a question about? – Daniel Jan 14 '20 at 20:01
  • Not an answer, just a general sidenote: Whatever your development method, it's generally a bad idea to have developers do extensive testing, speaking as primarily developer myself. Automated tests and basic functionality test, sure, but developers don't think like users and will rarely test for the right things, so test quality will be poor if you let developers test. Also, developers cost a lot, testers don't, so even economically, having non-developer testers makes sense. They might or might not be part of the development/scrum team, depending on the processes. – Morfildur Jan 15 '20 at 8:39
  • @Morfildur - if you get developers to test each other's section of the system, maybe we'd get better results? ;-) – Danny Schoemann Jan 15 '20 at 9:52

The Scrum Guide states a few things about the Development Team - it is "self-organizing" and no one can tell "the Development Team how to turn Product Backlog into Increments of potentially releasable functionality", that there are "no titles for Development Team members, regardless of the work being performed by the person", there are "no sub-teams in the Development Team, regardless of the domains that need to be addressed", and "individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole". If you were adhering to the rules of Scrum, then the whole team would be accountable and you wouldn't have "developers' tasks" or "testers' tasks" but the team would be collaboratively working to get the work done per their Definition of "Done" and ensure the Increment is potentially releasable by the end of the Sprint.

Kanban (assuming you are talking about David J. Anderson's Kanban method) says even less. The principles of Kanban include "start with what you do now" and "respect the current process, roles, and responsibilities", and then "agree to pursue incremental, evolutionary change". If you follow the various practices about visualizing workflow, making your policies explicit, managing the flow of work, and incorporating feedback loops and collaborative improvement, you may identify areas where you want to change your workflow and policies and roles. It's about doing what is right for your team, rather than having explicit definitions - different teams and organizations using the Kanban Method may reach different conclusions.

More important than the methods and frameworks, though, are your organizational constraints. For example, I have experience in regulated fields. When building safety and life critical systems, there may be requirements placed upon the development process. One such requirement for some systems is the need for independent verification and/or validation and objective evidence of that independent verification and validation. This means that a group independent of the development team must perform analysis and testing of the software and system to ensure that it conforms to requirements and is safe. However, it does not mean that all testing and verification must be done by an independent group.

We, in various engineering fields, have found that it is faster and cheaper in order to find and fix defects closer to their point of origin. Two of the wastes from lean are relevant. Discarding or reworking due to earlier injected defects is one type of waste. Hand-offs (of product or knowledge) is another. Reducing defects and minimizing hand-offs to those that are necessary leads to improved quality, improved flow, and often less cost and time.

Even in cases that require an independent group to perform testing, it's wasteful to rely on that group to perform testing. The people producing the product should also be involved in testing it. There may be reasons why an independent group also has to test, but this group should exist to satisfy regulatory compliance and not exist to find defects (although the extra safety net is also good when you're dealing with the most life and safety critical systems).

In the end, I'd say that it's ineffective for any team to have a silo between developers and testers. This applies to both agile and plan-driven teams.

  • I liked your answer until the point where you state that "an independent group also has to test, but this group should exist to satisfy regulatory compliance and not exist to find defects". You install a team "to satisfy regulatory compliance"? And how do you expect these people to feel valued or to act responsibly? What's bad or expensive about a different person deriving the test cases from requirements than the person who codes? Doesn't it lead to fewer misunderstandings, thus reducing costs closer to the source? – loom with a crew Jan 21 '20 at 4:49
  • @loomwithacrew Outside of regulatory compliance where an independent team must exist to perform independent verification and validation, I don't feel that the costs associated with independent test teams is worth the benefit. Consider the cost to hand off not only the requirements and the software product being tested, but the hand off of possible defects and a discussion about if those defects are real or a tester's misunderstanding of the requirements. Any kind of silo is costly (in terms of time, money, and productivity). That said... – Thomas Owens Jan 21 '20 at 10:01
  • Some organizations do feel that an independent testing team provides a safety net. Maybe, to them, it is valuable. But, to me, that is a symptom of problems on the development team. Just to name a few problems - a lack of understanding of the true requirements, a lack of concern about system/product quality, an inability to define and write (or execute) valuable tests at all appropriate levels (and there are more). But waiting to get software to this team adds cost to a fix on top of the staffing needs of this team - it would be better to fix the problem(s) on the dev team. – Thomas Owens Jan 21 '20 at 10:06
  • What kind of testing are you talking about? A test case that is derived from a requirement, clarifies that requirement and I don't see how that's debatable since neither the requirement nor the test case can be owned by a developer. "Hand off", well, just a few more automatic tests there which the developer can't tweak without discussion, which leads to clarification, which is good. And are you really assuming optimal team skills? – loom with a crew Jan 21 '20 at 20:44

In Agile it can be useful to think of individuals having a capability rather than a role.

Jill has a capability to do development work

Sam has a capability to do testing work

Helen has a capability to do both development and testing work

If our team is full of specialists who can only do one thing, then when we bring work into a sprint it can be a real challenge to get exactly the right balance.

For example, some stories we select for a sprint might be testing heavy and so require more testing capability. In another sprint it may be more development heavy and then we will require more development capability.

This can result in some individuals being overworked and others having not enough to do.

You can start to see how it would be very helpful if there are team members who are cross-skilled. Perhaps one team member is really good at development work, but can also write great automated tests.

A team filled with cross-skilled people will be very flexible in terms of the work they can take into a sprint without causing any imbalances.

A lot of teams when they first start out with Agile consist mainly of specialists. These teams can often benefit by sharing knowledge and doing additional training so that they become cross-skilled. This increased flexibility is likely to make the team more effective.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.