They had one tester, and a large number of devs.
The tester was not able to keep up with dev productivity, and as a result the debt in test was such that the devs were now ceasing new development and instead helping with the testing debt.
While its awesome they did that, the fact it was necessary was and is a problem.
The problem with this approach, as John Sullivan @Sensis once pointed out to me- is that the practice is “Ping Ponging”, as in you’re throwing resources to solve one problem (which more than likely wont solve the core problem, and will happen again), and then you’ll take them back and use them elsewhere when the immediate pain has been alleviated.
The most obvious and common perceived solution is simply to get more testers.
Of course, the words “easier said than done” don’t quite cover the futility of this, even if you had a Stork that somehow magically solved this, you still would not probably be working efficiently and something would need to change to make good use of said Stork delivered product.
What I usually propose in this situation is to front load testing, that is- to bring the preparation earlier into the life cycle.
Usually, when the tester is slammed, so is the Business Analyst. They’re the two frequent pain points aka bottlenecks.
I suggest you to get your Tester and your BA to work together on the stories and do the acceptance criteria and test cases up front as part of your normal planning phase.
What this means is, your tester and your BA have brainstormed, asked questions, written down all the test cases they can think of. Any questions that needed the BA to go ask the business, they’ve most likely done before a dev started producing code in anger. When the story hits “Ready For Development”, it really means that the story requirements are there, the test cases are there, and you could go write your automation, or if you decided to skip that step and go write the dev code you could (but as a TDD proponent I’d advise against skipping it).
It also decreases the chance that the story will “bounce” (god I hate that term, but anyway…). Bouncing is when under test, the functionality was not implemented as the requirements suggested subsequently the story goes back into development. Sometimes its ok, but frequent occurrence may suggest a bit of a problem – be careful not to place too much value on 'bounce counts' it can really kill team morale.
If we do this, what is the real benefit?
It means that the tester has performed the most important service that a professional tester can, that which is specialised to them, the rest of the test work should be able to implemented by developers, with some follow up by the tester.
The refinement of the story- very important step, often when this occurs late, especially after development – is very painful.
The list of test cases is important.
Some test cases are a quite appropriate for automation, some may not be and may need hands on testing, or working with integration points and data preparation that you may not have the ability to control.
It should be a warning sign that the tester never does anything later in the lifecycle. At some point they should be checking that all the boxes have essentially been ticked for the story to be complete. Sometimes its as simple as loading up a web page in a browser, a bit of a basic check followed up by executing the automation against an integration environment and seeing them pass, and bingo – complete story.
Be careful about roles. They are a guide, not a limiting definition.
Tester and BA, whoops I did it.
When using the approach I’m describing, the line between the two should be blurred- sometimes completely broken. I expect it; in fact I count on it.
The tester in many ways, behaves like a BA when they write test cases, test cases are requirements.
I’m sure some of you devs out there have had a tester come up to you about a problem for which you couldn’t see a requirement in the story. e.g. They tried to submit a form without entering anything in. The smart play by the tester is to go to the BA (or business in absence of a BA) and ask what the behaviour should be. When they agree with the tester, the test case is now a requirement. It’s that simple, end of debate, it was missing in the original story, and now it isn’t.
Using the approach I’m describing, the dev would never have seen the story without that requirement.
“but if you move a tester forward, you still have one resource, and they’re still constrained, how does that help?”
The answer is this, they are not the sole resource doing tasks that previously they were, and now these can be done by others more efficiently (devs are experts at writing code, testers are not, no matter how much we try to).
Additionally the tasks they do up front can be:
- Estimated and tracked easily, they’re just brainstorming and writing test cases (acceptance, functional, non-functional etc.)
- Have substantially less overhead as the tester wont be bogged down in one story, they’ll move through them rather more quickly, without compromising on coverage.
- The tester will become an expert on the functionality, reducing your co-dependence on your BA. When your BA is in a meeting with business, your tester will be around to answer questions.
- Can be done while developers are busy working on the current iteration.
While devs are implementing an iteration, the tester and the BA are preparing the next.
It will be painful during the first time through, consider an Iteration 0 for technical debt to assist if possible. - The test case list can be discussed as to whom should/could do it and be distributed. The automation may be done by devs, the manual tests may be run by business Subject Matter Experts (SME’s), if you’re still short, then you can talk to the business about getting more help in, it will be a quantifiable task list, should they decide not to, then quality is what they’re sacrificing, but at least they’re given the choice.
