Testers Should Not Fear Continuous Delivery

Continuous delivery is becoming an increasingly popular buzzword in discussions around agile software development and testing. With promises of increased throughput and speed to market, continuous delivery seems like a silver bullet solution to solve some of the common woes of today’s software organizations. However, there are many misconceptions about what continuous delivery truly is – as well as what it is not. As testers, it is important we understand not only how continuous delivery can affect the engineering organizations we are a part of, but also how that will impact our day to day roles.

What is Continuous Delivery?

Kieff Morris explains Continuous Delivery this way

– “Continuous Delivery doesn’t require frequent releases, it only requires ensuring software could be released with very little effort at any point during development.” A common misconception is that software developed in a continuous delivery environment is not acceptance/integration tested manually – that is not the case. As explained succinctly in this blog post, continuous deployment teams must use continuous development processes, but continuous development processes do not necessarily rely on continuous deployment.

Why Employ Continuous Delivery?

Continuous Delivery can potentially require a great deal of effort to implement – it requires not only a specialized set of tools, but a change in development process and mindset. However, the benefits of properly implemented continuous delivery are clear – usable pieces of software code can be delivered more quickly, allowing the organization to be more nimble in software development. Additionally, moving towards this method of delivery can more tightly integrate the various departments of the organization due to the increased reliance on developers to create good unit tests, and testers to understand development activity.

How will this affect me as a tester?

Testers often fear that a shift to Continuous Delivery will in turn mean that the testers’ role in the organization is deemphasized. This misconception is driven by the belief that manual testing will be reduced as the library of automated unit tests grows. While the testers’ role may evolve with the introduction of Continuous Delivery, their importance to the team is not reduced. With developers being tasked to create a large library of automated unit tests to reliably regression test the system with each code check in, testers must assist the developers in designing good tests. Additionally, as testers are relieved from having to perform regression “checking” with each build, they can shift their focus towards more creative and engaging testing to drive deeper coverage and explore new areas of the application.

Overall, Continuous Delivery should be seen as an opportunity to improve engineering organizations and as a change initiative that can allow testers to refocus on higher value activities. The automation of regression “checking” will improve the life of the developer and tester alike, and allow machines to perform the work that they truly excel at. As testers, we must understand that this change will undoubtedly change our day to day responsibilities from the traditional/waterfall manual testing role, but we should be excited at the opportunity to elevate our value within the development organization. At the end of the day, properly implemented Continuous Delivery practices have the opportunity to allow our development organizations to provide better software faster – which is our ultimate goal.

Leave a Reply

Your email address will not be published. Required fields are marked *

More Great Content

Get Started with qTest