TABLE OF CONTENTS:
The consequences of faulty software are widely recognized. Issues can range from malfunctions in Mars rovers and telecommunication system failures to sensitive data breaches and chemotherapy machines administering lethal doses of radiation. Given these stakes, it stands to reason that a skilled tester would be a valued member of any interdisciplinary software development team. However, it’s not always as straightforward as it seems. Why?
This question might stir the pot, but it’s worth asking because my answer is quite simple. There’s a common assumption that Quality Assurance (QA) engineers are individuals who aspire to be programmers but lack the drive or skills. While it’s true that some may view testing as a stepping stone to programming, the majority of testers I know are passionate about their work and genuinely care about the quality of the products they test.
So why don’t testers receive the reputation they deserve? Often, it’s due to not-so-great habits that many of us have encountered. Here’s a subjective list of 5 key areas to consider if you suspect your work isn’t being properly valued or recognized.
Let’s face it, we’ve all been there. A poorly described Jira story leaves everyone unsure about how a certain feature is supposed to work. A developer is tasked with fixing code that has no documentation trail. “Acceptance criteria? What acceptance criteria? Just run the application! If it doesn’t crash, it’s done and working.”
Really? How do you know the developer is right? If there’s a production failure, do you want to defend yourself by saying the developer told you so, and that’s why you closed the story?
Ask questions. Request the developer, analyst, or whoever is responsible to explain how the feature works and what changes were made. Ensure this information is recorded in Jira. Add acceptance criteria and specific agreements. Dig deep until you truly understand what’s happening. This way, you might uncover something the developer overlooked and send the story back for improvement.
Even if acceptance criteria are included (clearly specifying how a new feature or fix should behave), they are often written by the product owner or developer. These criteria are helpful and certainly better than having none, but they frequently only cover the “happy paths.” Not because someone is trying to hide something, but simply because no one thought about the edge cases.
Think outside the box! What could go wrong? Is there anything else a user might do that could generate errors?
When testing new features, we often encounter behavior that doesn’t make sense. It could be a button appearing in an unexpected place or a link leading somewhere it shouldn’t. When facing tight deadlines, we tend to focus solely on the “happy paths” and overlook or de-prioritize these odd behaviors. After all, the developer knows what they’re doing, and it’s probably the correct behavior, right?
Wrong! Trust your gut. If something seems off to you, it will likely seem off to the user, too. This could even become a reason why users abandon the functionality or, worse, the product altogether. Ask yourself what you would think of the product as a user, not just a tester. Be the guardian ensuring a good user experience. If your instinct tells you something is wrong, document it. If the application’s behavior frustrates you, strive to change it. Describe what you found and propose a solution!
Sometimes we get so fixated on finding a bug that we hinder progress by reporting even the most absurd “findings.” Instead of focusing on real-use cases, we pride ourselves on discovering behaviors a user would never perform, such as repeatedly clicking a single button, navigating back and forth multiple times, and then scrolling the page extremely quickly (but it’s fine if done slowly). And this is all on Chrome, in one specific version. Chasing this bug might have been fun, but consider how many real issues could have been found during the time spent reproducing this obscure and minor problem.
To be clear: it’s not about ignoring minor bugs because they seem insignificant. These issues can lead to unforeseen disasters. We should report everything, but when testing time is limited (as it usually is), we must focus on the most critical functionalities first.
Don’t chase bugs just for the thrill of finding them. Instead, concentrate on ensuring the software works well and is protected against malicious attacks. If you get carried away, ask yourself – is it worth it? Find the balance. Wouldn’t it be better to spend time checking real-use cases? And when time allows, of course, have fun. After all, finding bugs is a great pleasure!
Automation is fantastic, trendy, and highly desirable, but it’s not always the best solution.
When testing a new feature, dedicate some time to it. Understand it as someone who will actually use it. Allocate time for manual exploratory testing. Ask questions about how the feature can be used. Think about what a user might do with this functionality. Find bugs and report them. Only after taking these steps should you think about automation.
You know that the more steps a test has, the higher the likelihood that one of them will fail, leading to the entire process failing. This makes the tests unstable. Automated tests should be simple, and each test should check only one thing.
A tester is meticulous. A tester is picky. A tester thinks outside the box but can also take on the role of a regular user. This is why they are good at finding bugs. The result of a tester’s work must be the assurance that the user will use the product safely, easily, and intuitively. Only consistency and a focus on quality will allow us to build the reputation of an effective tester, earning the trust and respect of product owners, management, and developers.
