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
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.
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.