The comic above makes a good point. It is common to expect code to include executable tests that demostrate that it works as expected. Even if you deliver on time, have team full of experienced engineers and otherwise describe yourself as putting quality first face with a code base without test I’ll be thinking

  • You delivered on time but there are no tests – what other corner have been cut?
  • You have experienced engineers that don’t write test – your definition of experienced is different to mine
  • You say you put quality first but you don’t measure it – How do you know you are delivering a quality product

From my perspective reputation and credibility is eroded if I can’t see your quality assurance process in the code.  Having worked on solutions, some that had automated tests and some that didn’t, I have first hand experience of the compromises that are made when some form of automated testing in not there.


There is a good way to test and a bad way to test. Often, you see tests that simply test that the code does what the code does. What use is that? Instead the tests should represent the requirements and therefore assert that the code meets the needs of the business. So while it can be painful to discipline yourself to write test firsts it often results in a solution that better fits the requirements.  It takes time and effort to get there.

Developers and testers have different skills, they think differently.


The roles should complement each other. Testers can show developers how to think critically about their solutions whereas developers can help testers with the coding skills that are increasingly required to build a reliable and repeatable test suites.

Writing code, testing it, finding bugs and fixing them up is a natural cycle of software development. It is said that people learn more from mistakes so perhaps creating, understanding then fixing bugs makes a software team better.


Rather than focusing on stamping out bugs the focus should be on implementing a series of practices that increase the quality of the team output, which would include more than automated testing. The team needs to understand how to write good code, continuously improve it through refactoring and find ways to continuous measure the quality of their output. That is not only in terms of test coverage, but measuring other metrics such as the cycle time to deliver a story to the definition of done and code analytics like cyclometric complexity and method or function size. Thinking about it, it is not about testing code, instead we should be focusing on measuring quality metrics.


One thought on “Quality shouldn’t be testing

  1. “You cannot inspect quality into a product.” – J Edwards Deming.
    Testing afterwards adds no value, better to build the quality in to the product in the first place. In software, test-first practices go a long way to achieving this.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s