9 Ways to Keep Your QA Happy (And Efficient!)

Updated Mar 14, 2023 • 11 min read

Your QA team has their hands full of work to catch up with everything they get from PMs, developers and you - the client.

If you are curious on the best way to make a QA’s life easier, have a read below.

Let’s start at the beginning and assume a new project has just begun. The project team consists of a Project Manager, Developer(s), a Quality Assurance Specialist, and of course our dear Client. Everyone is doing their best to plan and organize an MVP version.

The PM carefully prepares user stories with the client — no easy feat! Everything should go according to plan, but suddenly complications appear somewhere along the road.

Then, during application development, the original assumptions change a bit. The Client has just decided that several additional features need to be implemented and in the meantime… the bugs start to appear!

Your QA team now has their hands full of work to catch up with everything. If you are curious on the best way to make QA’s life easier, have a read below.

1. At the beginning there was… a Decent Ticket

Tickets in Pivotal Tracker are fundamental to QA at netguru — they use them all day, every day. No matter if it’s a bug or feature, the ticket should be described very carefully, with love and detail. It’s the ticket creators’ job to give the perfect details which are necessary to address the ticket - the title, the body, the labels if required. It should be clear what the problem is, and/or what the expected outcome ought to be.

When creating a ticket, you can use subtasks if you feel that it'll be helpful to break the main task apart. But never leave a ticket uncompleted. Sometimes tickets are prepared really fast during a meeting and require adding more description later on. That’s OK. But it’s very common that a description is simply skipped over because the title might infer the outcome.

Before completing your ticket, ask yourself the following question: Will somebody else understand the ticket? Did I provide detailed information and my own insight? Could I easily give this ticket to QA from another project and would he or she be able to check it without extra explanation? If you can answer these questions with a yes, especially, the last one, it’s a good sign that the ticket is ready for the world!

Here is an example what a decent ticket should look like:

Decent tickets don't make themselves.

When you refer to the front-end work (e.g. graphics, flow, etc.) you can't expect that your QA is a seer. We really don’t know which colour the button should be, what the homepage should look like, or where anything is located. Always remember to attach your mockup (file), screenshots, or links where the required sources are located. What’s really important — make your resources accessible! I have come across several situations when a link from Google Docs wasn't shared properly, or the file was moved to another folder or there was a password I didn’t know. If the author of the ticket is offline and there's no way to get further explanations - your QA is in trouble!

Take a look at this beauty:

Is there anybody out there?

3. Always keep tickets up to date

Sometimes original mockups include really sophisticated functionalities, but we are doing an mvp version, right? Sometimes we need to cut down on some options and restrain from implementing everything at once, or change something in the mockup because it turned out the item is not practical. Always add info about any changes, even if they are small ones. For example, if you decided to change the names of the buttons, mention it. Remember that your QA pays attention to detail and after noticing this difference, he or she will wonder if the change was intended or not. If a new mockup is ready, always remember to replace the outdated file with the latest version.

4. Found an exciting bug? Do it like QA

Bugs found and added by QA are typically described very well, at least, we like to think so :D.

Good QA pays attention to include all the information necessary to reproduce the error and fix it. If you find a new bug and want to add it to PT by yourself, try to copy your QA’s way of reporting bugs. First of all, check if your brand new exciting bug hasn’t been already spotted and added by QA! You can use the search option in Pivotal Tracker and type keywords.

If you didn’t find your bug, create a ticket and remember to attach an accurate pic or video if it’s necessary to explain the bug (Jing might be useful). Always attach a pic and/or video with its URL address. Give full details about the unwanted behaviour of the application.

Stick with the simple form:

"as is": the unwanted action
"to be": how the function should work

Here you can find more useful advice on describing bugs.

Reporting bugs well makes your QA's life so much easier.

5. Commits and specs are welcome

First of all, never ever fix a bug/implement a feature without a proper ticket - if you can't find an appropriate source, ask your QA for help, but when you start fixing things without tickets, the QA will feel out of control.

If you work on a particular ticket, always remember to attach your commits. It’s a piece of cake because Pivotal Tracker is integrated with Github, so the only thing that needs to be remembered is adding a proper ticket ID when you are committing commit.

In other cases when commits are not added, your QA could think that the ticket is not ready and you have delivered it by mistake. What’s more, a ticket without attached commits looks sad and poor. Always remember to attach tests to the bug! If you can't do it for some reason, for example, if there’s no way to test— inform your QA about it in a comment, including an explanation for the lack of tests.

Never leave a ticket alone - it loves commits' company.

6. Labels are important not only in fashion :)

Very short information can be condensed into labels, and they are often essential to check the ticket. Always remember to add a ticket (for example no_qa) to the ones which are not for your qa. For example, if you do code refactoring: Ask another developer from your project to check the ticket tagged “no_qa”.

Another kind of a useful label tool is epic. Epic denotes a more complex functionality consisting of many user stories. You can easily filter by epic and see whole lists of tickets referring to the a bigger function or the a part of an application. Add the epic label if there is an accurate one in PT. Labels could also be useful to inform where QA can test a new feature or where the bug occurs, for example, on staging or production.

7. Ready, steady, go

To put this rule simply: Don’t deliver a ticket if it is not ready to be checked.

Netguru takes care of code quality, so the code from every finished ticket should be checked by other Devs in the company. We call this process a code review. A ticket can't be delivered if it’s not immediately ready to be checked and approved under code review.

Despite the example above, sometimes QA has checked a ticket still not ready to be checked. Why? For example: somebody clicks "Deliver" on the ticket whose commits were rejected by CircleCi and the changes aren't visible or the environment (production/staging) hasn’t been built yet. It’s a waste of time for QA when the task isn’t ready to be handled.

8. Never add a ticket you cannot explain or don’t understand

It seems to be an obvious rule, but sometimes it happens.

If you aren't perfectly sure about how the functionality should work, pass the ticket to someone who does. Ask other team members/featured-clients, for example using a project channel on slack. Don’t forget to add clarification to the proper ticket so your QA wouldn’t have to ask for explanation.

9. Stay tuned with your QA

If you feel like you need to leave some notes for your QA, don’t be shy! For example, if you want to leave hints on how to test something or share some doubts, do it without hesitation. Also, if you want to leave credentials because a bug/feature is implemented on a dedicated user’s account only, or there are additional settings to be changed, comments are a good place to do that - you can leave one for QA in Pivotal.

These practical examples might improve not only QA’s work, but also overall communication between all project members.

At first glance, it can look like a big effort to acclimate to all of those rules. But believe me—it will pay you back. Across the board we have observed changes in:

smoother communication - QA doesn’t need inquiries or further explanations, so there will be no questions which can disturb work on any side of the project.
work speed - the process of checking tickets is faster, even if it takes a little more effort to create the tickets well.
a solid source of knowledge - a comprehensively described ticket is not just for QA, it’s a gain for whole team. Pivotal is viewed by everyone, so it keeps all the members together and updated.

Do all of the above, and you’ll have a highly efficient, perfectly happy QA team.

Greetings from our awesome QA TEAM !