Is testing is best done by developers?

Or, put another way, is development best done by testers? Dedicated test teams can hold you back, not by verifying software but by allowing developers to deliver software that does not work.

Does this sounds familiar?

Developer: “I’ve finished the customer management story, it’s ready for test”

…moments later…

Tester: “I tried creating a new customer called ‘<a>click here</a>’ and look what happened!

What happened wasn’t that the tester used his or her unique skills to think of an edge case. They didn’t outwit the developer, they didn’t even attempt something particularly unexpected. What happened was that the developer was lazy, not even taking time to check he or she had delivered working software.

I heard this recently,demonstrating why it is we have test teams and why I find them to be counter-productive:

Developer: “If I have to write all the acceptance tests it’ll slow me down, that’s what testers are for. I didn’t become a developer to spend my day testing!”

Testing is the developer’s professional duty

Professionals take responsibility for the code they write. They do not release code unless they know it works. Think about that for a minute. How can you possibly consider yourself a professional if you are willing to release code that you are not sure of? Professional programmers expect QA to find nothing because they don’t release their code until they’ve thoroughly tested it. Of course QA will find some problems, because no one is perfect. But as professionals our attitude must be that we will leave nothing for QA to find. ‘Uncle Bob’ Martin

I’ve previously written about professionalism in software development and a professional must deliver more than just lines of code. A software engineer will deliver code which:

1. Is verified as working
2. Meets the originally stated brief
3. Is supplied with all other necessary artefacts (documentation, environment changes, release notes etc)

This means all testing of the software occurs before release from development and if that is to be effective it means continuous, automated, full system testing. Since this testing guarantees working code and a working system then there is no need for the extra validation of a dedicated test team.

Testing is not as difficult as writing correct code

There is a myth in software development that developers are good at software design and coding but “too close to the code to test”. This is of course absolute nonsense.

If a software engineer is unable to exhaustively test their own code they must also be unable to correctly develop it in the first place.

All that is required during development is knowledge of the same failure modes, testing methods, pitfalls etc that testers look for and, most importantly, a desire to avoid them. The information is readily available all that is needed is a different mindset from the developer: Now I’ve written this code what’s the best way to break it? In fact developers tasked with breaking a system will always be able to find new and unpleasant ways to destroy it through their intimate understanding of the code.

What’s a good developer to tester ratio?

The testing of any new code by developers will always be more efficient than using a dedicated test team. At any level. On any task.

When a good development team is presented with repetitive tasks they automate them and if they are any good they look at ways to continuously improve the coverage and efficiency of the tests.

Test teams are an enormously expensive way to allow development teams to under perform.

What about the things we simply can’t automate?

“Can’t automate” in this sense means “don’t want to spend the time automating”. And that may be valid – is it worth the time?

XKCD: Is it worth the time?

Give the development team the repetitive, soulless, mind-numbing task of writing and updating the test scripts and manually testing each feature which cannot be automated; eventually they will automate it.

The best way to get working code from a development team is to make them responsible for it

When a development team is required to produce a verified working system they will take on responsibility for it. Current common practice is to delegate responsibility for a working release to a different team! When it is a developer’s responsibility to ensure that his or her contribution works when released naturally motivates them to be more rigorous.

This revolution has already happened with devops. Where once days or weeks might have be spent promoting a release to a live environment software is now released continuously with full confidence of success.

TDD + DevOps means it’s already regression tested

If development is test-driven, if you have exhaustive unit tests, integration tests and acceptance tests and those tests are run on production-like environments then what is it that your test team is doing anyway? Are they verifying the ‘softer’ aspects of the system – that it ‘looks nice’? Should they be, is it their call?

You still need QA

A QA team dedicated to the process of guaranteeing the continued high quality of the system may well still be required to guide the development team as they test, and to ensure the continued high quality of the system. The QA team may define and lead the testing processes, continuously analyse the quality of the system and perform more holistic and exploratory testing initiatives. This developer testing approach does not remove the need to perform verification of the code or system, it moves the effort of actually performing the testing to the same team that writes the code.

Great in theory?

Not just a theory, big companies like Atlassian are doing it.