Strong collaboration and communication with your development partners is very important to the Agile process. But, remember that in your role there are some important quality assurance questions that you should ask yourself to keep your processes consistent.
WHY ARE YOU ONLY TESTING WHAT THE USER STORY TELLS YOU?
User stories should have acceptance criteria added by a product owner or business analyst. These are usually helpful for QA to know when they can consider a story as “Passed QA.” However, it’s important not to just stick to the AC and test only the “Happy Path” for a feature. The AC usually tells us what we want to happen, but it’s our job as testers to think about what could happen. Remember to use your QA skills to think outside the box and run validation and negative tests to improve your test coverage on a story.
ARE YOU LETTING DEVELOPERS BIAS YOU?
Sometimes, with a complicated user story, a developer may meet with the QA team to demo the feature they’ve developed. This can aid understanding in the scope of what needs to be tested and any risk areas. However, it can also result in the opposite effect where testers are biased by the developers into assuming something will work. A developer may demo a particular section of a feature and casually mention, “I tested this really well, and it all works great.” We might then gloss over thoroughly testing this section and miss an important defect. The developer is already biased because they created the feature, and they’re confident everything works before they hand it over for testing. In my opinion, a tester’s motto should be “Everything is guilty until proven innocent.” Just because a developer is confident that something will work perfectly in production doesn’t mean we should be until we’ve seen it for ourselves in a variety of scenarios.
ARE YOU WRITING STRONG BUG REPORTS?
If a bug report is effective, then the chances of having the issue fixed improve. We’ve all had bugs rejected because the developer can’t reproduce it from the description in your report.
Ensure you have a clear, unambiguous, step by step guide to reproducing the issue. Putting these steps in a bullet point or numbered list makes it more difficult for a step to be missed. A screenshot of the issue is always useful; a screen recording of the steps is often even better. Some good tools for screen recording are: ShareX on Windows or LICEcap on mac OS
Be specific with your report; don’t write an essay about what’s wrong, and keep it to the point. Be careful also not to combine multiple problems even if they seem similar. Compartmentalize your thinking and separate the issues into separate tickets so they can be addressed and retested separately.
Include as much relevant information as you can to make it quicker and easier for the developer to diagnose the problem if the issue is only occurring in one browser, state that. If there are errors in the browser console log, copy and paste the full log into the bug report. If your application makes use of a logging tool like Splunk, check the logs for anything relevant and include these in your report.
