The test team as an enemy of development? And how can this be avoided?

  • 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?

  • 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.


    Alan Page did convince me having a separate security testing specialist team might be very important depending on your context and risks.

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2