Quality Assurance is critical in Continuous Delivery. Every change we commit to the common source repository is a release candidate. That’s why we test our code before we release it. We find out whether objectives has been met or not. Unfortunately, testing is a discipline that many try to avoid and it’s one of the main reasons for having specialized testers in the teams who know how to break the code best. But shouldn’t be the developers of the code know best how to break it?
Sometimes I get the impression that we write tests only because it’s required from someone with influence. How can we change this behaviour and how can we change to a mindset where critical testing is as normal as writing the code that is to be tested? Imagine someone ask if your code is tested enough to ship it – and you look the person in the eyes and reply calmly but with a little pressure in your voice: ”My code is correct and I can prove it.”.
Testing has many years ago become its own discipline in IT because we all know how hard it is to deliver great quality. And great quality requires great experts. Obviously, the experts are not the developers anymore – it’s the testers. We even started to distinguish between technical tester and functional tester. Some companies started to call testers “Quality Assurance Analysts”. First of all, I like it when important areas get more attention. Second, I also think we can do more on the developer side of testing, just to highlight its critical importance in Continuous Delivery that is so important.
Just a week ago I listened to a chat between two developers. They talked about Code Coverage and that they need to test a bit more in order to pass the Code Coverage Analysis Tool that is part of their Continuous Delivery Pipeline. “I’ll just test some setter/getter methods and the code will hopefully pass the step.” said one of them. “Yes, or maybe we just decrease the passing value.” replied the other. Their talk missed the point of this tool and they knew it. Martin Fowler wrote about Code Coverage where he explains why it’s needed.
If we want to implement real continuous delivery or even continuous deployment we must be sure about what we commit to the source repository because it will go out into production and it will smell if it isn’t tested well and it will hit the customers at the end. Great quality is critical and we should try to prove that what we deliver is correct and that it works.
“Stop Testing, Start Proving.”
You probably ask what’s the difference between testing and proving. Maybe nothing, maybe everything – it depends on how passionate you’re about your code and Continuous Delivery. If I want to test my code I probably write some average tests. But if I really want to prove that my code is correct I put a lot more thoughts into how to write the best and the most understandable tests I’ve ever written. There should be very little reason to doubt the validity of this proof. Don’t aim for a proof like Einstein’s equation E=mc2. Still, it should be constructionist, like building a house. And that house should be robust and stable so it won’t fall apart next fall when wind and storm hits with 120 km/h or more. Top 3 DevOps Practices for Operational Stability – by Sven Malvik
Can’t Prove It, Can’t Ship It.
