This is the last article of this topic and I really enjoyed writing these series, they did surprised me a lot some of the topics came in a different way, that I imagined. And of course these 7 points or virtues, as I first called them, are just my viewpoint, I don’t consider them to be right or I think it’s just that. I think it’s much more complicated than that, but I will let you figure it out on your own. As last topic I decided to speak about the attitude that a tester should have in a software project and I called it “Trust no one” attitude. Yes, some of you might noticed the picture, it’s from “The X files” series and if we think about it, software testing has a lot to do a lot with crime investigation. We have to question everything, we have to investigate, we have to report, sometimes we have to just leave a defect and move on, it’s an exciting job, being a QA. That’s where “trust no one” mind set jumps in, we have to question everything and trust nothing, not even ourselves. It’s the only right and valid way to stay curious and efficient.
“Belief is a sin for testers.” James Bach
I adore this quote from James Bach, you could actually watch the whole lecture on youtube. And I will expand the quote a little bit like this. “We are not in the belief business”. Well, very well said. It is totally wrong to trust anyone, even yourself. And as James stated in his lecture this has nothing with respect, understanding, teamwork or applying your company’s’ policy. Best definition for this mind set will be – don’t take anyone’s words for granted.
So what are the key points in avoiding “blind trust”?
Don’t trust the devs.
Well, I think this is an obvious one. Not that software developers are “the enemy”, they are our colleagues after all, but don’t forget we are getting payed to report their errors. And since there’s human writing the code and human designing the app’s logic, we don’t have strong evidence to believe things will be perfect. That’s why we have to be sceptic to everything that’s introduced to us as a new feature or fix or a piece of programming logic. It also helps a lot to ask questions about anything. Can you frustrate people easily? Sure thing, but that’s how you are going to tell the good prоffessionals from the bad ones. A good developer assumes he/she might be wrong and will rather approach you with the words “I need you to test this really well’, instead of saying something like “You don’t need to test this, it’s working as expected”. And asking devs good questions might actually help them understand their tasks better. If a person can’t explain what he has done to make something work or what’s the logic behind it, he probably has no idea what has he done or what magic keeps it working, yet. Of course I am not saying you are allowed to ask dumb questions, but anything that’s meaningful for you and the project will be in yours and developer’s favour.
Another good point to avoid trusting the devs is that they are sometimes overwhelmed with tasks and if they are working on smaller projects it’s possible that they work on a couple of them. Don’t trust anyone that will tell you “Don’t bother logging that defect, it will be waste of time. I will fix it in 5 mins.” Just tell this guy it’s not gonna work like this. Small fix or not, all defects should be documented for yours and everyone’s sake.
And of course all this should happen in a respectful and professional manner. Your scepticism, shouldn’t offend people, it just have to encourage them to perform better and demonstrate their knowledge and professionalism.
Don’t trust your managers.
And again I might look like a fuckin’ anarchist with these words, but this has nothing to do with respect or company loyalty. It has to do with results, and if you want them you need to be that person always asking the right questions and not trusting anyone. Managers, might be your direct managers or project managers or team leads, are normally pretty busy – they are jumping in and out of meetings, reading mails addressed to them by their managers, replying to people asking them for advice or assistance and to be honest sometimes playing “mommy” for someone who got confused or frustrated or whatever. Having this in mind it’s too ambitious to believe that a manager or team lead will recall what he promised to do for you or to research for you or provide you with the information you needed. So, it’s completely Ok not to trust them, that helps you and helps them, just keep on reminding them until you get what you need. And it’s not rude to do it, if you do it in the proper manner and if you let people know that it’s team’s goals that drive you doing it.
Don’t trust yourself.
Would be a bit hard without that. As stated above we are human as well, hard to believe, but a fact. And since we are human we make mistakes, too. The thing is if we do a mistake, we screw everyone, because we have to be the ones to give the last call. That puts a great responsibility on our shoulders and that’s why I believe our scepticism should be at it’s biggest part directed to us. We may do so many mistakes being testers – we might consider working parts of the application being a defect by not knowing the requirements well enough, we might report false defects, we might write false test cases or even worse – test cases that rely on false input. As you can see, there’s pretty much things that could go wrong at some point and they all depend to no one but us. So my advice is – always try to double, triple or n-ple check what you do and how you do it. Assume that you are wrong and attack yourself from any possible angle.
Ask questions! This is very important. A good QA always has questions, if you go to a meeting and you leave without asking any questions you were either bored to death or were playing with your phone the whole time. You will always be rewarded for going in details when it comes to application logic, testing approach etc.
So that’s it. For the post and for the series. Don’t trust anyone, even me. Feel free to oppose me, comment, ask and share with your friends.
Good luck. 🙂
Mr.Slavchev
Senior software engineer in testing. The views I express here are mine, they don't represent any position held by any of my employers. Experience in mobile, automation, usability and exploratory testing. Rebel-driven tester, interested in the scientific part of testing and the thinking involved. Testing troll for life. Retired gamer and a beer lover. Martial arts practitioner.
Follow Me: