The tester role might be fun, but it does come with a share of challenges. Look at some of the major sins of working with testers and developer.
Working as a tester in a big corporation was probably the best thing that happened to me in my career. I can’t tell you enough how lucky I am to do the most enjoyable work in the world.
However, it can also be quite challenging at times as it requires a constant gain of knowledge (which btw, I think is a huge asset).
On the other hand, you are the first person in the world to hold in your own hands the new technologies and prototypes that reach the mass population in the future. Not to mention, the popular idea that people pay you to “break stuff” and the more annoying you are, the better.
Of course, I’m kidding about the annoying part. But most testers I know are happy with what they are doing and enjoy their testing career.
Table of Contents:
Major Sins of Testers and Developer
Unfortunately, life isn’t always rainbows and sunshine. Even the most enjoyable things can have issues and problems. The existence of such drawbacks is known to people working in the IT industry but for some reason, they are not willing to spread the awareness about it.
Part of it is due to the fact that no one wants to hurt anybody’s feelings. But for some, it is a matter of pride that they don’t want to be pointed out for their flaws. We have to hope that they will change their attitude and be realists – and, they won’t do it unless somebody pokes at them and speaks honestly about the problems.
And this is where my story begins and so does this article.
Let’s then take a few minutes and talk about the most annoying things that happen to us testers, in the wild and strange world of software development projects.
Recommended read => Perspective of “Testers” and “Developers”
Five of the Biggest Sins Committed Towards Testers
Here’s a look at five of the biggest sins committed towards us:
#1) Being selfish
The first sin is by the developers and it involves small things such as borrowing the devices to reproduce the defect/problem.
You know the feeling when a JIRA ticket is assigned to a developer. You will double check the version where the issue exists, how to reproduce the problem, etc. You included all that information in the JIRA ticket and now you are doing your daily tasks like sanity, monkey or performance testing.
All of a sudden comes to your arch nemesis – developer – and asks you to give him the MUT (mobile under test) because he now has time to fix the problem. It wouldn’t be a big deal if you weren’t assigned to at least dozens of other hot issues reproduced specifically on that one device with a unique system build label. But you are a good person, so you give him your work tool in the hope that it will be true that it will take him “only 20 minutes to fix the problem”.
Of course, it never does.
Besides that, he never comes back to you so YOU are responsible for taking back your property. Also, for some bizarre reason, the developers can’t grasp the idea of charging the phone. I hate it when I take back my MUT and discover that there is only 10% battery left and now I’m the one who is blocked with my work.
My solution is simple – Dear Developers, please, for the love of god, plug-in the phones to the PC and don’t forget that you aren’t the only people working on the project.
#2) Being annoying
The second sin is committed by our testers themselves and more specifically that ONE tester working abroad with you. I bet you know exactly who I am talking about.
In my career, I’ve been blessed to work with people of many nationalities – Chinese, Indian, Irish, English, etc. – but whoever I was working with, I was always stuck with at least one guy who always had some “made up” issue.
It wouldn’t be a problem if it wasn’t for the fact that this type of person reopens tickets for obsolete devices and systems (android 4.4 for some 3rd party phone manufacturer anyone?). He also has a strange trait of writing down “this problem reproduced 10/10 times” even if no other person had had such an issue for a long (if ever) time.
There is a simple solution to that. Just ask him to record a video of the problem. You would be surprised how many times it has been resolved in “Now I can’t reproduce, please close the ticket” situation.
#3) Being disjunctive
The third sin is by those people responsible for creating websites and software to improve testing and development. Wait, hold on. “How is this a bad thing?”- You might wonder. After all, they spend countless hours creating something useful and I’m still complaining?
Well, I am. Not about the process and good intentions, but the tardiness and laziness when it comes to optimization and writing down tutorials on “how to use the software”.
Oh my god, I hate this so much when I need to download one programme but then I also have to have the latest update of some package and it would be great to also keep in mind that the software might not be backward compatible with latest language version (python 3 and 2 – I’m talking about you).
How is it possible that for two people with the exact same environment the software works in one and fails in the other? There comes the dumb error messages which tells normal people nothing so you have to dig in stack overflow to find the topic in which one guy had a similar problem 5 years ago but he was able to fix it by rummaging the registry. That’s really, really great.
Then, when you come up with a smart idea to uninstall everything and try to start from scratch, you will be surprised because some packages will be lost in translations and others will be hiding in some unknown folders and so on and on and on.
Also, if we are on this topic, how is it possible that tutorials are sometimes so clumsy and hard to read? I mean we, as a tester, have some rules when it comes to creating tickets or test steps – information needs to be simple to understand, logical to reproduce even by someone without advanced skills and the steps should result in the exact same final result.
So why, oh why, are those tutorials not this way? Is it so difficult or maybe there is a lack of empathy from people preparing those?
So, to the guys making the next big software right now, I want to say – give your final product for review to someone who is NOT a developer. He will probably see more inconsistencies than you. Believe me – we only want to know how to install and use your software correctly to help other people with their tasks (automation, BDD, TDD and so on).
#4) Being clumsy
The fourth sin is again by the developers and it is all about clumsy unofficial repairs.
“Don’t worry I can do it in a few minutes and you can give me +1 in Gerrit” we hear this from time to time. The problem is that this fast patching with unofficial fixes equals the creation of 10 more bugs that didn’t exist before the patch.
Of course, it usually ends with the official way of reporting problems but then we hear that the documentation has flaws, there is not enough information, workplace etc. But honestly, dear developers, if you have labels of the build, AHA (Android host application), FW (firmware), system, name of the phone, number of attempts, exact steps of reproduction, logs, recorded movie, print screens and even additional files attached to the ticket then what more do you need?
I do get that some of you hate to do boring fixing (creation is better, right?) and you prefer not to hear that the problem is non-deterministic (NFC and Bluetooth issues, oh how we all love you) but stay cool with what you do and cooperate with us. We are, after all, in this together.
#5) Being noisy
The fifth and final sin is by me and people like me working in open spaces.
First of all who in the right state of mind had an idea to put a bunch of young, energetic people in one room without any walls between them? My god, this can be very annoying when the person next to you is laughing or coughing or talking with another colleague or even chewing gum.
Or can you imagine how annoyed you get after listening to someone’s “short phone call”? This never-ending sound bombarding and interruption may cause lack of focus and even make it impossible to get back on the right track.
I’m not blaming people for what they are (social creatures that do love to interact with each other) but can we all try to be at least a few decibels quieter?
This probably won’t restore peace in the galaxy far, far away but it might help with productivity just a little bit and that, in the end, might be enough for everyone to be happy.
And, there is nothing better in the world than an enjoyable place to work. Well, except maybe pancakes and bacon. Both are marvelous. 🙂
Also read => Importance of tester’s and developer’s communication
In conclusion:
Let’s try to keep in mind that working in a friendly, cooperative environment could bring a lot more positivity and synergy than anything else.
The more often we remember that we are not alone in the open space and try not be a nuisance at the workplace, the less stress we will have and enjoy our projects way more.
About the Author: This is a guest post by Marcin Sikorski. He is a mobile testing enthusiast actively involved in the Smart devices industry.
What are your thoughts about this article? Do you have any feedback/queries? Feel free to share them in the comments section below. We would love to hear from you.
Very true! Some of the instances mentioned in article brought smile to my face and can totally relate to them!
Seeking testers for the company ?
Ah the dreaded open-office environment. I too want a quiet work environment and wish everybody around me would shut the heck up. But ultimately those people have a job to do too, and they probably have poor quality conference calls they need to talk on… and often the only way to be heard is to talk louder than the loud people next to you.
The only way this will change is if employers realise they need to treat their staff better and give them the tools required to do their job (in this case, a quiet work environment away from people who need to talk all day).
I agree on of off the above points, and especially the last point being noisy, that just so rude. You can also add one more point, some people I come across don’t do the basic R &D before asking questions. The moment they get question they’ll ask without evening thinking that it could be in the user manual, or it can be googled, and ask all the irrelevant questions, the list goes on. Then there are managers who just are good enough for sending status report, but can’t write a descent test when they are required, then they come up with “brilliant” ideas when they don’t even know if its required.
Truth has been spoken!!!
In spite of all sins mentioned; what I think is, we(testers) need to be more Diplomatic to avoid such kinds of situations. what you say vijay sir?
very practical experience
Very well said.
Good read!!! Very neutral article..no body gets hurt and point well conveyed and written..
@George, I expect that within a month there would be some requirement coming up, will post soon
Nice article, i like the selfish point as testers as well must get red of this bebaviour among us first.