The Whole Team approach to Testing in Continous Delivery

How to test faster while pusing towards a more automated environment of continous delivery?


Tutorial Day 2

Speakers

This was a tutorial I was really looking forward to. This session was put on by Lisa Crispin & Ashley Hunsberger. I’ve read Lisa’s Agile Testing book, and I head Ashley speak at Selenium so I had a good idea of the people I was going to learn from. So not only were the people that I knew this is a topic that is going to fit perfectly in to some changes we had upcoming here at Miami.

What is the biggest thing that is keeping you from implementing Continous Delivery

We started the session forming teams that we would work with for the rest of the day (more about my team later). We then generated a list of things that prohibited our teams from implementing Continous Delivery. Our team came up with several and they seemed to boil down to changing the culture. We also talked about our teams Definition of Done (DoD) and Definition of Ready (DoR).

What is Continous Delivery

Continous Delivery doesn’t require full automation. Now it is true that if it an automated solution then it is probably easier and delivery can happen quicker but that is not a requirement to implement the continous delivery ideology. Continous delivery is really talking about the “pipeline” or flow that is taken from the code being commited in a repository to the value is actually delivered into a production environment.

During the day Ashley and Lisa gave aus different ideas and scenarios and it was our job as a team to discuss and determine the best way for our code to be released through the pipeline. We did determine that there is no right way. There are many steps that you code will probable travel from check-in of code to deployment into production.

I am really excited to get back to Miami and talk to co-workers and see what we can come up with as a solution to help our code better and easier to realease into production.