As part of the development process we follow the developers have a peer code review. This is done after the developer is happy with their completed code. It involves another developer inspecting the code to look for stuff like:
- Possible logic errors.
- Areas of the code that appear to be unreachable.
- Syntactic errors (Although a good IDE should pick most of these up).
It’s a great part of the process because it can often find problems even before the work has been given to the test team to look at.
I think that testers could also benefit from having a similar review but carried out on the testing that they have done and recorded (We can do the same peer code review on code we have written to test within the test team of course such as python code written to perform a selenium test).
In order to do this exercise the testers must document the testing they have carried out throughly, this should be a given !
The things we can look for in QA reviews are:
- Has the basic happy path test been done, an example would be “If a user on a website signs up for a news letter email do they get an email ?”
- Have any breakage tests been done? an example would be “If a user on a website signs up for a news letter but the email that the user tries to submit does not contain an ‘@'”
- If the feature / change is on a web application have all the supported browsers been tested ?
- If the feature change is on a web application has it been tested on mobile devices ? (If the application is designed to be used on mobile devices of course!)
- Are there any areas of the application that could be impacted by the new feature / change? have these been regression tested ?
- Is the reviewers understanding of the feature / change that has been tested the same as the testers who carried out the testing work ?, if it is not this might indicate that the tester has not quite understood what the feature / change was and due to this might not have performed the correct testing.
- If bugs were found during the testing process and fixed, was the feature / change then regression tested to check that the bug fix did not break another part of the feature / change.
Maybe you could think of some more good things to include in the QA reviews that you could do?