The other side of the moon
We’ve all heard about the Test-Driven Development, but how about the reversed approach – Developer Driven Testing (DDT)? What can we gain and what can we lose by writing our code before writing tests? Let’s explore this approach to software development, which implies setting up QA processes without a QA team.
What guru says
Developer Driven Testing was first time described by the originator of Test-Driven Development (TDD) Kent Beck in his article “Test Infected: Programmers Love Writing Tests”, dated 1998. He explained the process like “code a little, test a little, code a little, test a little.”
The difference
In Test-Driven Development a developer initially writes a group of tests that will fail because of no code, and then they write code that will pass those tests. On the contrary, in Developer Driven Testing a developer writes a small amount of code, then writes a small test, splitting the monolithic application into microservices. In TDD the code is driven by the tests, and in DDT the tests are driven by the code.
Everyone can be turned into a tester
The general vision of DDT is “Every coded feature should be tested completely once, by the developer responsible for implementing it”. In Developer Driven Testing developers write their tests by themselves, only when they feel they’re done with the code. They are the people who have to verify that the code is “good enough,” not the testers. The purpose of this approach is to make developers responsible for their code. Developers employ manual testing, code reviews, and a wide variety of automated testing solutions.
Developer Driven Testing Manifesto lists the following DDT statement of values:
- Early Developer Testing over Scheduled QA Testing
- Quality Assistance over Quality Control
- Bug Prevention over Bug Correction
- Rapid Communication of Results over Consequence Documentation
Will DDT empower software development process?
Let’s study the main pros of DDT:
- Fewer bugs in every iteration
- No extra testing
- More responsibility is given to developers
- Increased velocity
- QA processes without additional headcount for QA team
- No bouncing back and forth between developer and tester
- QA is integrated into the developer’s workflow
- Time-saving due to speed up in testing processes
- Lightweight and effective development
- More accountability
Surely, DDT is not without its challenges:
- A tendency for the amount of time between tests to become longer and longer
- Harder to have a working feedback loop
- Sometimes developers don’t address emerging bugs with diligence
- Harder to keep a big test suite up-to-date
Testing without testers
Developer Driven Testing can enable you to build up QA processes with faster test execution and more coverage while adding no dedicated testers at all. Instead of having the team of testers, developers rely on their own and write both the code and the tests. In DDT developers are responsible for the product at all levels, and this approach makes them care about the quality and the customer satisfaction. Developers know that there is no tester to check everything, and they tend to do the work more seriously. This results in a better bug-free product.
