Ytdyklly

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.

If you have a set of Regression Tests, testers can start automating them starting with which are easiest to automate. This will save you a lot of time in the long run during Regression Testing. Of course, this requires some programming skills and if the testers do not have those at the moment then this is the great time for them to learn it and apply to automating the tests. This is a win-win for both the testers and the team. As, testers are adding a new skill to their personal tool-set which will eventually benefit the business/company too.

In addition to some of the other suggestions, you could consider a few other options:

• Build/run load tests for new/recent work (given the maturity of your test automation you may already have this under control)


• Review existing test automation for obsolete or ineffective tests (You have no idea how much I wish I could reach this point)


• Review and refactor existing test automation code. In any rapid development environment, automated test code can get dated quite quickly.


• Review and update older customer documentation. In my experience this can become out of date fairly rapidly if development is quick.


• Review other documentation to make sure it's up to date. This can include (but is not limited to) use cases, business requirements, database dictionaries, functional requirements, test documentation...


• Work with product owners to refine any stories in the backlog - or just go in there and review them and ask questions anyway. Testers typically have a unique combination of breadth and depth with a product they're familiar with and can often pick up potentially problematic changes before they go to code.


• Review the user stories and defects in the current sprint and start planning how to test them. If there's configuration that's needed, it can save a lot of time to set up as much of the configuration as possible before the story/defect is coded.

A lot of these are things I've done when I found myself in a holding pattern.

Since you mentioned, it's a scrum.. its actually the scrum master role to make a deliverable level module to prepare from tiny user stories, so that tester can start preparing their test case based on the deliverable level.

Say for example, if a micro service which cannot be tested, it should not be included alone in the sprint, rather connecting module (frontend or api) should be included.speak to your scrum master, ask him for it, else request for agile coach itself for it.