Have you ever consider, for how many purposes the issues, you raise during system test, might serve? It is very easy to get lost in daily activity of reporting mismatches between actual and expected result. It is a risk that Software Tester just starts to be register — assign — verify machine.
Let us consider here additional value you, as quality person, are giving to project and company.
First, you support test manager with valuable measurements about progress, achieved targets and quality. Thus, be sure, that without original error, you mentioned information like:
- Which part of system the issue belongs to?
- Does this issue is result of particular test case execution, or is it you noticed in additionally? Maybe the test cases could be updated or expanded based on your findings?
- Can you link you error with requirements/user story or acceptance criteria?
- Is this a new issue? Can you find out which code changes result this error?
- Or maybe this is an old issue, but detected only now? Ensure, that the affected version provides valuable data.
- Maybe this was already fixed before? Do you recall any related issues?
- Is this documented in business specification, or have you noticed missing flow?
Points above will be useful during retrospective or project closure activities. It could signal potential improvements for deployment, coding, test design, requirement quality. There are always reasons why the defect is introduced, and these are not always lazy developer. Very often their productivity suffers due to weak development practices.
In addition, view testing as support to your counterpart in the projects — developers. I bet they appreciate information that helps them easier to reproduce the issue locally, debug it and maybe even update their units tests to catch such issue in the future before delivering to test environments. What information might be important for them?
- Environment, where the issue was identified. Any additional information, if issue is present on another ones are valuable too
- Browser or other settings you are using
- Build version, on which the issue were found
- Repro steps, how to reproduce the error, including description, what is wrong.
- Expected result. Any references to documentation is great too.
To make all story short, just in case you prefer skipping all post and read only the end, just remember: Value your finding — the defect — and document it in the way that both you and your delivered information are respected.
I am looking forward to growing together with testing community and sharing my experience. If you liked my ideas, please consider supporting my time: paypal.me/EvelinaUrb