5 Major Sins of Working With Testers and Developer

Having the opportunity to work as a tester in a large corporation, I feel incredibly fortuitous. I continue to appreciate the luck I carry to immerse myself in what I affirm is the most pleasing profession on the planet.

The task at hand is rewarding but challenging, which in my view, is a significant plus point.

Simultaneously, it affords me the luxury of being the first to lay hands on emerging technologies and prototypes that are yet to land in the hands of the general public. And then, there exists a widespread belief that I am paid to “shatter things” and my persistent efforts are appreciated.

The preceding point was a jest, of course. Nonetheless, most testers that I know derive satisfaction from their tasks and rejoice in their testing roles.

Sadly, existence isn’t always a smooth ride. Even the most delightful ventures have its own array of challenges and troubles. These obstacles are universally known among people in the IT sector, but strangely enough, there seems to be a hesitation about actively acknowledging them.

A part of the restraint might be due to the unwillingness to step on anyone’s toes. However, some people view it as a matter of prestige, rejecting the possibility that their shortcomings could be highlighted. Our expectations lie in the hope of them adopting a more practical outlook, but this will only transpire if someone has the courage to openly address the issues.

This is the point where my tale takes flight, triggering the substance of this article.

Let’s devote a brief span to deliberate on the most annoying experiences testers run into in the complex and captivating domain of software development projects.

Recommended read => Perceptions of “Testers” and “Developers”

Five of the Gravest Offences Committed Against Testers

Let’s enumerate the topmost five offences committed against our lot:

#1) Being Egocentric

The first violation comes from developers who are engrossed in minor stuff like borrowing devices to recreate issues/glitches.

You’re accustomed to thoughts where a JIRA ticket is assigned to a developer, and you have scrupulously ascertained the issue’s existence and its reproduction method. You have stated all this inside the JIRA ticket, and then you shift your focus on your daily tasks such as sanity testing, monkey testing, or performance checks.

Suddenly, your prime opponent— the developer— presents himself and requests you to hand over the MUT (mobile under test) because he now can spare time to rectify the issue. This wouldn’t be much of a problem if your hands were not occupied with numerous other high-priority tasks that can only be recreated on that specific device with a distinctive system build label. But being a considerate person, you lend them your device hoping they truly will fix the issue within the “next 20 minutes.”

Naturally, it never happens that way.

Moreover, they fail to return the device to you, making you accountable for reclaiming your belonging. Also, for a reason that beats me, developers don’t seem to comprehend the idea of charging their mobiles. It’s exasperating when you collect your MUT only to find that it’s left with a meagre 10% battery, rendering it useless for your work.

The solution is quite uncomplicated: Esteemed Developers, I implore you to connect your mobiles to your PCs and keep in mind that you are not the sole contributors to the project.

#2) Being Troublesome

The second misdemeanour is perpetrated by our co-testers themselves, especially that one tester who is always working remotely alongside us. I am certain you can instantly recognize who I am referring to.

Throughout my professional journey, I have enjoyed the company of colleagues from different nationalities – Chinese, Indian, Irish, English, Polish. But the theme remains continuous, with one individual who continually presents “fabricated” issues.

The problem compounds when the person re-opens tickets for obsolete devices and platforms (think Android 4.4 from third-party phone manufacturers). And then there’s this peculiar habit of declaring an issue “reproduces 10/10 times” even when no other person has had a similar issue for quite some time (if at all).

The answer to this is fairly simple: ask them to present a recording of the problem. It’s surprising how often the problem magically vanishes when asked for a video recording, culminating in a “I can’t reproduce it now, please close the ticket” situation.

#3) Being Disjointed

The third offence is committed by those responsible for developing websites and programs to improve testing and development. You might question, “Why would that be objectionable?” They utilize countless hours to prepare something useful, so why the criticism?

Well, my grievances do not lie with the process itself or their noble intentions, but it is focused on the delay and inertia when it’s about optimization and offering comprehensive tutorials about “how to utilize the software”.

It’s infuriating that I must download a program and, at the same time, ensure that I have the latest update for some package. Even so, it would be beneficial if they considered that the software may not be compatible with the latest version of the language (Python 3 versus 2, for example).

Additionally, why is it that one software works for one person, but fails for another even in the same environment? The error messages can be absurdly cryptic, forcing you to dig through Stack Overflow in search of an ancient post from a user who experienced a similar problem five years back and figured out a solution by meddling with the registry. Not very delightful.

But then, when you opt to uninstall everything and initiate from the scratch, you find that some packages have disappeared in translation while others are concealed in esoteric folders, and so it goes.

By the way, why are some tutorials so complicated and daunting to follow? As testers, we follow specific guidelines when creating tickets or test steps – the information should be direct, the steps should be simple enough for anyone with minimal knowledge to replicate, and they should produce the exact same result.

So why aren’t these tutorials designed in the same manner? Is it truly that complex, or could it be a mere lack of empathy from those who create them?

Hence, my appeal to those currently crafting the next revolutionary software is to submit their final product for assessment by someone other than a developer. They’re likely to reveal more inconsistencies than you can ever envision. Believe me – we just want to learn how to correctly install and use your software to assist others with their jobs (automation, BDD, TDD, etc.)

#4) Being Incompetent

The fourth transgression is again attributed to developers and revolves around clumsy unofficial fixes.

Often, we hear assertions such as, “Don’t worry, I can patch it up in a few minutes, and you can vote for me in Gerrit.” But, the haste associated with these patches and unofficial fixes usually creates ten new bugs that were non-existent before the patch was applied.

Of course, the official problem reporting process is followed eventually, but then we hear bouts of complaints about deficient documentation, lack of information, or unsuitable work environments. But honestly, dear developers, if you have the build labels, AHA (Android host application), FW (firmware), system data, phone model, number of attempts, exact reproduction steps, logs, recorded videos, screenshots, and additional files attached to the ticket, what else do you need?

I understand that bug fixing might seem mundane to some of you (indeed, creation is more enticing, right?), and some of you might even like to avoid dealing with non-deterministic issues (NFC and Bluetooth, did you hear me?). However, keep calm and collaborate with us. We are working towards the same goals, after all.

#5) Being Disturbing

The fifth and closing violation is committed by people like myself who operate in open spaces.

To begin with, whoever thought it was a smart move to cluster a group of dynamic, spirited people together in a room devoid of partitions? My good lord, it becomes incredibly unsettling when the person seated next to you is giggling, coughing, conversing with a colleague, or even chewing on a gum.

Have you imagined how annoying it is to overhear someone’s “quick phone call”? The incessant barrage of noise and interruptions can disrupt concentration and make it near impossible to regain focus.

I don’t hold people at fault for being social beings who find joy in engaging with others, but could everyone endeavour to lower the volume a notch or two?

Although this might not bring peace to the galaxy far, far away, it could marginally boost productivity, which could be just sufficient to ensure everyone’s contentment.

And there’s nothing more delightful in the world than a congenial work atmosphere. Well, maybe apart from pancakes and bacon. Both are magnificent. 🙂

Also read => Significance of Tester’s and Developer’s Communication

Final Remarks:

Let’s endeavour to remember that operating in a cooperative, cordial environment can generate markedly more positivity and synergy. The more we remember that an open workspace is a shared space and strive not to be troublesome, the more we will reduce stress and derive joy from our projects.

About the Author: This article is offered as a guest post by Marcin Sikorski, an ardent mobile testing fanatic who is actively participating in the smart devices industry.