Turning the Quality of Your Pipeline into a Team Task

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, this is not something unheard of in an Agile software development team, where quality is a whole-team effort and not just the tester’s obligation.

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 “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 an Agile team. Finally, we will discuss how we, as testers, can facilitate and monitor the implementation of the solutions and the benefits of turning the quality of the deployment pipeline indeed into a team task.