0

In a scrum team there are automation testers and manual testers as well as database mid and front end developers. While the automation testers from the beginning of the sprint start creating tests to automate the UI, manual tests usually wait for the code to be deployed, whilst creating lengthy test plans that will cover all the test cases for the job done. Then, they wait for the code to be deployed, and only then do they start testing, and putting their results in the central-testing software. This creates a massive testing overhead that ends up in stories not being done. Also, sometimes, despite short development, testing might take many days to complete.

What are your suggestions to adapt the manual testers, whilst maintaining software quality in the pre-production environment?

Improve this question

1 Answer 1

Reset to default
2

The sooner the developers can get code to the testers, the less the risk of back-loading the sprint.

There are a number of things the team can do to help with this.

Minimise the size of stories. The smaller they are, the earlier in the sprint there will be completed stories and the sooner the manual testers will be able to get started.

Plan carefully. Focus in the planning meeting on what order of stories will best keep the manual testers busy. Perhaps there are certain stories that require a lot more testing than others? These stories should be worked on first and if possible broken up so that they are delivered sooner.

Work through each story in turn and decide what is practical to develop and test in the sprint. It may be that some combinations of stories are just not practical, especially if they are all manual testing heavy.

Try and leave the sprint planning session with an idea of what will get done and when. Of course this won't be perfect, as unexpected things will happen once work has started. But you will find there is real value in spending time during planning so that these problems are minimised.

In the medium/long-run you might want to consider having the manual testers cross-train to learn how to do automated testing. This will give you more flexibility and enable you to generate more automated regression tests. It would also help if the developers were willing to assist with testing. This would allow you to reduce the elapsed time for the manual testing.

Finally, if you still have the issue of incomplete stories at the end of the sprint (as they have not been tested), then the team should start to bring fewer story points in to the sprint. Better to have the team working on a realistic amount of story points than to have them continually missing the completetion of some stories.

Improve this answer
2
  • This is a good answer, however what if the majority of the stories cannot be broken down, and the ratio of easy/difficult stories in a sprint are 1/4? Theory says that "with maturity comes better backlog refinement and planning", though what happens in "immature" teams? Then, with respect to testing, plans do go wrong more often than not.
    – dqm
    Apr 16, 2016 at 18:55
  • My experience has been that almost all stories can be broken down. It is a real challenge and you need to use all of the intelligence and ingenuity of the team to achive it. Strive for the absolute minimum sized story that can deliver some value. As you say, immature teams will not be as good at planning. This should be reflected in the team's velocity, so that they bring less work in to a sprint. As they get better they can increase the amount of story points they bring in.
    – Barnaby Golden
    Apr 16, 2016 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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