User acceptance testing (UAT) is a critical practice to employ for a multitude of products and processes. For the purpose of this article most of my examples will be within the context of migrating or merging instances for Atlasssian products. Nonetheless, these tips can be used for other avenues: I actually picked up these habits working as a QA tester for a video game publisher.
Context is king
When testing a product or a process, such as a migration or a merger of two instances, if you come across any issues, the most important thing you can do is provide as much context as possible so the developer or admin whose responsibility it is to correct the issue can have as best of an understanding as possible of how the issue came about. The best way to achieve this is by telling them what you did (repro steps), telling them what you expected to happen (expected result), and then telling them what actually happened (actual result). By providing the steps you took and giving the context of what you expected from those steps, followed by what actually happened, it paints a better picture for the team in charge of dealing with it.
Screenshot or it didn’t happen
Speaking of pictures, we used to have a saying on the QA team I worked with: “Screenshot or it didn’t happen.” If you can provide a screenshot of your issue, you increase the chance that the person responsible for resolving the issue will be able to address it without any back and forth. Screenshots of any errors you see on pages, or incorrect configurations of data, help identify the exact issue, with no room for interpretation. If you’re doing user acceptance testing, a screenshot of the UAT instance where the issue lives and what it looks like in production is even better. Again we’re trying to establish context for what your expectation was and what you actually saw.
Often during migrations or mergers, the individuals who are performing the work do not have the context of what the content is and what it should look like. This is why user acceptance testing is such a valuable tool: It gives the users a chance to scope out the changes and see if anything looks wrong. So it is the tester’s job to provide as much information as possible to resolve any issues. Here’s an example of an issue related to a migration:
- Summary - Write a brief summary of the issue you’ve run into, it can be a simple statement, 2-3 sentences at most. (This can be optional depending on the medium for reporting the issue, if you’re using a Jira project to track bugs this would be important. If you’re tracking things in a table, the description would probably be sufficient)
- Description - Provide a detailed description of what you observed. Include specifics like a link to the exact page or any particular tools used. This is a situation where less is less, more is more.
- Reproduction Steps - Give a detailed step by step walkthrough of how you achieved the result.
- Expected Result - At the end of the reproduction steps explain what you expected to see.
- Actual Result - Also describe what you actually saw; be sure to indicate how this is different from the result you expected.
- Expected and Actual results can sometimes be obvious or at least seem that way, just remember that it may be obvious to you but not necessarily to someone with a different context.
- Screenshots - Where possible, include screenshots of the errors or issue you witnessed, and provide a comparison if possible to paint that contextual picture.
The most important thing to remember when doing testing of any kind is providing context. Always assume you can’t… assume anything! Treat it like the person you’re explaining the issue to has no idea what you’re talking about. And if you have any questions regarding UAT, or how it can make the most of your processes, drop us a line, we'd love to help you out!
