PractiTest QA Blog

A PractiTest customer was telling me about a problem they have with people not writing down their reasons when rejecting a bug, or writing unclear explanations in the Description or Comments fields.

I know exactly what she meant…  I also hate this issue plus the fact that since the data is in Free Text it is very difficult to track the reasons and keep statistics (in case you believe like I do in tracking this behaviour as part of an on-going improvement policy).

My solution is simple: I create a customized field called Reject Reason with the acceptable values for rejecting bugs in the project.  Usually these values are: Not a Bug, Not Clear, Unable to Reproduce, and Duplicate.

I find that by providing a list instead of asking my users to write down their explanation in free text they are more willing to comply.

Also since I have this as a structured list, PractiTest provides me automatically with statistics to keep track of my rejections and make corrections if needed.

I was talking this week to an R&D Manager friend who explained to me that they don’t really need the overhead and bureaucracy of a QA Team; and so he is willing to suffer some bugs, delays and rejects from letting his developers do all the testing, and tracking everything in one “simple” (but endless) Excel sheet he shares with his team.

Since I actually respected the guy I was shocked (and even a bit hurth!) by his comment.

My friend explained to me that his last “QA Manager” had come to the Company with some big backing from Higher Management, and he started wasting everybody’s time and efforts on endless meetings, worthless processes, and expensive tools that made people spend up to half their time in bureaucratic tasks and not on things related to the product or the existing customers.

In principle, this sounds very familiar from the years I worked and consulted for large Enterprise Companies.  And in many places this is the only way in which you can coordinate the work for tens of internal teams, hundreds of products, and thousands of developers & testers.  The big problem was the this QA Manager was hired to work on a 5-Developer start-up company…

We need to realize that our job as testers is to help the Organization based on its needs and constraints.  In the same way you would not use a Bazooka to Kill a Fly (chances are the fly would continue flying, but you wouldn’t), we cannot use extremely structured processes and complex tools to fit informal environments that need extreme flexibility in order to survive.

I know my R&D Manager Friend will grow out of his QA-fobia and will eventually find the right QA Tools and QA people for his company, but this is an example of a mistake we make again-and-again.
When we come to a new place / team / project we need to understand how to help and how not to hurt.  Our job is to work side by side with development to provide visibility via our testing efforts (thanks to Linda Wilkinson for her comment) into the product, project and process.

If our effortshurt the development process (more than they provide value to it) then we are definetly doing something wrong.

Many times when I need to write a new Test Case, run an Exploratory Testing task, or even write a new post for this site, there is a moment when we think I’m done, but deep inside I feel that I might have missed something important.

At these times I usually do a break and either go to a meeting, take on another short assignment, or simply take a walk outside to clear my head; and by the time I’m back I can retake my task find the areas where I still have work to complete.

I think that there is nothing like perspective to help us find our mistakes or the things where we can improve our work.  We use this principle all the time when we do peer reviews and walk-troughs, and even outside of work when we talk to a friend about stuff that bothers us… We use distance and perspective to look at the same problem from a different angle.

Still, you can gain distance and perspective even by yourself; you only need to find a way to switch context and return to your task from a different point of view than the one you were when you left.

This is one of those intuitive, simple and effective things that many of us forget to use.