The goal of the developer is to write reliable and tested code, that he believes in. But companies should strive that he will also be responsible for this code. When a developer sends over the feature to someone else to verify, in most cases he will feel that he has protection and as a result he will feel less responsible for the feature. This process gives rise to developers to think that a task is done when the QA verifies it.

Let’s say you don’t have this step in your workflow, the developer is the one responsible for the feature and for both its reliability and quality. It will produce a more tested code. The developer will think about every step because he will feel that he does not have the QA shield. He might also test manually the feature or even write more automatic tests as developers are lazy.

This will not only improve the code quality, but also the quality of the feature itself and of the subsequent features as the code coverage is greater. Adding more tests gives more confidence in the changes to carry out in order to add more features and go faster. The developer will feel ‘ashamed’ if he has some issues and as a result, he will add tests, alerts and alarms, that will mechanically improve feature quality.

Features need someone responsible from the design time to the roll out to production. The real owner of the feature is the developer as he is the one that can fix bugs, write tests and have the knowledge of what’s going on behind the scenes.

This process won’t remove all your bugs but QA doesn’t find all the bugs either. In a world where you can deploy fixes to production in a few minutes, the responsibility of the developer will give you faster problem solving, more testable code, faster features delivery, more automatic verifications and better monitoring.

If we look at cases where features are verified only by the QA team, this verification won’t find major issues. Indeed, the developer sends the feature in a relatively working state. So, if you think about all the cases where there are no issues at all or no major issues, isn’t this a waste of time and money? It’s just adding delay for no reason.

The methodology of QA as part of the process came from the old days when each customer had a disc and each mistake was very costly. This process is still relevant in some cases — for example, applications that the client installs on his phone. Indeed, you can only fix an issue by releasing a new version of the app that has to be downloaded once again by the end-user.

We need to think about more ways to verify our features, more automatic tests, more responsibility. In any case, features need a feature flag to enable gradual roll out.

Some of the companies can consider early access programs, where some customers can register to receive the latest features that are still in development. As part of this “agreement”, these customers report issues and the developer team receives precious feedback. It’s a win-win situation: customers can see the next generation of the product and the company benefits both from feedback and user engagement.

So, is QA evil? Maybe not! Unreliable developers might be! So, consider QA as a tool and not an inherent step of your process. Let the developer decide if his change needs verification. Give him full responsibility on the feature, you will make him a better worker, and you will get a better product.