It is around 16:00 on a Friday afternoon and somebody from the other end of the office says out loud: “Who is working on fixing the API tests?” A silence, as thick as a morning fog, covers the entire floor. Nobody has done anything. Slowly, all eyes are turn towards the tester. How could she allow this to happen? When the API tests fail, the deployment pipeline is broken. When the pipeline is broken, there can be no deployment to production. The hope of a work-free weekend is slipping away… This could be the beginning of a fictional, admittedly a bit corny, story. Unfortunately, in my experience, the statement “everybody in an Agile team should be responsible for Quality”, sometimes leaves a gap in the personal responsibility that each individual has. This can cause, from delays of deliveries to fights within the team. So, how do we create a clear action plan to avoid such drama scenes? In the first part of my presentation, we will identify some of the causes of such a situation, for example

• the “I thought the tester would inform me if something is wrong” misconception,
• the “as a tester, I don’t trust the developers and I should always be responsible for alerting them” mentality, and
• the thorny problem of not having a unified team perception of the importance of each test.

In the second part, we will explore the solutions that can remove each of the causes and look into ways that they can be applied by a DevOps team. Finally, we will discuss how to facilitate and monitor the implementation of the solutions and the benefits of turning the quality of the deployment pipeline indeed into a team task.

A mathematician by vocation, a software tester by profession, I am now working as a cloud quality coach, helping development teams within SAP come up with cloud quality strategies that best fit their