Testing Is Not Just About Finding Errors, It's About Clarifying the Issue

Sometimes, a bug can go back and forth between the developers and QA several times.

"I don't see a problem on my end," or "There's still an issue, you need to check again" — this kind of conversation is pretty common in QA daily work.
After a while, you start thinking: besides just finding errors, is there something more a QA can do to help clarify the issue faster and reduce this back-and-forth?

This post shares a small example — not a particularly tough bug, but it’s a good illustration of how the experience level of the tester impacts the way a bug gets reported.
What I’m trying to show is, with different experience levels, the way bugs are reported varies, and these differences often make a significant impact on how quickly an issue can be resolved.

---

Bug Example: Contact Us Link Not Working

Website: https://prod.dvcbot.net/login
Problematic Link: Contact Us

---

Beginner Tester’s Bug Report

Title: Contact Us Link Not Working
Steps: Click on Contact Us
Current Behavior: The browser opens a new tab, showing about:blank
Expected Behavior: Should open an email application

This kind of bug report isn’t wrong, but it’s hard for the developer to reproduce the issue. The problem may not show up on their end, which leads to the bug being sent back to QA.

---

Intermediate Tester’s Approach

In addition to the basic description, an intermediate tester might:

• Check the Contact Us link (mailto:aide.support@mediatek.com)

• Test it across different browsers (Chrome, Edge, Firefox)
  

  

• Verify if the browser blocks popups or supports mailto links

These details will give the developer a clearer direction and might help reproduce the issue.

---

Senior Tester’s Approach

A senior tester, having more experience, would consider whether it’s an issue with the system settings.
In this case, it turned out to be a problem where the operating system wasn’t set up with a default email application, which is why the mailto: link wouldn’t work.

This is a subtle issue — it’s not a browser bug, nor a system error, but rather an environment configuration problem.
By adding a note like this in the bug report:

The test machine does not have a default email application set up, so the mailto: link fails to open.

The developer can quickly focus on the real issue, reducing back-and-forth time.

---

The Value of QA: Sometimes It's in the Details

We are often focused on "finding issues," but the real value lies in "clarifying issues," helping developers focus on solving the right problem.
This isn’t something AI can do, but it comes with observation, reasoning, experience, and a bit of patience.

 Do You Start Testing Right After Receiving the ZIP File? I Prefer to Verify First.

When we’re testing, we often receive ZIP files from engineers, either via cloud links or shared through communication software. It’s quite common to get a file and just dive straight into the testing process.

I used to do the same, but after a few incidents where the contents of the ZIP file didn’t match the expected version—sometimes the version was outdated, or the wrong files were included—I learned the hard way. After spending time testing, only to find out that it wasn’t the correct version, it’s a feeling of frustration and helplessness.

Now, I’ve developed a habit of verifying the files first. Some people manually open the ZIP file to check, but I wrote a small Python script to unzip the file, read the version info inside, and compare it to the version I’m expecting. This way, I feel more confident and save a lot of back-and-forth time.

It’s not something anyone mandates, but for me, testing is not just about executing the process—it’s also about ensuring that we have the right stuff from the beginning. That way, all the effort I put into testing won’t go to waste.