We manage without an army of QA: how having no testers saves developers' time and improves their expertise

Working on a complex project in an assembly-line approach looks roughly like this.

The client sets high-level goals for the product or solution.

The project manager handles them and keeps the "assembly line" moving.

Business analysts and systems analysts rework requirements and write a lot of documentation.

The whole team is also involved in testing: developers write tests for each other's code (cross-testing).

Does this mean that developers are doing low-skilled work?

His job is less to find a flaw than to review the result of another person's work in the project. People who are in the context of the whole project make better decisions and are more aware of business goals and outcomes.

The team is fully involved in the project, makes more thoughtful decisions, and better understands how its work connects to the outcome.

The habit of having someone else clean up mistakes makes people lax.

Have you ever thought about how much time a developer loses to working with a tester? A lot, sometimes up to a third! How does that happen?

Code written by a developer is not tested right away: it waits until its turn comes up in the tester's schedule (time).

The tester runs the code through tests based on the technical specification and finds bugs, flaws, and issues (more time).

The task goes back to the developer. But he was not sitting around waiting for that to happen.

He has moved on to completely different tasks.

To fix the issues, he has to pull himself out of the workflow, reset, and re-immerse himself in the problem. And that takes time again, plus energy and nerves.

After fixes, the code goes back to testing, and the process repeats again and again until victory. As a result, the developer constantly switches back and forth between tasks and cannot properly immerse themselves in solving problems. What about multitasking? Multitasking kills the cognitive skill of deep problem immersion and leads to an inability to focus.

In Agile, code quality is addressed not only through cross-testing, which we discussed above.

There are many practices, including TDD, Agile testing, and the role of the SCRUM master in the process.

We will talk about all of this in future articles. Andrey

CEO of kt.team: "Strictly speaking, our developers are not coders but engineers.

Their level is such that they can objectively check both their own work and their colleagues' work through cross-testing. And even those who come to us from other paradigms adapt to our way of working relatively quickly.

A tester is not actually needed in an Agile team, only a quality mentor, the QA engineer. The person who regularly reviews the project and evaluates the completed work: presence of tests, speed of work, presence of incidents, and their type.

He knows how each of them solves the problems that arise and can spread successful practices to other teams and projects.

When a developer sees the end goal and makes thoughtful decisions instead of simply "translating the technical specification into code"

, does not waste time on endless testing iterations through intermediaries, and the team reaches its goals much faster. Just as importantly, the developer's personal and professional growth also happens much faster. Solving tasks consciously helps not only improve programming language skills and expand the tech stack, but also build design, management, and business understanding skills, while better grasping other parts of the project.