Probably every tester would have missed a bug while testing an application. But whenever a bug is found on live environment, the game of pointing fingers begin. Usually, software testers and developers are at the receiving end of such blames. The project manager and the management team begins to ask: “How come you missed that bug?!” or “Who tested this??!”

Although, there’s a saying that true leaders ought to create a sense of togetherness for his team members such that everyone shares in the glory that comes when things are successful and such a leader should not apportion blames but take responsibility when things go wrong, but the truth remains that in software development processes, there is always someone that is accused and has to take the fall.

Most of the time where I work, the software tester is the one that is castigated for the bug on live environment. This has happened a couple of times to me and whenever this happens, I feel very bad for days and sometimes weeks. I begin to question my competence and my ability to pay attention to details. I often ask myself, ”How did I miss it?”, “What could I have done better?”

Every tester should realize soon enough that we cannot discover every bug while testing but this is a not-so-good excuse especially when the management or sales team discovers the bug at a very conspicuous place during a demo to a prospective client or the bug was just so glaring that anyone should have noticed so easily!

What then can be done as a tester to at least reduce this occurrence?

1. Have a plan: This cannot be overemphasized. No matter how sketchy this initial plan is, write something down whenever you are about to commence testing. All the possible scenarios, possible actions a user may take and may not take, the obvious test cases and the ones that are not too obvious, the high risk ones and the ones that are of little priority, take them down on a notepad and then later add flesh to them for proper documentation especially if you work where you are required to send your test reports or test cases to developers or and other members of the team

2. Don’t be afraid to ask for help or ask questions. Yes, don’t hesitate to ask another tester colleague to take a look at the application. You can do this without guiding him on the specific steps or scenarios you used while conducting your tests. Also, ask questions from the Project Manager and even developers (that’s if they are available and willing though) for all the possible cases you ought to consider while testing just in case you missed any.

3. “It was working on my local” or “I tested it, it was fine on test environment!” There are times you actually did test a functionality very well on test environment but ended up being that the same functionality began to throw an error or wasn’t responding on live environment. When this happened to me, I thought, maybe I should start recording myself testing all functionalities with screencast tools or taking screenshots to serve as an ‘evidence’ that I actually did test all the functionalities just in case things go wrong on another environment. I doubt that would solve the problem of issues occurring on live. One way I believe we can reduce this is to prepare a checklist we can use in doing a brief ‘smoke test’ when the application is moved to live or another environment to confirm that the basic and testable functionalities (not all functionalities can be tested on live because it’s ‘live’!) works as expected.

4. Do not make assumptions! Never assume a user to behave in a certain way. It’s better to prepare to accommodate such variations and unlikely scenarios than to be caught pants down.

One final thing I would like to address really is that it’s not the duty of the software tester/software test engineer/ quality assurance analyst ALONE to assure quality. It’s the collective duty for the whole software development team; front-end designers, back-end software engineers, software testers, project coordinators/managers. Not many software companies know this or actually implement this and so they blame the Software Test/Quality Assurance team for low-quality applications. The way the developer caters for exceptions to be handled, the way error messages are displayed, how data is input by the user, the number of steps carried out by the user to accomplish a simple task, the logic, the general look and feel all contribute to the quality of the application. Hence the need to empower and remind the developers and other members of the team that they also have a role to play in improving the quality of the software products.

I am looking forward to hearing from you guys. Cheers!