QAs are very important but some companies are giving their responsibilities to developers instead of hiring them. I will share what I have learnt working with different teams.

The role of the QAs

They are very important because they ensure that applications and websites are fully tested before being released. This way customers have a better experience because they can use them without issues.

They usually have special skills and focus:

Broader vision of the project: developers focus on implementing specific parts and sometimes don’t see how they fit with others. QAs have a broader vision because they do end to end tests and see how all the features work together. This way they can detect scenarios that don´t work as expected or don’t make sense.
Edge case testing: programmers focus on implementing as fast as possible features that match the requirements and sometimes miss other scenarios. QAs provide a different view of the feature and think about edge cases that may not work.
Regression tests: they write tests that cover the main scenarios and allow to check in an automated way that all the features work after doing changes. This way they save time of testing manually and detect side effects that others may not have considered.

How to help them improve and be more engaged

This is what I have learnt in teams that worked in many different ways, mostly with junior and mid level QAs.

Involve them in the projects from the beginning

Sometimes they are only asked to participate in the projects when they are ready to be tested, so they miss all the meetings in which the requirements have been discussed and don’t get a global vision. And at that time the team may be quite busy trying to meet the deadline and may not be able to explain properly how it works.

Engage them in the planning meetings

Some people are very task oriented and don’t pay much attention when they know that they may not work in a project until a few weeks later. In these cases they may spend more time thinking in the test that they have to fix later that learning what the project is about.

You can make them participate more asking them questions about how they will test a feature or how they think it will affect the existing tests. You can also ask them to propose a testing plan after the meeting. This way they will focus on the meeting so they can reply the question and prepare the plan later.

Ask them when instead of if they are going to be able

If you ask people, mostly juniors, if they are going to be able to meet a deadline, they may tend to say yes without thinking too much about it. And then the day approaches and they feel bad and stressed because they didn’t had time to make it although they tried to do their best. At this point there may not be enough time to get everything tested before the release, what could have been prevented asking other people to help them or removing low priority tasks.

You could ask instead how long is it going to take it. This way they will have to think about the different parts and the time needed for each. You can also keep an eye on the board to see the progress of the tickets and involve the developers in the test if you see that it is going slower than you expected.

Do a code freeze with enough time in advance

The implementation is slower as the beginning of the projects as there are more meetings, and there isn’t much to test because the devopers start preparing the foundations. Then as the deadline comes, the rithm gets faster and the devs will try to get in the release as many features and bug fixes as they can. The problem is that the QAs won’t have time to test everything if you allow the devs to do this until the last moment and at that moment the QAs may also be too busy fixing the regression tests. You can do a code freeze of new features a few days before the release so there is enough time to test and stabilise.

Encourage to work smarter instead of harder

Usually it is not about spending much time but about using tools or different approaches that give better results in less time. For example instead of spending hours checking reports manually they could use the functions that Excels provides to find duplicates or do data look ups, or modify the regression tests so they check the content of the reports after downloading them.

Make them get involved in the team

Sometimes QAs form a separate group and don’t talk much with other members of the team. Ask them to join not only the stand ups but also other activities like going out for lunch or for a walk so they know better each other.

Have regular catch ups and listen to them

They may be shy or not confident enough to say what they think about certain areas that may not have enough coverage, features that have more bugs than others, difficulties that they have asking help to certain people, … Asking them directly and in private may give them the confidence to say what they think.

Look to their code

Some QAs don’t have a strong technical background because they started doing manual testing and then they learned how to code. Due to this they may have bad practices like copying and pasting the same code instead moving the common part to separate methods, what slows down their performance because every time they have to do a change they have to do it in many places. Some companies don’t detect it until they start spending too much time in maintenance instead of creating new ones, and at that moment there is too much tech debt and they are already used to work that way. What you could do is to get involved in their code reviews or ask the developers to participate in them. That way you can provide feedback so they can learn how to work better.

Check the coverage

Having many tests doesn’t ensure that they cover what is needed. The tests may just follow the basic flow from the first to the last screen without checking what is displayed, and some features may not be covered. Check this from time to time as these tests are the safety net of your team.

Share the ownership of the regression tests

The tests may fail due to different reasons like an API that was down, a bug added the day before or a change of the elements of a screen. It takes time and it is exhausting to go through all the broken tests and determine which failed due to actual errors. What some organisations do is to have a weekly rota of who is the responsible to look to the tests during that time.

What do you think? Do you have other experiences that you want to share? Or are you a QA and have a different point of view? I would love to read your opinion in the comments.