No More Unwritten Rules: Tracking My Work My Way

In one of my previous jobs, I had a supervisor with a rather peculiar attitude towards taking leave. Even if it was a normal leave request and tasks were completed on time, I could sense some dissatisfaction.

At first, I didn’t understand. I thought as long as I did my job well, it would be fine. To avoid affecting the progress, I adjusted my work routine:

• Arrived 30 minutes early
• Shortened lunch break
• Stayed late
• Sometimes continued working in the evenings

The tasks were never delayed, and I never complained.

Until one year-end 1-on-1 meeting, when the supervisor said something that really surprised me:

“If you have time to take leave, that means you should have time to handle more work.”

That’s when I realized — my supervisor didn’t know that I was adjusting my schedule and putting in extra effort to complete the tasks.
They only saw me “taking leave but still delivering on time” and interpreted it as me “having more time to do other work.”

This experience made me realize the unwritten rules in the workplace: if the official work hours are 40, you should report only 40, and the negative impact it causes.

In the past, I complied and chose to remain silent, but from that moment on, I decided not to do that anymore.

I track the hours I work honestly.

Any overtime, I don’t hide. Any effort, I no longer ignore.

The work itself is important, but making sure the work is seen is equally important.

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.