How to deal with or prevent idle in the test team?



  • I'm currently in two scrum projects. The team consists of 9 people (5 developers, 3 testers). We work with user stories, story point estimates and two-week sprints. The team has received a great deal of Scrum and delivers reliably finished (Code + Test + Documentation) software. The test automation is up to date, and the CI runs through every day. However, this does not result in enough tasks for the test team.

    Nevertheless, we have the following problem:

    At the beginning of the sprint it always takes until testable user stories are completed. Therefore, it comes to idle with the testers, because there is nothing to test.

    Already taken countermeasures (which could not solve the problem):

    • Testers begin with the test preparation for all stories

    • Support testers - where possible - the work of the developers

    • "Open Issues List" by the team in case someone has nothing to do

    • Know How Transfer among the testers

    Nevertheless, we have not gotten the problem under control so far. Question: Has anyone had similar experiences? What can you do about it? I am grateful for all suggestions!



  • "there is nothing to test"

    That is a strong statement.

    I like to use James Bach's definition of testing:

    Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes to some degree: questioning, study, modeling, observation, inference, etc.

    So, unless there is nothing new to learn about the product, yes, you don't have anything to test.

    However, there may be some new things that you can learn. Maybe if you do some of the following, you may uncover them:

    • Pair programming (yes, with the developer);
    • Investigate results of your monitoring and logging instrumentation;
    • Extend your monitoring and logging instrumentation;
    • Create chaos in your environments;
    • Refine backlog to remove duplication and increase simplicity;
    • Watch users (control groups or real ones) using your product;
    • Investigate competitors systems;
    • Refactor any piece of code (production code, automated checking code, deployment code, etc).

    These activities may put a tester in new places, expanding his/hers understanding of the product.



Suggested Topics

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