How to write effective QA comments for Ticket Reviews

As a QA Engineer a significant part of my work involves analyzing tickets and testing the respective solutions implemented in order to make a verification of whether it is good enough to move forward or needs improvement or refinement, and then, close or send that ticket back to development, accordingly. When doing this you should always leave a comment, explaining why you made your decision and providing some proof of what you saw during your tests. In this article I will give an example of what these comments can look like and a short explanation of why it looks like this.

Before we can write our comment, we have to make a decision by designing and executing a few Test Cases (TCs), that are meant to evaluate two parts: what the ticket requested has been implemented and the solution did not break anything. When this solution has been thoroughly tested and you are happy with your review, you will make a decision of whether the ticket is approved or not and this is where we begin writing our comment.

First, we should make that decision clear to everyone reading, start by writing it: 

QA Status: Approved 
or 
QA Status: Not Approved 

Note that you can also make it clearer with an emoji, if you are into that: ✅ or ❌, for example. 

This is better to be short, direct and on top, so that it is clear to anyone if this concerns them (i.e.: the developer might want to know about a “Not Approved” ticket, but if it was approved, it no longer concerns them). You are going to want to keep it between these options, but there are more status available, for example, sometimes it is more agile to approve a ticket even though it failed one or two TCs, for this situation, QA status might be “Approved with issues”, and we would leave a reference to the ticket where this known issues will be addressed.

Then, we leave a short paragraph explaining our decision, for example: 

If it is approved, “these TCs have been executed and are all working as expected”
Otherwise, if it is not approved “these TCs have been executed and are not working as expected”. For this second case, and particularly if the TCs that failed are more complex, it is better to write them step-by-step in the comment to facilitate the job of the dev that will pick this up later.

Afterwards, it is smart to leave some details about your tests, for example: 

-Version of the app
-Device used
-Operating system
-Browser

Most of the times you will not see all of these since they tend to be standardized inside each project (e.g.: if you are testing an Android app, for example, saying what OS you used for tests is not very relevant), you, alongside your team, should try to figure out which details are relevant and which details are redundant, and keep in mind that what is relevant or not can change between tickets.
 

Lastly, make sure to leave a few items of evidence to prove your point. This evidence usually takes the form of screenshots or videos, but it can be, almost, anything - PDF files, audio recordings… The purpose of this is to show what you have seen during your tests. Things can change and similar environments can work significantly differently after a few updates (even if they seem unrelated at first), so if a bug you saw stopped being reproducible or a behavior which was working as expected, now is not, you can always fall back on your QA Evidence to prove that your review was fair.

In conclusion, this article shows only an example of what a QA comment can look like, but these comments can have many formats, you should keep in mind that the purpose of these comments is to express your decision clearly to whomever is going to read it, so the complexity of your comment should take into account who is reading and the ticket itself, some teams want more details, others want things to be more direct, some tickets require a lot of information, others are so simple that you really do not need to complicate, you should find what works best for your team and for each ticket and improve from there.