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.
測試不只是發現錯，更重要的是釐清問題
有時候一個 bug，會在開發和測試之間來回好幾次。
「我這邊正常啊」、「還是有問題耶，你再看一次」——這種對話在 QA 日常裡應該不陌生。
久了就會想，測試人員除了發現錯，能不能多做一點什麼，幫助更快釐清問題，少一點這種來回。
這篇想分享一個很小的例子，不是什麼難 bug，但就剛好可以說明，
想說的是，經驗不同，回報 bug 的方式也會不太一樣，而這些差異，往往就影響了整個問題能不能早點被解決。
Bug 範例：Contact Us 連結無法運作
網站網址: https://prod.dvcbot.net/login
有問題的連結: Contact Us
初階測試人員的 Bug 回報
標題: Contact Us 連結失效
步驟: 點選 Contact Us
目前行為: 開啟新分頁，顯示 about:blank
預期行為: 應該會開啟電子郵件應用程式
這樣的回報其實沒有錯，但開發人員可能沒辦法複製這個問題，這就會導致 bug 回到 QA 手上繼續確認。
中階測試人員的處理方式
除了基礎的描述外，中階測試人員可能會進一步：
-
檢查 Contact Us 連結（
mailto:aide.support@mediatek.com） -
測試不同瀏覽器（Chrome、Edge、Firefox）
-
檢查瀏覽器是否封鎖了彈出窗口或是否支援 mailto 連結
這些細節能幫助開發人員更清楚地了解情況，也可能幫助他們複製問題。
資深測試人員的處理方式
擁有更多經驗的資深測試人員，會考慮到是否是系統設定的問題。
在這個例子中，問題實際上是操作系統沒有設置默認的電子郵件應用程式，因此 mailto: 連結無法運作。
這是一個很微妙的問題——不是瀏覽器的 bug，也不是系統錯誤，而是環境設定的問題。
當這個細節被加入到 bug 回報中時：
測試機器沒有設置默認的電子郵件應用程式，導致
mailto:連結無法啟動。
開發人員可以很快聚焦在正確的問題上，縮短回報與修正的時間。
測試的價值：有時候就是在細節中
我們常常專注於「發現錯誤」，但實際上更大的價值在於「釐清問題」，幫助開發人員專注於解決真正的問題。
這不是 AI 可以取代的能力，而是來自於觀察、推理、經驗的積累，還有一點耐心。
沒有留言:
張貼留言