Should developers take over testing?

"I dont always test my code...But when I do, I do it in production!"?

Why quality assurance (QA) or software testing should not be performed only by developers?

The question of whether quality assurance (QA) should be handled by a developer is one of the most common in software development. Many companies and teams are faced with the decision of whether they need dedicated QA or whether the developers themselves can be responsible for quality assurance.

A widespread approach is to not have a separate QA and instead engage the developers to test their own software. This approach is often chosen for reasons such as limited resources or financial constraints. But is it really advisable to leave QA exclusively to the developers? Or even to leave the acceptance of its own defined features to a project manager or product owner?

In the first blog post "Do I really need QA?", we talked about the importance of dedicated QA. Here we want to dive deeper into the pros and cons of this approach to help you make a decision.

Why developers should not test their own software

Operational blindness

"Not seeing the wood for the trees” ( german phrase )

Developers are often too close to their own code to recognise bugs objectively. They tend to overlook bugs that may seem obvious to other users and can be serious at worst.

An appropriate example of this would be the metaphor of the previous blog post:?

write a text on a piece of paper and check it for errors. Then ask a second person to correct the text. This person will certainly find errors that you have missed.

Success case

“The acceptance criteria are met, so it's successful, for sure!”

Developers usually test their software under ideal conditions to make sure it works as expected. They tend to spend less time considering negative test scenarios or unexpected usage scenarios.

This so-called happy-path testing is of course a part of quality assurance work, but only a small part of it. The majority of the work consists of testing negative scenarios and dealing with errors. A tester tries to "break" the system to see how it reacts.

It is also important to check whether the implementation of the new software affects existing software in other places or causes errors. These regression tests are often performed automatically during the CI/CD process, but the tester often knows the entire system better than the developer, who has often specialised in a particular area. A basic example of this is the separation between the frontend and backend.

Acknowledging your own mistakes

"It wasn't me!"

It can be difficult to admit your own mistakes. Developers may tend to cover up or rationalise mistakes instead of accepting constructive feedback and learning from mistakes.

Bugs may be quickly missed to avoid putting themselves in a bad light. Psychology should not be underestimated in this area because we are all human and such behaviour is human.

Motivation for testing

"Eat the frog!"

Developers are often motivated to develop new functions and solve complex problems. Testing can seem like a hassle that distracts from the actual development.

How would you complete a task that doesn't appeal to you and just seems like a chore? The task would not be performed with the motivation that a tester would display, as the main part of their job is to find bugs. The developer would certainly not reach the depth of testing that the tester would.

Of course, there are exceptions that prove the rule!

Positive testing

"Sometime the negative parts are also important, but only in testing!”

Developers often test that their software works instead of testing that it doesn't work.

Dedicated QA, on the other hand, focuses on uncovering potential problems and vulnerabilities. As described in the "Success Case" section, I always remember the "nerd tester joke" here:

"If a QA person goes into a bar, orders 1 beer, orders 2 beers, orders 99 beers, orders 0 beers, orders -1 beer, orders a beer, orders an iguana."?

The limit values should not be neglected during testing. This is where the so-called limit analysis comes in handy.

Anyone can test

"Sure, I can do it! Easy peasy! What should I do in detail?"

The worst statement I heard from a project manager was:

"We're having trouble getting testers, why don't you go to the bus stop and ask the people there, anyone can test!"

Testing requires specific skills and knowledge. While any developer can perform basic tests, a professional QA is able to perform more comprehensive and effective tests. Again, the different motivation and thinking outside the box or thinking "differently" is crucial.

A tester thinks differently than a developer.

Anyone can also build a house, given enough time and money. The question is, how good is the quality of the work? How long can I live in the house? And: could I have built the house faster and more stable with a professional at my side or a specialized company?

Economic efficiency

"Time is money, we have neither of them."

Developers have often studied computer science for 3-6 years, while testing is a popular career entry job.

It is therefore not unusual for a tester to earn less than a developer.

So why let an expensive developer do the work of a "cheaper" tester when the result is obviously getting even better if a tester does it? It's actually a clear win-win situation. In addition, the developer can concentrate on further developing the software or implementing additional features.

DevOps and QA

"Cobbler should stick to his last” ( german phrase )

The rough approach of the DevOps methodology is: everyone should be able to do everything, at least a little bit. I see a lot of overlap here between developers and operations (admins), but between QA and DEVs I see a clearer separation of the specialist department and tasks.

An agile team should not only exist of developers, but should at least have product managers/product owners and QA as part of the team. Of course, the SCRUM master should not be forgotten here either.

The above points clearly speak in favour of thematic separation, even in agile teams. I don't think it makes sense to completely take over QA responsibility and tasks from the developers. The specialisation in the specialist area is simply too great; it is not without reason that there is a separate professional division for the testing area.

So what should a developer test?

Developers should of course also keep the quality flag flying high and ensure that their code is tested as well as possible. Local tests as well as unit tests and code reviews are part of the quality assurance process here.

The developer is by no means "relieved" of not paying attention to the quality of the product or software. An efficient division of tasks and responsibilities between QA and the developer is the be-all and end-all here.?

The obligatory "just throw the software over the fence" and let QA do the work been outdated for a long time now.

Closing words

In the end, it is the service provider and its name that is responsible for delivering quality, not individual departments or employees.

Dedicated QA offers a variety of benefits, including objectively evaluating the software, identifying issues from the user's perspective and ensuring consistent quality.

While developers play an important role in the testing process, they should not be solely responsible for quality assurance. Professional QA can help improve the quality and reliability of the software and increase user confidence.

The only given advantage of having a developer do the software testing is that you don't have to hire, find or train a QA. However, this is where I can support you and take your quality assurance to the next level and help you work more efficiently and effectively in your agile teams!

I look forward to your contacts, your feedback or your ideas and questions.

This article can also be found on the website of:

Fullstack-QA

Autor: Julian Farizi / 05/2024 / Should developers take over testing??