QA can be very tedious. If you’ve been at it for a while, you’ve had more than one of those “what did I just do?” moments. Perhaps you’ve had to QA a checkout process both as a guest and as an existing user. You may have forgotten which user you are acting as. Or perhaps you had to perform the same tests across multiple browser and platform combinations and realized you’d lost track of where you were at. You need a way to keep track of what you have tested and your results. This is the reason for the QA Results Document.
One way to create a QA results document is to set up a spreadsheet with the following columns:
Page/Action
Provide the name, URL or page type where the issue was found. If it is an interaction, provide the name of the action. These values should correspond with your specifications for easy cross referencing.
Status
Generally, the two values you need here are “open” or “closed”. You can also add others like “fixing in release X” or “fixing on a specified date.”
Ticket #
If you use a platform like JIRA for submitting bugs, enter the ticket number here. It may help to just paste the ticket URL here.
Priority
Generally, you can use a system like “H” for high, “M” for medium and “L” for low. Don’t stress too much about what the priority should be; that can always be changed. As a guideline, consider which issues are most important for reporting. Things that will prevent critical analysis should be “H”. Things that will affect values in reports but can be handled with a workaround could be “M”. Anything else can be “L”.
Variable(s)
Here, specify the affected variable or variables. Use the variable names found within the code since the intended audience is those involved with implementation. If you are relaying results to the reporting team, then you will want translate these to the variable names used within reports.
Issue
Share the incorrect value found or describe the issue.
Solution
Share the correct value as expected in the specifications.
Comments
Provide any helpful details such as how to reproduce the error or what may be causing the issue and how to resolve it. You could also provide an explanation of how reporting will be affected, especially for medium- and high-priority issues.
You’re going to find that your QA process flows much more smoothly with just a little preparation and organization. Best of luck, and may you find all the bugs!