AIGLU: Agile Testing and Continuous Delivery

AIGLU: Agile Testing and Continuous Delivery

Last Tuesday (22nd of September) was the AIGLU meetup about Agile Testing and Continuous Delivery organized in collaboration with Société Générale Bank & Trust (SGBT).

christianChristian Baumann and “Agile Testing in Practice”

Christian (Senior Test Engineer at Q-Leap) has shared his knowledge about test practices in an agile environment. He wanted to make the link between those practices and the values and principles of the Agile Manifesto. Some of his most prominent experiences include the use of practices such as “group testing”, Behavior-Driven Development and Specification by Example.

Christian has experimented these testing approaches in domains such as Intellectual Property and Civil Aviation. Being a true follower of the Context-Driven school of testing, his efforts brought value to his customers according to the specific context of the team and project he was working on. His experience report was shaped with three different examples of different project contexts. For each of them, Christian provided the audience with food for thoughts and linked back to the agile principles he thought were the most relevant:

  • customer collaboration,
  • face-to-face communication,
  • self-organization of the team,
  • technical expertise,
  • working software as primary measure of progress,

gojkoGojko Adzic and Continuous Delivery

The second speaker of the evening was Gojko Adzic, agile thoughts leader, prolific author and actual father of Specification by Example. Gojko had chosen to talk about Continuous Delivery: how delivering software more frequently can become a significant competitive business advantage.

Gojko started with a warning : faster does not always mean better. It’s not because you “can” deliver software features faster that you necessarily “should”. Statistics prove that more than 50% of the features delivered in the software industry are actually never used. The main idea here is to decide upfront if the feature actually makes sense before you even start development.

He continued with a metaphor about Asimov’s three rules of robotics to provide his own vision of the three rules of continuous delivery.


According to him, continuous delivery may not:

  1. Confuse users
  2. Interrupt users’ work or sessions
  3. Disrupt of prevent marketing initiatives

Respecting these rules requires a very high level of technical expertise. But modern tools and platforms allow us to deploy software in production with multi-versioning, which means that several version of the same product are running in parallel.

This manner of deploying software makes it possible to release features and hide them until we want to officially make them available. This especially makes sense in regard of the third rule. According to Gojko, deployment is a technical event, whereas release is a marketing event. Delivering early in production and deciding when you want to officially release allow to decouple the two events to provide greater competitive advantage.

Maeva Pitou
No Comments

Post a Comment