The role of the QAs

They are important as 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 a 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 features as fast as possible 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 for checking in an automated way that all the features work after making changes. This way, they save time on testing manually and detect side effects that others may not have considered.

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 on a project until a few weeks later. In these cases, they may spend more time thinking about the test that they have to fix later than learning what the project is about. You can make them participate more by 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 answer 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 have 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. That could have been prevented by asking other people to help them or removing low-priority tasks. You could ask instead how long it is going to take. 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 at the beginning of the project as there are more meetings, and there isn’t much to test because the developers start preparing the foundations. Then, as the deadline comes, the rhythm 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 Excel provides to find duplicates or do data lookups, or modify the regression tests so they check the content of the reports after downloading them.

Get them 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 get to know each other better.

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 for help from certain people, … Asking them directly and in private may give them the confidence to say what they think.

Look at 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 of moving the common part to separate methods, which slows down their performance because every time they have to make a change, they have to do it in many places.

Some companies don’t detect it until they start spending too much time on maintenance instead of creating new ones, and at that moment, there is too much tech debt, and they are already used to working that way. What we can do is to get involved in their code reviews or ask the developers to participate in them. That wa,y 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 to 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 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.