Don’t compromise on automated testing

It’s surprising how hard it can be to reach a common understanding of what DevOps is. While Netflix and Amazon have set the gold standard – you don’t need to join these massive corporations to maintain a fully automated DevOps operating model. It does require that your organization’s management, architects, developers, and testing teams agree on what DevOps is - and isn’t. Otherwise, the change process you are about to undergo is doomed to fail.

Nicolai Graff Andersen
CIO and Partner

So you’ve decided to transition to DevOps… now what? While we believe that is an insanely smart decision, figuring out where to begin can be a challenge. It is important to begin defining what the core principles of DevOps will mean in terms of day-to-day operations for your organization.


It can be challenging to establish a consensus around how to implement and maintain the DevOps operating methods. You must establish complete buy-in across your organization – ensuring all levels of management and the engineering teams understand the basic idea behind DevOps and work according to the same objectives. Otherwise, the change process you are about to undergo is doomed for failure.

Let us set the scene explaining how we define DevOps:

Quote Icon

DevOps is a set of practices that combines software development (Dev) and information technology operations (Ops) which aims to shorten the systems development lifecycle and provide continuous delivery with high software quality.

Source: https://en.wikipedia.org/wiki/DevOps

DevOps is a practice that aims to shorten the development and supply cycle and enhance the quality of software deliverables. While it is likely that your management teams have been introduced to the DevOps methodology in concept, not all organizations have navigated the transition to realize the potentially productivity improvements and lightning-fast time-to-market that front runners have achieved. According to the State of DevOps Report,  this methodology, when successfully implemented, enables organizations to “deploy 200 times more frequently, with 2,555 times faster lead times, recover 24 times faster, and have three times lower change failure rates.”

 However, it is quite important to understand that the results have only been achieved by being uncompromising. DevOps is best visualized with the "you-build-it-you-run-it" model, which is practiced by some of the pioneers in the field, such as Amazon and Netflix.

Either/or?

Does this mean that it’s either/or, and that DevOps is only for organizations that are ready to go all-in? No, it is not necessarily so binary. But we should use the pioneers as points of reference and as guiding stars that demonstrate what is possible. There are insights and smaller steps that can be taken to follow in their footsteps. Any action - organizational, procedural or technical - that reduces the development and supply cycle and enhances quality of your output is a step in the right direction.

100% automated

If agile transformation stopped at planning boards and stand-up meetings, then the road to realizing benefits of a fully automated DevOps program would be long. Whilst Agile and DevOps methodologies aim to resolve different problems, there is one key overlap. In agile transformation, your organization should aim to breakdown the barriers developers and the testing team. This requires first focusing on testing and quality assurance as a key element in your development process, where most actions are more naturally fully automated.

With DevOps, automated testing is a key element. There is no sense initially considering daily deployments if you have not automated your QA process. So whilst your Head of DevOps (or whatever he or she is called in your company) is working on the organizational changes that are needed to bring your Dev and their Ops closer together, take a look further down in the engine room.

Evaluate the processes you practice in your agile development. If you don’t already have a process and a culture that strives towards 100% automated testing and a joint supply responsibility between Dev and Testing teams, then this is a very good place to start. While it may be hard to imagine, this can be done in parallel with the large, organizational transformation of Dev and Ops.

Next step?

Let's have a conversation about your current IT needs and discuss the options to realize your vision.

Let’s book a meeting