A tester should report errors/bugs even if he doesn't understand the technology particularly well. What is important is that you know the bug well, which means several things including the following:
- What it is that is not working or working as you believe it should.
- What do you believe the expected behavior should be? (In some situations, this is less obvious than it may sound.)
- Under what conditions does the bug occur? This includes identifying the steps to reproduce the bug and can include other factors such as these:
- Data and whether the particular data used is a variable in reproducing the bug (if data is a factor)
- Other variables such as operating systems, browsers, service packs installs, timing or race conditions, memory, and caching.
There easily could be a longer list of variables, but the point is know the bug well and don't be intimidated by not knowing the technology well.
You could also view the situation as an opportunity to learn more about the technology, but I can appreciate that this might not be an option due to time restrictions or other factors.
A note about convincing a developer to fix a bug: Being able to show the impact of a bug and the likelihood of a user encountering the bug has always been the combination under which I am more likely to get an issue resolved. The more probable it is that the bug will be experienced and the higher the impact of the bug, the more important (and likely) it is to get the bug fixed.
Dig Deeper on Topics Archive
Related Q&A from Karen N. Johnson
User acceptance testing and system integration testing differ in one key way: the person who does the testing. Learn when to apply UAT vs. SIT. Continue Reading
Initiating test automation on your project team may seem challenging, or even overwhelming. Fortunately, expert Karen Johnson has been through this ... Continue Reading
New mobile phone models enter the market all the time, and it seems daunting to perform application testing on the various devices available. Expert ... Continue Reading