I was in a meeting where a developer said: “every test is a form of waste”. Coincidentally, this meeting was about how the build was taking too long because the tests were slow, so I can see how the connection was made in the mind of the developer. It must be the tests, right?! What a waste (a waste of what actually? Time, money, effort?). However, I think this is a fallacy and I would like to use this blogpost to explain why.
In my career in IT I have heard remarks from some developers in different shapes and forms about how testing is wasteful: it takes too long (“I have spent 3 hours developing the functionality, now I have to spend 6 hours writing tests, how stupid!”) , it is boring, tests are flaky and besides: after all the effort put into making the tests work there are still bugs! Gosh.
Consider the following statement: In essence, with tests we cover (and store) the WHAT of business requirements while the implementation code covers the HOW of business requirements.
I realise that without the implementation code, there is no reason for tests to exist so you could make the argument that the implementation code is also the WHAT of business requirements. However, I hope you agree with me that it is very dangerous and irresponsible to only have an implementation (the how) without storing the requirements of this implementation (the what) in tests. This is one of the reasons why we write tests and why techniques like ATDD, BDD and Specification by Example exist.
What do you think changes more often: the requirement or the code to implement the requirement? Coding standards evolve, programming languages change, developers leave the team, new developers join the team, refactoring is needed to keep the code clean, and so forth.
Of course, requirements change as well; this is one of the hallmarks of agile development. But, in order to implement a change or new requirement more often than not you change existing code as well. So what survives longer? The requirement-covering test, or the code to make sure that the test passes?
Think about that for a minute. Do you still want to make the case that tests are a form of waste?
No, the opposite is true! A test is not waste at all, because a requirement (and therefore, a test) survives longer than the code that implements it.
When you invest in a process like ATDD, BDD or Spec by Example with your team, you will acquire a good base of tests over time. Then, it will actually be easier for you to change the underlying code.
Would you call that a waste? I wouldn’t.
Interesting topic. Also very nice graphics in this article.
I guess you could argue that everything except working code (or something that adds value to the actual product) is a form of waste. The less documentation/requirements and testing you need the better.
If you are working in a self-organizing Scrum Team, with a good Scrum Master and Product Owner, and have regular interaction with the stakeholders, the need for written, detailed requirements might decrease, and if everyone in the team take responsibility for quality and actively work with it throughout the life cycle of the product, then the need for testing might decrease. For example if you actively work with keeping the complexity of the product low, then the need for extensive system test might decrease.
But calling “every test a form of waste” is probably just a provocative statement to get a discussion going 🙂
Good article.
Thanks for your reply Johan. This was my first time trying to create my own graphics, so I especially appreciate your positive comment on those 🙂
I think it’s a good point to always aim for low complexity. I have seen many projects start with that thought in mind. But somehow….we humans seem to make stuff complex! (You could also make an argument about how ‘too complex software is wasteful’!)
I think at least making the tests executable (automated) will solve some of the waste-problems we create as a software development team