Tuesday, 10 March 2015

The Dark side of Continuous Deployment

A short post!

In the software development world there is a drive towards continuous deployment of software which in the majority of cases in a good thing.  The good side is the reduction in costs, faster feedback from users and quicker release of features and bug fixes.

However my experiences of using software in which there are constant and frequent updates provides me with some concerns.  Have you ever downloaded an app for your device that crashes upon starting or has new updates each and every day?  How does this make you feel?  I for one get very frustrated when I get up in the morning and my phone says x number of apps have been updated.  Or that the same app I have updated 3 times previously in the last week!  Suffice to say this app have been deleted and I no longer use it.

There is a common phrase that appears to have been forgotten in the rush to continuous deployment and using users as testers and that is "First impressions count"  If you come across a piece of software which you have purchased and it is buggy or does not work in the way you expect you may feel cheated.  All software has bugs that is to be expected, my worry is that we are paying for software which has not been sufficiently tested by skilled testers.

There is a major movement to automate 'testing' within continuous deployment practices.  This implies to me that those who promote and suggest this may not have an understanding of what testing is and the value it provides to the quality of software.  This is a big assumption for me to make but I am experiencing more and more examples of software being released to users which is not good enough and with a little bit of testing could have provided a much better user experience.

I am not saying to stop doing continuous deployment but within the development cycle there should be some level of human testing to provide information about how the software is behaving.  This is not meant to say have a dedicated testing phase but ensure that testing activities are added into each and every release. Continuous deployment is a wonderful tool to enable quick and easy releases however it should not be used to release poor or sub-standard software that relies on users to provide details of issues, especially software that a user has purchased.

The key problem to me as someone who works in business is that if you release poorly tested software and it is noticed then the chances are they will not come back and you will lose their customer.  If this happens again and again you may find you do not have a business, social media is powerful in allowing those who experience bad software to make it know very quickly to a huge amount of people.  Can your business take that risk?

RANT over.....

Over to you the reader, what are your thoughts on this?

Further reading:

Testing vs Checking refined - James Bach
Continuous Deployment - Agile Alliance
Why continuous deployment - Eric Ries

1 comment:

  1. No – the business I work in could not take that risk. I work in the medical device business and errors in our software could have very sad consequences. So I totally agree.

    A continuous deployment mindset with continues integration, static code checks, automatic checking etc., is in most cases beneficial (finding bugs as soon as possible). It’s in most cases also good to be able to release with short notice in order to be agile and flexible. However we always need to add manual sapient exploratory testing (and manual checking) before release. This we do continuously by having testers in our development teams. When we develop a new feature we also have a lot of customer interactions with mock-ups and prototypes etc., before we get to the final thing.