Free eBook - The Road to QA Excellence - Download now

C’mon!! If you have something to say, get up and say it!

By on June 19, 2012 in Communication, Management, Testing Intelligence

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.

(Q)Ade wrote:
“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:

Heimdall (from the movie Thor, by Marvell Studios)

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)

About Joel Montvelisky

View all posts by Joel Montvelisky →

,

  • http://twitter.com/TestSheepNZ Mike Talks

    Good post – lots of interesting points there about being the gatekeepers.

    Totally agree on “Don’t Panic” or what I call Chicken Little testers (the sky is falling in) – it can not be helpful.

  • james bach

    Hi Joel,

    The headlights metaphor comes from me, not Cem.

    I think you are taking it too literally. Obviously, by headlights, I do not mean that testers should actually cling to the hood of a car. What I mean is that testers provide “light” that allows the “car” to travel quickly and safely in the darkness.

    As a tester, I can give my opinion of quality problems, of course. I can argue that a bug should be fixed. The important thing is that I not lose sight of the fact that– in my role as a tester, anyway– I am an agent for my clients. I strive to be a good agent. That means I am thinking about what my client (not me, personally) would consider an important bug, if they were acting in their own best interest.

    If I believe a bug should be fixed, I will push for that. But the moment I believe my client understands my argument, and yet disagrees with it, I must stop pushing. Otherwise I deserve to lose credibility as a tester.

    – James

  • joelmonte

    Thanks Mike,

    I liked the mental image of the “Chicken Little testers”, I may even use it in the future :-) Thanks!!-joel

  • joelmonte

    Hi James,

    Point taken about the headlights metaphor been yours, will add a clarification to the post.

    Regarding my taking literally the metaphor, you are right about that, but the core of the post is not so much about the metaphor itself as it is with the comment that used it.  Where the argument was that we (testers) don’t have the tools to talk about prioritization, and so we should not speak our minds on that.

    I think that your comment shows we are close in our opinions here, we both think we need to provide our professional point of view, and we both understand that some (or even many) times we will need to “let go” and do what our customers, or in my case our team, decides.

    My underlying point is that I think there are testers that apply some intentional self-blindness, and in some cases keep quiet even when they understand something big is wrong, only because they feel it’s not part of their jobs, and they don’t want to risk been seen as out of line…

    I believe it is our duty to speak up, and at times even swing the line, if we have something in our minds.

  • Hadar

    As I was reading your post I could actually hear the voices and see the angry faces of the QA manager versus the R&D manager in a laud ego-trip argument. I agree that the panic is not at all helpful but I can imagine where it is coming from – many times, if the bug is fixed or not is not as important as who’s arm was twisted harder. The day testers and developers will finally understand they are on the same boat, the panic will vanish. 

  • joelmonte

    Hhmm, I think that at least in most of the times where I, as a QA Manager, was involved in an argument with my Dev counterpart where not so much about ego, but about who understood the customer situation better.

    An important thing to take into account is that Developers, given the nature of their work, are not able to decouple themselves from the technical aspects of fixing an issue (or developing a feature this vs. that way).

    I remember catching myself more than once asking the Dev Manager “did you even think about the User before saying this last sentence or did you just think about the technical aspects?!”. 

  • Pingback: Five Blogs – 20 June 2012 « 5blogs

  • Kuznetsova Victoria

     And just when I finished reading the post and wanted to write that your opinion isn’t that different from what James, Cem and Michael are saying, James himself did it. :-)

    I just want to add that in my opinion it’s good that testers do not make decisions about bug being fixed or feature being implemented. And it’s not because testers know product badly or smth like that – it’s because we don’t have the power to make our decisions work, and if we do – we are not testers, we are also product managers.

    When I hear “testers should provide information” I understand it as “all information they can provide to help the product”. It implies that tester sets initial priority of the bug, it implies that tester participates in planning meetings of different kinds, and it also implies that when tester strongly disagrees with his team about bug priority, he must tell why exactly he disagrees and what he thinks would be the concequences of not fixing the bug.

    But if tester provided his expertise and explained himself but his team still thinks bug is a minor – it’s ok to retreat. Maybe he is wrong after all. And even if he is not – if product manager is willing to take that risk, it’s his call. We are here to work as a team, not to play in “who is the king today” game.

  • http://www.practitest.com Joel Montvelisky

    I think that reading your comment we are both saying the same thing (also), we should set up the first priority, and then if for some reason your team disagrees then you provide your inputs and try to convince them of your point of view, but in the end it is up to the team to decide.