Trjtdtk

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.

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.

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.

Trying to add to the great suggestions here...
How is the test team utilized towards the end of a sprint?
Do they become the limiting factor then, i.e. are developers waiting for feedback from testers?

A little bit of spare capacity is good to have (something like 15-20%), though it rarely becomes as visible as in your case.
It's needed for keeping response times low; put simply, without spare capacity you get queues and thus delays.
In your case, I assume you could make good use of some of that capacity towards the end of a sprint... if only you were able to move it there, right?

First suggestion: Do one week sprints.
As a result, you should get some user stories whose implementation will span two 1-week sprints.
Some of these will become "ready to test" at the beginning of a sprint, thus using some capacity.
Other user stories may also get "canceled" from the weekly release (or however you call the working software resulting from a sprint),
just because they still have bugs that you weren't able to fix in time
(Use feature flags to allow last-minute decisions of what gets released.)
These will also become "ready to test" at the beginning of the next sprint.

Second suggestion: Use Kanban instead of Scrum (there are hybrids of Kanban and Scrum as well).
With a Kanban system you'll get user stories arriving in the "Ready to Test" column continuously.
Then you can still collect a bunch of user stories in "Ready to Release" (i.e. development done, testing done) and
make a weekly or biweekly release from those.

Finally, whenever that team composition (5 developers, 3 testers) was decided,
you problably had a greater need for testing capacity than you have now.
With all your great automation and the other improvements, you may be able to put one tester into another team.

Whatever you do, be ready to accept some "idle time" -- think of it as providing tester availability for faster feedback.
If you reduce testing capacity too much, that will become the bottleneck and slow down the whole development cycle.

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 such level, product owner need to make the user stories innthis manner.

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

First focus on the overall value of quality assurance - the value added to the organization from the quality of the product, the quality of the testing, the number of defects recently found, the number of users affected, etc.

If your focus becomes short-term, such as "people look idle" you can very slip into a lot of bad practices equating output with number of hours (on a larger scale it doesn't), micromanaging, people living in fear, etc. This does not inspire quality work.

I think you have a good question but I would suggest you may wish to consider phrasing and titling it as:

What should quality professionals do while waiting for a new release to test?

And remove that mention of idle. I know it may seem 'idle' time from one perspective (testing a release right now) but when you follow the advice of the many answers here you'll see it need not be 'idle' at all and in fact can be some of the most productive and value adding time for the quality professionals who can finally have time to do 'all that other stuff' like:

• Time Off. we all need that.


• Technical Education. in this field it should be life long and constant. Every available moment should be spent on it when not testing a release, writing automation, on vacation, etc.


• Social Events. When done appropriately (often low-key) these strengthen connections.


• Domain Education. Spend time with users and/or their representatives to better understand how they use the application in the real world.


• Refactoring. The highlight of the day for many automation engineers.


• Reducing technical debt. Who doesn't have that?