Testing, Checking and Continuous Integration

My team has been looking into how we can employ continuous integration in conjunction with our software development lifecycle. We are currently on the early stages of adopting agile and perhaps understand that this requires effort and is not just a switch that we can flip.

I must admit that I had reservations with the whole idea of continuous deployment because it seemed to not have a place for exploratory testers like me. It was until I had a conversation with Adam Goucher early this year when he mentioned that there are two schools of thought when it comes to continuous integration, Continuous Deployment and Continuous Delivery.

Continuous Deployment is essentially a process where after a developer commits code into a repository (repo), automated tests are then executed and once every test passes, the code gets deployed to production without any human intervention.

What happens in Continuous Delivery on the other hand, is that after the developer commits code into a repo, all existing automated checks get executed, and once all the checks pass, testers can then start testing, since all the known parts in the site that should work are still working.

As a tester, Continuous Deployment is a heresy and is unethical because it assumes that all your automated tests are good enough to a point that it no longer requires human judgement. Continuous Delivery on the other hand recognizes the fallibility of automated scripts and relies on human judgement to ensure that all the acceptable risks have been mitigated, then we can say that the code is now ready for production.

Testing has a place in Continuous Delivery, but not Continuous Deployment. Checking on the other hand is KING when it comes to Continuous Deployment but works hand in hand with testing in Continuous Delivery.