Developers should write test cases(?)

There is an old dispute on the topic of who should write test cases: developers or testers. It seems like if there are testers in the team, then it is logical that they write the tests, right? On the other hand, the guys from the development know exactly how their code works and how it will behave in certain situations. At least they suppose to know.

If development writes tests, you can solve several problems at once, for example:

· Perceptibly speed up the release cycle;

· Unload testing.

In most commands, the process looks something like this:

1. The developer creates new features and completes existing ones;

2. The tester tests all this and writes various test cases;

3. The automation tester, justifying the title of the position, automates everything according to the written test cases.

Everything seems to be simple. But there are weaknesses in this paradigm.

Let’s say a developer has completed his feature and has safely passed it for testing. But the feature turned out to be not medium rare, but frankly raw. This will lead to a rediscovery of the problem and additional fixes, and there can be from one to N iterations, depending on the size of this feature, its complexity, impact on related processes, and the conscientiousness of the developer himself. And also on how your processes in development are arranged, how carefully pull requests look, whether the application is launched before being sent for testing.

After the task is tested and ready for release, testing needs to be written for the entire functionality of test cases. Then do regression/smoke testing and finally release.

The automation tester, after receiving the written test cases, covers the functionality with tests. There is a fairly high probability that the task will end up in an existing queue, so the tests will be written with a delay.

Just need more developers

The more developers you have in this scheme, the stronger the testing load will be. As a result, either the release cycle or the testing team itself will increase.

And this, according to the domino principle, will increase the load on the automation testers, who will have to process more and more test cases that fall on them from testing. There will be a mirror situation: either the test coverage time will increase, or the automation staff will.

For eight developers, there are usually two testers and one automation engineer. At the same time, automation is not directly involved in the release cycle — rather, it is nearby. And the question arises: how to make the described processes more effective, and even not to lose in quality?

Let’s try to move the automation stage from the third place to the first, to the development stage. What happens?

· developers write tests simultaneously with writing the feature itself, which significantly improves its quality;

· the load on testing decreases: testers now need to look at the test results and assess whether the task is sufficiently covered by the tests;

· manual regression in the scheme is no longer necessary.

What about testers?

The tester, even in the updated paradigm, remains an expert in testing — it is he who reviews both the quality and the completeness of the autotest coverage of a particular feature, and also deals with the analysis of complex and unusual problems. But now, thanks to the reduced load, a part of the time is freed up for the tester, he can deal with the processes.

At the same time, you need to understand that manual testing will still not go anywhere — you will always have something that, for some reason, is either impossible to automate or does not make sense.

So, to a new paradigm. Cool? Yes, at least implement it right now. If you can do two things.

1. Sell this idea to development. Because not every developer will immediately want to write tests, because it can be boring, or he simply does not want to: do you, in fact, have testers over there for what?

2. Sell this idea to managers. Because, with other advantages, you increase the development time for each feature.

What are the disadvantages here that can await you?

1. Most developers just don’t know how to test, because they are developers, not testers. And that’s okay. Here you can either teach them how to test, which will not be the most trivial task or just write test cases for them. Which de facto breaks the process itself;

2. At the start, automation will take more time, because there will be no test codebase, infrastructure, and usual approaches — the task is new;

3. Clear reports will be needed for testing. But keep in mind: even the most understandable report cannot always be read correctly right away;

4. You cannot easily and quickly cover not every problem with tests. In some cases, you will have to spend more time on tests than on the actual implementation of the feature;

5. It will be difficult to deliver large-scale tasks at the same time as tests, it takes a lot of time;

6. For these same large-scale and complex tasks, you will still have to set aside time to simply delve into them, because there is no other way to check the correctness of the tests that the developers wrote.

What to do?

Basically, each problem has a solution.

1. Developers don’t know how to test. →

You can advise them in the early stages to help you figure it out;

2. There is no codebase, infrastructure, and approaches. →

Everything is decided only by time. It is easier to write texts on marked functions;

3. Clear reports. →

All steps should be included in the reports, and the name of each test should immediately reflect what exactly it checks;

4. You have to spend a lot of time on a number of tasks. →

Common sense saves: not everything should be covered here and now;

5. It is difficult to give up tasks when there are no approaches and tools. →

It is also being solved gradually, the main thing is the time for the analysis and implementation of this or that tool. And this should be a separate task;

6. The problem of large-scale tasks. →

They can be given immediately without tests or partially covered by tests. But this in any case does not negate the immersion in context.

Output

An approach with all its pros and cons has a right to life. And if you also set up the processes correctly, then this will help you speed up the release cycle and not inflate the state!