It is believed that a serious IT-company can’t do without a QA department. While implementing the principle of labor division, a QA team can more effectively sort out bugs, unload developers, and improve the product quality and value.

We are used to see a “Q.A. Passed” marking on different electronics and expect the same control measures when using IT-products.

But the development of IT products is not a nonstop production process. The world experience (and, among others, the kt.team IT integrator experience) shows that in complex environments the evaluation criteria are defined for each feature, which is clearly beyond the competence of an ordinary QA Specialist. Their involvement blurs the value of the product, its cost and development time increases and conflicts arise within the team due to the incorrectly divided responsibilities.

Hi, I'm Andrew Putin, executive partner with IT developer kt.team. And in this article I’ll explain why this happens.

Complex Environments is a concept from the Cynefin framework, which divides all environments into four types: clear, complicated, complex, and chaotic.

In linear (clear and complicated) environments QA Specialists just need to strictly follow the rules. Everything is clear: it is enough to compare the plan to the result, to check the parts or to just plug the device into the socket. There can only be one result, the product either complies with the regulations or it does not.

But in a complex environment, everything is different. There is no final result, neither is there a fixed path that can be used to achieve this result. There isn’t a single standard for different types of results such as acceptable or excellent, only a vector of development. The typical test criteria do not match the core values of Agile, which are the most effective in complex environments. In a complex environment, the reaction to changes and the feedback come in first place, not the rules.

Once upon a time, in an IT company...

1.

2.

3.

They are both put in a position where the quality of the result is overshadowed and where conflicts are inevitable. Here are the factors that provoke them.

It’s bad when developers start thinking that their job is to supply the code instead of the value. In the case above, with Peter, the developer and Victor, the QA Specialist, neither one is thinking about the value; the developer is thinking about the number of features, and the QA Specialist - about the number of bugs. Business interests are left beyond this process.

The result requirements change in each cycle of Agile and in each feature. To avoid conflicts, evaluation criteria need to be written for each feature. And this leads to a monstrous growth of bureaucracy and time wasted on developing new regulations. Both, the developer and the QA Specialist will have much less time for the product.

Do the little experiment described in the book “Focus”. First write down “fat red cat”, and then try to write these words in parallel: “f.. r.. c..”, “fa. re. ca.” and so on. Which way will take more time and energy?

It’s the same in IT development. When Peter got feedback on the bugs from task X (“fa.”), he was already working on task Z (“ca.”). He had to recall his code, correct (“fat”) it or dispute the corrections and return again to the current task (“cat”). He’ll spend more time going back and forth, doing the switches, than working on the task itself.

When the developer does not keep in mind all the possible errors or difficulties that the user may encounter, he cannot foresee them. Peter, the developer, completely transferred the responsibility for his task and its interaction with the user to his QA Specialist. While Victor tries to figure out the feature from the users’ point of view, Peter loses touch with reality.

World leaders of the IT market do not hire QA Specialists. In the case of MAANG companies: Meta, Apple, Amazon, Netflix, Google — the idea of nonstop testing is an outdated concept. Headliners do not think that attracting QA Specialists, by default, adds quality value to the software. For example, in the book “How Google Tests Software”, the authors point out that Feature Developers have everything necessary for self-delivery of quality value, and the so-called Software Engineering Test is obsolete. Google describes IT used by food retailers, but the same logic applies to most service companies working on Agile.

In practice, Agile QA Specialists are not considered to be a separate class of engineers. For nonlinear tasks, the Cynefin framework recommends frequent supply of value and constant feedback from the product. Therefore, there is a need for a common centre, the developer, who will be responsible for both, the supply of value and obtaining the feedback. Once he starts sharing responsibility with the QA team, he inevitably loses focus.

Based on kt.team’s experience, the best way to build this process is when the developer:

It’s a proven and a practical way to avoid a massive failure.

How did we get to this conclusion? We tested different schemes of work, with and without a QA team. Based on our experiments, over a year ago, we have removed testing from non-linear tasks. Instead, we actively use extreme programming techniques such as:

and others.

And another practical observation: to improve the quality of the product, you need to use all the different types of feedback.

I will not claim that a QA team is never needed in complex environments. There are situations in which the team cannot do without a QA Engineer.

For example, when creating a mobile application. There are many platforms and devices on which the application must work correctly. The developer can test its performance on several major platforms and devices, but it doesn’t make sense for the developer to waste his time “running” it through the whole bunch.

It’s best to contract a QA Engineer, especially if you are using a specific hardware part that does not have software emulation, for example, some rare controllers from second-tier manufacturers. In this situation, the use of a QA Engineer is justified. The developer keeps the responsibility for the value of the product, while QA engineers are responsible for figuring out system bugs on variations of rare devices.

It’s not a good idea to let a QA Engineer do testing on popular browsers: functional tests cope with such testing tasks much more efficiently. Besides that, we are not in 2010, it’s not a problem if a button bugs in some version of a rare browser. Moreover, today, automated DOM-analysis tools are easily available for any browser.

In this case, the company does not need an ordinary “bug catcher”, but a manager who will thinks about global tasks and will build testing processes based on them. He will define testing zones, certify the commands for quality, develop and implement test design standards and adjust collection processes and feedback from users.

There are narrow areas of development that are strictly regulated by specific legislative or safety requirements. Even in the banking sector, this includes a small proportion of the work done only by technology giants. These are companies that operate many systems as a single unit on all continents and are subject to the same legal and other regulations.

QA Engineers in such companies check for compliance with regulations and uniform standards. The delivery of the value is not part of their responsibilities: their task is to regularly read the code and identify specific vulnerabilities. When they find a weak spot, they incorporate part of the automated test into the code, which must then be maintained by the team.

These engineers are experts in their work. They are very much helped by the presence of a well-established culture in the company and a benchmark for evaluating the expertise of developers.