At work I was asked, together with a colleague, to come up with a plan on how to improve/introduce automated testing on our two systems.
It didn’t take us long to identify that integration testing was the way to go. We presented that track. And we were met with questions such as “And how are you going to measure the amount of defects we have?”
Well, would the quality of our systems improve if we measured the amount of defects they had? Would it tell us anything more than the amount of faults they used to have? (Or still have if the mentality is to tolerate and not fix the bugs)
Our plan was completely different.
Quality is something that you build into the system and testing is a tool that can help keep focus on it.
People are fond of TDD because the quality of the code can improve when you use it. It helps you keep track of the intent of your code, make it more structured and hopefully keep the complexity down.
In the same way, by using BDD and integration testing, you can keep track on the goal of the system. What business value does your code add? Who will use it? What is the desired effect?
Even though they are testing techniques, they are also development tools. And an interesting part in introducing quality.
The search for simplicity 