|
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.
|
