I recently read a blog here talking about the need to get testing involved earlier. I was particularly taken with this quote:

“Good test managers try to accentuate the advantages of early participation and working at the same time with development…”

Is this solely the preserve of the Test Manager, or can any tester accentuate these advantages – and just what are they anyway? As we seek to improve our craft we all need to think about what we’re doing, how we can do it better, and most importantly, what we need in order to achieve those aims. It may be that this needs to be escalated to the Test Manager, but often problems can be solved and improvements suggested much earlier on and without escalation.

Before we get onto the advantages, let me briefly outline what normally happens.

Testing is usually the final stage of the process before the users get their hands on the application, whether that is by going live, or by UAT. Ideally, testing and development should have proceeded so well that very few issues will be found (of course no application can ever be certified as bug free as complete testing is impossible)

As the final stage of the process, there are numerous associated issues.

First and foremost is that projects often have inflexible end-dates, and so as a project hits any delays, testing is the obvious candidate for being shortened – and if no phase is explicitly shortened, then testing is hit implicitly. That’s a well-discussed topic for another day though.

Second, is that testers are often late to the party. Documentation testing isn’t considered a part of the process, and the time devoted to gathering requirements, designing code followed by the actual development of that code is considered to be a lot of time for testers to be sat around ‘doing nothing’. The argument goes that testers can get involved later when all the documentation is finalised, or after development has started.

The issue with this is that most developers do not know how to test that requirements and design are accurate and complete, and that there’s no independent observer to cross-reference the two and ensure that the requirements are properly and fully covered by the design.

So, to try and mitigate against some of these issues, there is a concerted move to try and get the tester involved earlier. The benefits include:

a)      Testers by nature have an eye for detail. Getting them involved in reviewing requirement and design documentation is more likely to expose issues and get them addressed before they ever make it into code.

b)      If the testers are involved when the requirements are being written, then they’re likely to better understand them, leading to fewer questions later on, and better scripts written more quickly.

c)       By reviewing both the requirements documentation and the design documentation, testers are uniquely placed to ensure that the two line up, and that interpretations are consistent.

When presenting these points, draw on experience where possible too. I’ve written before about two developers next to each other coding a new ‘Priority’ field to be applied to two applications. One went for the values Low, Medium, High and Critical and the other went for 1, 2, 3 and 4. A lack of communication and reading each others’ work led to this error, but a tester working with them before the designs are committed to code, would have picked this up too.

Getting back to the original quote, these may well be points that a good Test Manager would make, but there’s no reason that any tester can’t suggest them initially. Remember that we’re not just trying to find bugs, but to contribute to the overall solution and increase the value that we add. So go on, think about what improvements you could make by being part of the project earlier on, then push for it to happen!

Advertisements