Software testing with or without testers?

Is the tester as a role still needed? What does development without a tester look like and what advice would you give developers working on such a project? Also, what can we take away from this idea for a project involving testers?

I asked six of our developers who have extensive experience with software testing, with or without designated testers. Looking at both sides, they were able to find the pros and cons and discuss how this way could be improved.

Development without testers = the way to more responsibility?

"Quality is everyone's responsibility," is W. E. Deming's famous quote. If it is everyone's responsibility, what should I do as an individual? Is anyone else taking care of this issue? And does the same apply to software testing in terms of quality control? Is it also everyone's responsibility?

I learned from our developers that even if you remove the software tester as a designated role, the need for testing will not just disappear. This task just passes back on to the developers themselves. They see greater responsibility as the main motivation and advantage in development without testers. When no one is covering your back, you are more motivated to properly check everything yourself, or to use more automatic testing and submit better work overall. On the contrary, on a project with testers, the developer may just rely on them instead of being proactive, he just waits to see if the tester returns the work to him for a redo or not.

Development with testers = is it a waste of time?

There are often no release tests on a project without testers. Developers test the application on an ongoing basis and usually there is no big specified testing process before it goes out. You could say that there is one less phase of the development process and the "time to market" is getting shorter. At the same time, the problem of coordination and timing disappears, as it is not possible for the testers to receive all the material for testing just before the release and not being able to manage, which is usually a common problem on projects with testers. In addition, if the tester is working on multiple projects at once, they may be busy elsewhere and the developer may receive a delayed bug report and lose the context of what he was doing. If a bug is found during development without testers, the developer can fix it right away. The tester also comes with a lot of minor problems which you can easily get stuck with.

Then there are the activities that are simply easier for developers. For example, create a mockup of something, if it is needed for testing. There would have to be a mockup created for the tester, or he would need help with it at least. At the same time, the developer already knows what he is working on and has more insight into what to test, therefore it takes less time. However, this can simply turn into a disadvantage, as testing loses its independence.

Developers’ recommendations for development with testers

The developers themselves then thought about what is the right process and based on this have come up with some recommendations for projects with testers.

• Don't start being responsible when it's already too late. Even if there is a software tester on the project, do not rely entirely on them and try to do as much as you can. Write unit tests, focus on understanding the assignment, be aware of a specific set of acceptance tests for a given functionality, and perform basic testing as part of the code review.
• Cooperate with testers as much as possible. It is best to have dedicated testers for each project. Agree with them on how the whole cycle should go and involve them in the task preparation and development process. For example, they can prepare acceptance criteria. Proper prioritization of fixes and new features is also important. It's also a good idea to give testers more insight into the development process itself. When a tester understands how developers think about specific things, they can identify potential risks based on these ideas. At the same time, they can learn to handle more technical tasks themselves, such as setting up a project and creating a build locally and creating mockups directly in the code.

Development without testers and independent testing

As I have already indicated, when there is no tester on the project, his role does not just vanish, it is partly transferred to the developer. This also has its disadvantages. The developer usually focuses on precisely what changes he made, anticipates possible errors and tests precisely only this change, he does not search anywhere else. He may miss the side effects of the change or errors that are not directly related to the change. Only independent testing can detect these.

The advantage of testers is that they see the application mainly as a black box. As a result, they approach it more as a user and also test things that developers seem to take for granted. In addition, the tester has more knowledge about testing and has an experience based feeling for it. They also usually test both Android and iOS and can compare the two platforms, which, again, helps them find more potential problems.

Almost all developers agree that they can catch marginal or regression problems only by chance, so more bugs get into production and the product quality is degraded. This feels unfair to the users, and relying on users to report bugs or the system catching application crashes is definitely not ok.

Developers’ recommendations for development without testers

So how about that? How can we develop without testers in order to eliminate these problems? Get testers onboard :) That was a bit of a joke, but overall the prevailing opinion is that the developer will never have an objective outsider’s view. Even so, some steps can be taken to improve the situation.

• One way is to automate even more testing. Use unit tests as well as some automated integration and UI tests. They may not replace the tester, but they will certainly help with greater coverage. Above all, it is good to cover those parts of the application that bring the most value to users and thus generate the most money for the client.
• The developers also agree that it would be good to get educated in QA and its processes. Be even more careful and consistent, don't miss any use case, even though they may seem trivial. Acceptance testing should become a direct part of code review - space for acceptance criteria can already be in the pull request template.
• At the same time, developers from one platform can test the functionality of another platform to highlight the differences. It is also good to have a given "definition of done" and know in what quality the project can be considered done.
• And last but not least, do not leave everything up to the developers and include specific test groups - internal alpha track, external beta track, etc.

Which approach takes more time in the end?

Now, you might be thinking that if a developer does all this, they will spend as much time on the project as if they were working with testers, if not more.

It may save them the trouble of doing release tests, but the developers agree that the time spent on the development process is longer, precisely because of the increased caution. The developer checks everything three times in a row and tests it through three times, another developer who reviews it also checks and tests the matter, and then with each change, the process repeats itself.

The growing routine always increases the chances of finding a bug. In addition, because no one regularly looks through the entire application, there are screens that no developer knows anything about - how they currently work, let alone how they should work properly. And this amount of time spent is similar to the time saved, but the developer doesn't have to explain to the tester how and why he programmed things. This is called the Rubber duck debugging effect, when he himself may find a mistake or something he missed.

The problem in itself is that it is often not registered that the developers need more time to develop, because they also have to test. The developer is thus always fully occupied, and as soon as deadlines loom and time is sparse, time spent software testing is the first thing he will cut down on, because it is a secondary job of the developer, the primary is programming.

The developers agree that in order for the testing process to be worth something, it is necessary to give it a sufficient amount of time. And it is best to take this into account in advance and include it in the project planning phase (whether in an agile approach or with waterfall) and to agree with the project managers so that they are not always being chased by them. Whether developers really want to spend more time testing is another question.

What suits the developers?

Among our developers, the opinion of development with testers won clearly. Only one mentioned that when there is enough time, he is happy to test, but as soon as he is time-pressed, he also prefers working with testers. The basic reason is simple, developers just like to programme. With a tester alongside them, they have more time to do so. Developing without testers forces them to emphasize the quality of the code right from the start, because without a tester, it is squarely on the developer to submit the right code. Testers are perceived as a safety net, giving the developers more space to do what they love. At the same time, the developers understand that the tester has more experience, knowledge and an independent view on the project at hand. So they can relax more with the knowledge that someone with these skills will go through the whole application and monitor the functionality of the main components.

So how do you view development with or without testers?