…When working as a single QA in a big team of developers.
Regardless of actual coworkers’ attitude, this feeling may often come to a tester’s mind. Indeed, the quality control work is less likely to produce visible results compared to developers’ work. The better their code is, the less of obvious bugs it contains. A tester might spend a lots of tume and catch some hidden issues with potentially high impact — and it would be a great success. Or catch nothing: then this time would be spent without any significant results, making tester feel bad about that.
Defragmentation of application functionality, preparation of all possible use cases and — most important — good experience with different kinds of projects help to avoid such embarrassing situations. But it is difficult to do everything properly when alone testing a big project. However doubtful the practice of assigning a single person to test everything may seem, it is nevertheless pretty widespread. As a result, testers start questioning themselves, if they are really helpful for the team.
Now, a disoriented, self-discouraged team player is a 100% disaster when it comes to this stage. It is a problem a PM, team leader and/or HR must solve. But I want to talk about actions a tester could do her- or himself to avoid getting embarassed and improve the overall QA process in the team at the earliest stage of her or his involvement.
“Be Proactive”, a common advice people are giving each other in many different situations. What does it mean to be proactive for a QA engineer? When you join a project, you should be given some time to get familiar with it. They must share some documentation with you. Better try getting access to as many documents as possible, while analyzing those which you have already obtained. Point out at any case of unclear description, inconsistent design, contradictory requirements or seemingly wrong assumptions about customers’ needs. Ask your PM whether you can access more sources to clarify these specific things. If there is nothing else for you to read, volunteer for improving the documentation. It could be a task for a tech writer, but why not trying yourself in this field? Writing skills could appear very helpful in the future.
Another good tactic is developing critical approach to the product or its separate features you are testing. Try finding weak spots and suggesting improvements — in most cases your team will be interested to hear about them. It is important to think as a future user who does not know anything about the code and architecture. Try imagining what such a person will like and what will be found confusing. Products are made for customers, so this approach will ultimately be helpful as long as you construct proper model(s) of customer behavior.
Teams vary; sometimes your teammates might be open for communication and sometimes everyone will be just focused on some narrow scope and refuse to discuss anything outside it. But it is always worth trying, so — talk, talk, and talk. Just do not press people, stay friendly and try to be helpful and generally positive. In most cases it should work!
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!