Agile approaches are great and everybody uses them. Many either already do or plan to switch to continuous delivery models, where business value is shipped to production after each sprint or increment — every 2 to 4 weeks. No more waiting for months or years until new functionality is available for the business departments and customers. What an improvement compared to the past waterfall projects, where new value was generated after long project duration, often years.

There’s a good and a bad side to everything

One of the main risks of continuous delivery pipelines is, that the latest improvement of a single component doesn’t work well together with any other component of the overall system landscape. Just because developers tested a new feature (supposedly without any side effects), it doesn’t mean that all other components or features still work. In waterfall projects you’d reserve approximately 33% of the project time for testing, fixing and retesting. You’d do that in waves. Of course there was never enough time to finish coding until the testing started, but at least the whole system was tested — not only single components or features.

In continuous delivery models there is no time for thorough manual tests, usually less than 1 week between a developer has completed his task and the code reaches production.

On the other hand, there’s no way to not do agile. Your competition does it, brings new value to it’s customers more or less regularly. You can’t fall behind unless you’re way ahead — which in a global economy is highly unlikely.

Micro-services help — a bit

In theory micro-services are independently developed components of a system architecture, that have backward compatible interfaces, work seamlessly together for instance via REST APIs and break up the complexity of monolithic systems into manageable chunks. What a revelation to have them!

If all developers, designers and business requirements would adhere to these principles, it would indeed mean testing of a new increment is a simple as testing only a single micro-service. The rest of the landscape would work as before.

Reality shows a different situation. Micro-services are in their first release developed and designed to be independent. Wonderful. As complexity raises and more functionality is needed we start to interchange more and more data through the interface. First only a few flags, then also some input-data, that doesn’t quite fit into the database, then some additional attributes in the response, that help the receiver to decode the message body. Soon you find yourself in a situation, where in order to upgrade one functionality, you’ll have to simultaneously bring 5 or 10 micro-services into production. Before you burn me alive: Yes, of course this shouldn’t happen and probably it was bad design from the beginning and instead of doing this, refactoring and redesigns should be done. Have you ever heard of everybody´s companions “budget” and “timeline”?

Agile without automation testing is reckless

If you have CD/CI-Pipelines and you don’t have a very good set of automated test cases automatically integrated in the deployment process, you’re in for trouble. It worked for you for the last year? Two years? Hard to believe, but not impossible. It won’t work forever. We’re talking about your production system — the most important software and visible interface between your company and your customers, partners and employees.

Good automation testing is not free. Test cases need to be maintained and improved/extended in the same rate, that developments happen. Usually you’d pay for pretty expensive software, that has per-seat or per-user licenses, limiting the number of people, who can work on automation testing.

Don’t be reckless

Check out open source test automation suite baangt.

• No vendor lock-in
• Open source software — easily extendable and fully documented
• No license costs
• Code-less test automation based on Microsoft Excel
• Business people can create and maintain test cases. Not only a few experts.
• Simple integration with any CD/CI system and strategy