Dear engineers, build-in quality!
Co-author: Rodica Piciorusi
With the adoption of DevOps on larger scales it became a common vocabulary that quality is everyone`s responsibility. True!
Everyone is saying: we focus on quality and we aim to deliver better and faster software, thus increasing the customer experience. Also true!
So, the engineers put in place the tool chain for a successful Continuous Integration/Continuous Delivery (CI/CD), an automated pipeline with monitoring and everything needed for a successful delivery experience.
But when all are responsible for quality, no one takes responsibility.
And this is how after a while, we realize that the pipeline kind of breaks, the incidents are pouring like a tornado and the customers are complaining and still investing a lot of effort in User Acceptance Testing.
But why by having an automated delivery pipeline and everyone focusing on software quality, quality is nowhere to be found ?
Hmmm.. two years ago the The state of DevOps report told us that the most important factor that contribute to a successful continuous delivery is the test automation.
Yet, two years later, only few people seems to acknowledge that there is no CI/CD without continuous testing and there is no continuous testing without automated tests.
Let`s see what the report says: “As we had hypothesized, we found that the following all positively affect continuous delivery: comprehensive use of version control; continuous integration and trunk-based development; integrating security into software delivery work; and the use of test and deployment automation. Of these, test automation is the biggest contributor. “
So we build pipelines and we write code in short iterations, but we don’t do any automated tests and we expect everything will magically work in production.
I know… silly us, right?
Google engineers say: what is not tested is broken.
But is easy to blame, you will say. What is the solution?
To get to the solution we must understand the problem.
And the problem, like it or not, is that all those years of dedicated testers into the teams, made developers think there is a safety net after they push the code, that if they will make a mistake someone will catch it, so their focus is on writing code not on testing it.
I actually heard this statement from many developers along my career. And with the risk of hurting someone’s feelings I have to say: Bad news buddy!
You are not paid to write lines of code you are paid to deliver working software, just like a chef is not paid to mix ingredients is paid to deliver tasty food. So as tasting it, is part of the process for a chef, the same for you, testing is part of writing quality software.
It is a crucial part of the process for delivering quality software.
Also, for many years the testing discipline was seen as the poor brother in the software industry because people always misunderstood it.
But let`s not live in the past and take a look at the first statement “ Quality is everyone`s responsibility! “ to see what is missing. Let`s try to answer a few questions:
Is the product architecture designed with test automation in focus? Well …not quite, because as an architect I have to <insert poor excuses here>.
And this is how we end up with so called service-oriented architectures that do not allow testing and deploying services independently from each other. And this is a major drawback in enabling the team to achieve high delivery performance.
When your ”loosely coupled” units are depending one after another and you cannot test them in isolation, then you have failed.
The architecture should be designed so that it can be tested, deployed and changed with the minimum effort and resources. Designing an architecture that is testable, forces you to design an architecture that is truly loosely couple.
Is the code written with test automation in focus? Well …not quite, because as an engineer I have to <insert poor excuses here>.
And this is how product credibility gets affected by all the bugs that should have been catch by a test. But no one did the unit test because, he might think he’s too senior to waste his time to write tests.
If you find yourself in the above statement take a look at the famous OpenSSL bug HeartBleed or to the famous Apple “goto fail” bug and explain me how this can never happen to you and why unit testing is a waste of time.
All code should be tested by at least one automated test. Either a unit, integration or end to end test depending on the case. The more, the merrier.
As John Ruskin said : “ Quality is never an accident; it is always the result of intelligent effort.”
Is the planning made with test automation in focus? Well…not quite, because as a product owner I have to <insert poor excuses here>.
This might sound a bit harsh, but if you are a product owner and you are searching for excuses on why and how you focus on something else, rather than quality of your product, then you are doing it wrong. Sorry but this is the truth.
Because without Quality there is no Customer. And without Customer there is no Product. That is all. Everything else are just excuses on why we fail.
Ok, we got the picture, you might say! But testing was for so many years a separate discipline and we just don’t know how to do it.
True again! You cannot learn testing overnight just because someone says it’s your responsibility now. Full stack developers are not full stack just because we start naming them like this. We should follow a learning curve.
So the solution to the problem is that everyone learns the testing mindset.
And who can learn us better than the testers that are already doing this for years?
This is where I think people got confused. Somehow everyone started to think that the tester role is not needed anymore and put the testing responsibility on developers without providing them any help.
Congratulations! You`ve just discover the recipe for failure.
The tester role is very important in such a transformation, because we need someone to be the advocate for quality, to teach us the mindset and the best practices that comes with this discipline of testing.
This means that the tester role is not disappearing, it is just transforming. It is the time to take his rightful place into the process and stops being the poor brother of the software industry.
This is how all the big tech companies did it. When they say they have no testers is not because they do not have them, it`s because they put it on the same ladder and are not making any differences anymore between developers and testers.
We are all engineers.
As the State of DevOps report says, automated testing is the biggest contributor to successful continuous delivery process, so we must invest time and resources to learn how to do it properly.
You cannot deliver quality software without tests and you cannot do tests without the proper mindset and skillset.
So the main take away from this article should be a change of mindset. Stop working in vain and trying to patch the product when is already too late. It will not work.
Focus on build-in quality from the beginning, invest from the beginning in automated tests as they are the key for quality of your product.
Remember this fact : Code that is not tested, eventually it will break!
