Often a QA is alone on a team, which may consist of a large number of developers. And sometimes you need to make some decisions that affect a particular result. Depending on the culture of attitude to testing in the team as a whole, the result also depends. QA can and should see some unresolved or bottlenecks in development and try to tell all participants in the process about them, convey important thoughts and direct them in the right direction.

What can a QA do to successfully influence a team?

🔵 When you find a bug, send it directly to your team to get feedback faster. If general criteria for describing a bug have been developed, then try to adhere to them, which will help team members quickly understand what the reason is. In the message, you can immediately mention a colleague who was responsible for this functionality, or ask if anyone knows who you can ask about this bug. You can also assume some related events, perhaps this will help colleagues quickly understand and understand what happened.

🔵 Attend important team meetings, ask questions, pay attention to various cases. So you will be aware of the events and will be able to better understand what is happening in the team at the moment. Write down important moments so you don’t forget ;)

🔵 Share knowledge about testing, hold learning rallies and talk about the state of affairs in regression testing, approaches, etc.

🔵 Start transparent processes: set up dashboards so that the team can see all tests, test cases and other documentation. It’s never too late to start, the benefits will undoubtedly be for all team members)

🔵 Join testing as early as possible, do not stand aside, develop the shift-left testing approach. After all, it’s no secret that finding a defect at an early stage saves both time and money, respectively, the sooner the tester is involved, the better for the team.

🔵 It’s up to you to show how useful autotests can be. Show how to launch, how long they last, what profit the team gets from this, etc. Set up reports, messages in work chats or e-mail. Sometimes it is useful to separate team tests from the general mass and follow only them. See with the team what results, what errors occur, communicate, because it is almost like your living product documentation, if everything is done correctly.

🔵 Any person can make a mistake - take it as a fact, do not criticize, it is better to explain in detail what and how and where. In practice, this helps a lot, namely, to figure it out together on the shelves, what if you are wrong or the problem is not on your side and what to do next.

🔵 Become a product guide. The longer you work, the more valuable this knowledge is. Ideally, if you know the background, how and why this or that was done, but this is not always possible. If there is nothing, then start doing everything yourself from scratch: break it down into mind maps, use internal documentation efficiently, structure it competently, put it next to your team’s documentation.

And your work will not be in vain - not only the developers of your team will contact you in order to explain this or that functionality, but also the rest - PM, PO, designers, etc.

🔵 “We don’t need developers in testing, but testers in development.”

You can develop in different ways, this is a personal choice for everyone. For example, you can develop “in breadth”, i.e. study various areas besides the main one, for example, improve your knowledge in the frontend or backend. There is another way, “in depth”, when we study one area to the core, going from beginner to expert. A tester may have excellent analytical skills, as well as flexible thinking, be patient, able to see the big picture, and have good mental abilities.

QA can also apply these abilities to other areas such as development, management, design.

In practice, I manage to play different roles, if there are interesting tasks or just want to try something new, then this is always only a plus for your development and for the team it is also a plus. A tester can become a successor to a developer, adopt knowledge and experience, learn a little, etc.

Conclusion

A good QA is a friend and helper of the whole team, making a significant contribution to the development of the product and to improving the work of the team.

Original post in Telegram - https://telegra.ph/Kak-QA-mozhet-vesti-komandu-k-uspehu-02-18-2