Today I’m following-up on a comment left two weeks ago by (Q)Ade on a post I wrote called “A tester should know when to take a stand!“.
To save you the “searching” I’ll copy the comment here.
“On Point 1 (When you think a bug should be fixed) I have to disagree here. it is not the job (or even within the remit) of QA/ QC to determime whether a particular bug *should* be fixed or not. QA simply do not have access to enough information about the business to make this kind of judgement call. As Kaner**, et al illustrated, the role of the tester is to be the ‘headlights’ of the project. QA highlights the impediments to success, but it is the role of production/management to decide what (if any) resources will be dedicated towards resolving a particular issue. Otherwise, we drift dangerously close to the ‘Sentinels of Quality’ mindset.”
(** James Bach commented that the headlights metaphor was originally his.)
I want to thank (Q)Ade for bringing his point of view forward (BTW, any person citing Bach or Kaner on my blog will always be more than welcome). But to the point, as much as I respect his opinion I will have to disagree with it.
Even a “Blind” Gatekeeper has a point of view:
I loved the movie Thor (although I only got to see it on a plane while my kids slept). One of the characters I liked best was Heimdall, the “blind” gatekeeper.
To quote a comics blog “…he sees in such a different way from the rest of us that he counts as blind” (I could say the same about a couple of testers in my past teams!!!).
Although this guy was “only” a gatekeeper, and he had to obey his king Odin by banishing Thor to earth, he still used his common sense and allowed Thor to return when he understood the situation called for it (C’mon! Heimdall even broke free from the ice Loki used to freeze him!!!).
But enough of Thor and my geek-e-ness…
The point here is that even a gatekeeper should have an opinion, and exercise discretion to decide who enters and when. If not, it is simples and cheaper to put a lock with a key and forget about it!
We are not gatekeepers and not headlights, but Intelligence gatherers.
But back to testing and the comment by (Q)Ade… Testers should not act as gatekeepers, we are not paid to stand watch and stop bugs from walking out the door (or even to concentrate solely on seeking bugs like hounds hunting a fox!). This approach is both impractical and unintelligent.
If gatekeeping was the only alternative, then I would agree with the definition of been the headlights of the project. But personally I think this “headlights” analogy also falls short of our potential value as testers in any Organizations.
I stated in the past that I see the role of the testing team like that of the Intelligence Arm in any modern army. We are in charge of gathering information from multiple sources (tests, bugs, metrics, schedules, emails, etc) and providing visibility into the status of our product (good/not-good) and our project (on-target/not-on-target).
Like Intelligence operatives behind enemy lines we are in charge of carrying out predefined operations (e.g. load test a specific component to check it can ramp-up to 500,000 visitors) but also of finding the important information based on our professional knowledge and individual experience (e.g. running ad-hoc customer scenarios based on scripts gathered from the support team reports).
In this case, the headlights approach is not a good one since headlights ONLY focus on the path ahead of them, and do not have the flexibility to look at the sides of the road or advance 100 or 200 meters to look for hazards that are there but will get in the way only eventually. We need to have our own independent points of view, and to be able to choose what to test and how to test it.
Understanding our place as part of a Project Team
How is all this related to defining the priority of a bug???
It is directly and indirectly related to it, let me explain.
If we agree that Testers need to understand enough of their projects and their products to define (at least part of) their testing activities independently, then this means that they have both the technical and business knowledge required to make these decisions. (I know that not all testers are given the freedom and responsibility of defining their tests and tasks, but most of us do get this freedom even if the extend of it can change from project/company to the next).
And if the testers achieved this level of knowledge (technical and business), then this means that they can have an opinion of the priority of the bug. As simple as that.
Notice that I didn’t say that we as testers should single-handedly define the working schedule of our projects, but we can/should share our thoughts and help the team decide what bugs should be fixed and when. This is also the reason the QA Manager (or a representative of the Testing team) is always part the bug triage meetings.
Theory to practice – how to influence the priority of an issue?
So moving to the practical realm, this is what I think you should do in cases when you find a big problem (e.g. a bug!) and your team does not agree with you regarding its priority:
1. Don’t Panic!!! And I mean it, by looking like someone heralding the end of the world you won’t help your cause. Remember that once all this is over live will continue (even if the bug is released).
2. Try providing the view of the issue from the customer perspective. Talk about the inconvenience or damage the issue will actually cause the users and how will this affect their perception of your product or service.
3. Provide a quantitative and not only qualitative analysis. Try to come up with estimations, not only of the suffering by the individual user, but also of the number of the users that will be affected and/or the financial impact of this specific issue to the project or product.
4. Look for past examples of similar issues and what was the damage they did when released to the field.
5. Consult with other teams in your organization and gather their point of view. For example contact your product support or your sales teams and discretely ask for their opinion. Just make sure to talk to the *smart* people in these teams (those who understand that if you fix a bug then most probably you will delay a product) since it is very easy for them to think that “all bugs should be fixed” no matter what.
6. Don’t be afraid to raise your voice respectfully and in the proper forums. Ask your manager to let you come to the Bug Triage meeting or to the project status meeting. Sometimes it is even more convenient to ask for a meeting with the project manager to talk about the issue and present your point of view.
Make sure to listen and not only to talk!
Still, in the end you are part of a team, and as (Q)Ade wrote, sometimes you will not have all the business information required in order to make the proper decision. You need to learn to listen and in the end to accept the responsible decision of your team.
I’ve seen testers who make a full of themselves simply because they refuse to listen to the legitimate points raised by the other members of the team. These testers are the ones who end up acting as children mad at their parents because they won’t buy them the Big Teddy bear in the store…
Remember, you are not the gatekeeper and so you are not responsible for stopping the bugs from walking out the door!
(*Image by FreeDigitalPhotos.net, Marvell Studios)