How testers can be useful to the product team other than just testing

Somehow it has historically been so that the idea of QA-specialists’/testers’ capabilities is concentrated around two tasks:

1. The very top notion: they are only needed to test the product — to click the buttons, see if everything is okay, and then release it to production with peace of mind.
2. Advanced level: quality assurance and quality control.

And while the first point is clear, the second one is more complicated, it’s a vague and expansive definition. And those who are not so closely connected to the specifics, haven’t the foggiest what it is. Something to do with quality. Perhaps this is why testers border on the image of monkey testers, who hit buttons every now and then.

The skills and capabilities of QA-specialists are evolving and are no longer limited to clicking through in search of bugs. But at the same time, the customers’ and businesses’ understanding of how to apply these skills and what to, most often does not go beyond testing. And this mismatch is a missed opportunity for both sides: QA-experts do not understand how to sell this to the business or to communicate the benefits of these capabilities, and the business, in turn, only regards them as bug catchers.

In this article I want to talk about the non-obvious, but cool skills that QA-engineers possess, know, practice, and how it can really help businesses.

Setting up work processes

The quality of the product and what users receive as a result is strongly influenced by the project’s work processes.

Work processes are the interaction between the team or teams/departments, as well as the development life cycle itself.

• What is the interaction in the team: who should question whom; in what form should questions be presented; how tasks are passed, to whom they are passed and at what point in time, who is responsible for what, etc.
• What are development processes — this is the development life cycle, which consists of analytics, development, testing, and support. And here it is important to understand the whole chain: how is analytics conducted; who is involved in this stage; what are the statuses of the tasks; when they pass on and who they pass on to; what happens during the development, etc.

This can all be set from scratch, adjusted and controlled by the QA-engineer.

Why should the QA-engineer do it? Why not a PM, for example? QA-engineer understands the user’s logic, the business logic of the product, how the process affects quality and, no less importantly, how the functionality and business goals should interconnect. He looks at the entire process as a clockwork, takes it apart thoroughly and refines it. This sounds very similar to what the PM does, but a QA-engineer also has to understand the product technically, not just from the top level of the manager.

If there are problems somewhere in the processes, even the trivial ones: the designers did not agree with the development department, the marketing department did not agree with the designers — this is where problems with the quality of the product start. Some task may get lost in the depths of processes and never make it to release. Result? Users get a low-quality product, and business suffers losses and negative feedback from users.

Case in point:

One of our projects had a high percentage of calls to the support service. We began to set up process: figure out how departments interact, what happens within the team, how tasks are sent for development, who is responsible, and so on. And after a few months of adjusting and reassembling the processes, the number of calls to the support service decreased five-fold. Simply because all the processes became transparent and fine-tuned.

Attention! We didn’t pour in money, or hire more and better developers and testers, they didn’t inflate the support staff to speed up cleaning up the mess, but they built a new process in the conditions of the existing team.

Competitive analysis

Another cool thing you can and should ask a QA-engineer to do is competitive analysis.

• First, you need it when working with an existing product to understand why competing products are better or worse; what features are appearing in their products; whether users like these features; what should be improved/changed in your product to get more users. Without this information, it’s hard to keep abreast of developments and keep your product competitive on the market. It’s cool if you have a business analyst — that’s his job. But if not, a QA-engineer and his technical vision of things are there to help.
• Secondly, you need it if you’re just starting out. Let’s say you have a new product. There is already something similar out on the market. If things are to be done properly, you need to understand the experience users have with the competitor’s product; what users like and are comfortable with, and what they do not; whether the competitor has cool features/bugs. To do this, you gather a list of competitors and give it to QA-engineers. They go through the functionality of all your websites/applications, map out the differences, find the competitor’s functional errors or cool features that you haven’t considered. This is your advantage and an opportunity to beat your competitors without making similar mistakes in the functionality of your product.

Again, why QA-engineer? There are developers, analysts, marketing after all. QA-engineers have visual experience, a lot of experience in going through user paths, and an understanding of user’s logic. That’s all you need for a quality analysis.

Parsing product logic

QA are the kind of guys who would rather pester you with questions than let doubts remain about the logic of the product. A QA-engineer knows what can interact with what; how it can interact; understands the consequences of functional and logical errors. He begins to ask questions from a common user’s point of view: how will the system behave?; what will the user do?; and if he does this, where will it take him? During the question session, errors in the logic of the product very often surface.

Case in point:

We had a case where when we were brought a functional for testing, we started asking questions. It turned out that there were a lot of inconsistencies in the product, or rather in the logic of the product. As a result the product was sent back to marketing for revision, not even to the developers. This is because initially questions at the stage of discussion with insurance companies and lawyers had not been worked out.

This is the Pareto 80/20 principle. 20% of the errors found at the final stages of development take 80% of the budget to fix. And vice versa: 80% of the errors found on the early stages take 20% of the budget.

Scaling up your business

QA helps you scale your business. More specifically, a QA-engineer can diagnose the product, check its readiness for scaling, to avoid global errors that may occur, e.g., when the load on the product is increased. Let’s say you want to dramatically scale a platform. The resources are there, the development department swears that everything is absolutely ready, but first it’s critical to understand: can the system withstand the load?; are there any potentially dangerous but imperceptible problems now?; will the platform hold if there are not ten users but, say, a thousand? Yes, it all seems to be clear as it is, but as experience shows, in fact, it is not.

Case in point:

A client came to us who wanted to scale dramatically. He came with a finished product for manual testing. We started looking at the platform, and we began to have doubts: will the system hold up, will the database hold up, will the server hold up. So we advised to do load testing, not manual testing. And indeed the problems were revealed, which would have sprung up if the platform received a heavy load. i.e., after manual testing for 100 people, as the client wanted, everything would be fine, but if you launched it for 10,000 people, everything would crash.

A few kind parting words:

Of course, it’s fair to say that what I wrote above is not within the reach of all testers and QA. After all, it depends on experience, skills, and visual experience. But this is what QA-specialists should strive for in their work.

Just like marketers, business analysts, strategists, and other specialists/departments of a company, QA-engineers are interested in making the product generate revenue to the business. So by going beyond just testing, a QA-engineer monetizes his knowledge into transparent processes, a competitive, high-quality and user-friendly product, into a cool user experience. And satisfied users mean money and growing business.