A tester should know when to Take a Stand!

We all love our programmers very much!  All of us are part of a superb development team and we are sure they do a great job.  And maybe most importantly, all of us (programmers and testers alike) only want the best for our users and the applications we develop.

Still, every once in a while, as testers we will run into situations where we realize our team is making a wrong decision and something should be done to correct it.  Whether this happens once a week or once a quarter varies, but I can promise you that wherever testers and programmers work together there will always be points of friction and subjects where we don’t see eye-to-eye.  The question is what do you do when stuff like this happens?


Saying “There’s nothing I can do!” is only the easy way out

Last week I was doing a methodological review for a PractiTest user (we provide this service for our customers on-demand, where we work with them to improve their testing & development process), when I noticed that not all his projects where progressing according to the flow we had defined together.

When I asked him why?  He replied:
“There is nothing I can do about it!  Sometimes programmers will simply take the code and push it to production even when I tell them that we should test it first.  This is just the way it is around here…”

What does he mean “nothing he can do” or “the way it is around here”?!?!
Isn’t he part of the team??
What’s going on here?!?!?!

The truth is that I was not really surprised.  I’ve seen it many times before and I guess I will see again in the future.  Sometimes testers feel overwhelmed and second-best to their development peers and are not willing to take a stand to defend the point they think is right.

Make your point strongly and intelligently

There is a saying in Hebrew: “It’s better to be Smart than be Right“.

I personally think a tester should try to be both (smart and right!), and in order to do this she needs to understand how to communicate and what arguments to provide whenever she wants to push one of her decisions with the rest of the development team.

Following are some situations I run into all the time, and how you as a tester can sale your point of view more effectively to your development peers:

1. When you think a bug should be fixed

When you think a bug should be fixed and not postponed to a later version you should approach the argument from a customer / market perspective.  Try to think of specific users (or user types) and how “you know” they will find this bug unacceptable.  You should try to use an argument such as “Bank ABC uses this feature extensively, and they will run into the bug at least 4 to 5 times a day”.

You can also use the argument of “a similar issue” that was reported from the field in the past and was fixed as a patch (instead of waiting for the next version).  You can then say for example: “Remember the bug XYZ we had 6 months ago, that was detected by Customer ABC, and we fixed as part of a patch because they could not wait for a formal version to be issued”.

In both cases your argument is that users will find this issue urgent and it is better to fix it now than to release the product and then issue an emergency-patch-fix later with all the overhead, the cost and the pain that come with them.


2. When you think a test should be run (or run once again)

This is the case where you think a test should be run, even if there was no time allocated to it.  A classical example is when you think that part of your regression tests should be run on all browsers and not only on IE (for example), or when you think the load testing suite should be re-run after a specific change in the product (even if it was already run before).  In both cases you are actually saying that more time will be spent on testing even though this was not planned ahead of time.

In order to allocate time for these cases you should talk about bugs that were found (either in testing or even worst by users in production) when your team did similar changes in the past.  Again, here the alternative is to release the product without running these test cases and missing bugs that will need to be fixed after the product was released to the public.

Examples of arguments to use on these cases are:
“Last time we ran tests like this we found 4 or 5 showstoppers no one expected to find”
“Remember when we last changed this function the response time of the server degraded about 200%”.

Whatever your argument is, it will need to come also with the reason why you now think that the tests should be run and why you didn’t think so before.  For example you can say that “in principle I thought about running only sanity, but in light of all the bugs we found on the different configurations I now think we should test in all of them full regression” or “even we already ran load testing in the past, we are experiencing bad response time even without load and I think we should evaluate this once again”.


3. When a feature should be modified or re-written

This one is similar to a bug that needs to be fixed but focused on the functionality of your product, that in your opinion will not suit what the customer is looking for.  Just like in the case of the bugs above, your best approach is to explain it from the point of view of the user, and it will be even better if you can provide the name of a specific user who will protest the current feature as it is right now.

But how can you know these things about your users???
I said multiple times before that as testers one of our tasks is to be the Customer Advocate within the development team; the reason for this is that we are the (only?) ones who constantly evaluate the product from an end-to-end perspective and based on the requirements from our end-users.  If this is the case, you should try to be as close as possible to your users and try be in contact with them to understand how they work.

When you think a feature should be changed you will need to use arguments such as “user XYZ works like this” or “remember that user ABC asked for feature XYZ to be modified because it was doing the same thing you want it to do now…”


4. When a version is not stable enough to be released

This is a hard one; sometimes you feel that even though the due date for the release is approaching we still need to run more tests even on areas we’ve already tested.

You can call it a hunch or a gut feeling, but sometimes I also have them and I’ve learned to trust them whenever they come. The hard part here is explaining to developers and project managers why you should spend more time testing areas you already tested.

Whenever this happens I do my best not to leave it as a gut feeling, but to understand what my instincts are trying to tell me.  In most cases it is related to the risk assumptions we made in the past and how after working with the product I feel that these assumptions may be incorrect.

Whatever the reason may be, once you are able to provide an explanation of the risk involved you will see how you team is more willing to make the effort and invest in the additional testing efforts.


Try always to provide hard data but also learn when to give up

When I want my team to change their minds I can try to boldly tell them that I am right and they are wrong, but this usually won’t work.

The best approach is to come up with “hard data” and “concrete examples” that will make it difficult for them to say I am wrong.  It is even better if these examples come from your current company and project, but you can also provide examples from previous projects and even from different companies where you worked int he past.


There are 2 important points to remember in these cases – when you think your team is wrong and you are right.

1. IT IS OK TO DISAGREE WITH YOUR TEAM AND YOU SHOULD MAKE YOUR VOICE BE HEARD.  Don’t hide behind the pretext that they won’t listen.  If you talk to a team member and he doesn’t want to listen, then go to the manager and tell him what you think and why!


2. EVEN IF YOU THINK YOU ARE RIGHT, YOU NEED TO KNOW WHEN TO GIVE UP AND EMBRACE THE DECISION OF THE TEAM OR THE MANAGER. After all, in the same way you can be right you might also be wrong, and as a team you should make decisions together and sometimes take risks and release bugs not because you want to work blindly or harm a specific customer, but because the business is telling you to work this way.

As I said before you should try to be both RIGHT as well as SMART all the time.

About PractiTest

Practitest is an end-to-end test management tool, that gives you control of the entire testing process - from manual testing to automated testing and CI.

Designed for testers by testers, PractiTest can be customized to your team's ever-changing needs.

With fast professional and methodological support, you can make the most of your time and release products quickly and successfully to meet your user’s needs.


4 Responses to A tester should know when to Take a Stand!

  1. Colin A April 26, 2011 at 7:17 pm #

    Great comments. This closely reflects my current situation. In time, the developers, the business team and and project managers will eventually trust your expertise and opinion, which will result in less in having to fight fewer battles anyway.

  2. joelmonte April 27, 2011 at 5:56 am #


    I think sometimes we are afraid of raising our voices because we want to “be part of the team” and not to attack our friends. But in the end we play by wearing 2 hats, the team-mate hat where we need to support everyone in our team, and the testing-professional hat where our task is to provide unbiased visibility into the product and the process (in order to help the team achieve it's objectives).

    It may be easier to be always the nice fellow who doesn't bring forward criticism, but in the end we are harming the team…

  3. (Q)Ade. June 1, 2012 at 1:25 pm #

    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.

  4. joelmonte June 3, 2012 at 12:39 pm #

    Thanks for the feedback!
    Still, I will need to disagree with you on this one, specially because of the same argument you are stating.  How can the QA be the headlights of the project, highlighting the impediments to success, if he does not understand the business and maybe most importantly if he cannot serve as an internal customer advocate?If he does not have enough knowledge to have an opinion on the priority (not to say the severity) of a bug, then he will not be able do discern between the important and the unimportant (and by this I focus importance from the business perspective!) aspects of his product, and so he won’t be able to focus his work and that correctly.Obviously, and maybe this is the part that is not so obvious, in the end the whole team lead by the Product Management or the Business Team, should make the final decision.  But the QA Team member can and should have an opinion, and he/she should also know how to communicate this opinion and learn to defend it in front of other members of his team.What do you think about this?

Leave a Reply