{"id":20913,"date":"2019-09-05T12:30:08","date_gmt":"2019-09-05T11:30:08","guid":{"rendered":"https:\/\/www.devopsonline.co.uk\/?p=20913"},"modified":"2019-09-05T12:36:39","modified_gmt":"2019-09-05T11:36:39","slug":"shift-left-vs-shift-right-practices","status":"publish","type":"post","link":"https:\/\/devopsnews.online\/shift-left-vs-shift-right-practices\/","title":{"rendered":"Shift Left vs Shift Right practices"},"content":{"rendered":"
Are you worried about your organisation\u2019s ability to cope with the complexity of delivering at high velocity, with excellent quality, in multi-speed IT landscape and hybrid environments?<\/p>\n
DevOps – an art (combination of philosophies, methodologies & tools) of delivering products and services at a higher velocity as compared to traditional SDLC methodologies \u2013 now, I always like to add a statement that Velocity without quality is of little use \u2013 and that\u2019s where the question of testing comes up.<\/em><\/p>\n There has always been a confusion (to say the least) about the role of testing or testers in the DevOps world.<\/p>\n While ‘continuous testing’ and ‘quality engineering’ are some phrases that have taken a front seat when it comes to DevOps \u2013 one always wonders where to draw the line. How to assess how much QA is actually needed, and in which phase, or is there really a phase?<\/p>\n Whilst Shift Left is what everyone is talking about, what does that actually entail? And then of course we have ‘testing the unexpected’, ‘testing in production’, ‘exploratory testing’ etc., \u2013 or Shift Right.<\/p>\n From my experience across multiple enterprises, as they go through the transformation journey from traditional SDLC to DevOps, and while we try to align practices to meet difficult demands from the complexities arising in a true multi-speed IT environment \u2013 I have built a perspective.<\/p>\n Shift Left is something that is simpler to implement. The IT community has put in lot of effort into it, in terms of setting up guidelines, tools and frameworks for early validation and verification. More unit and component level testing, early validation of services and techniques like service virtualisation for early integration testing are practiced.<\/p>\n However, it is more about ‘testing the expected’ and does very little for real-time feedback and exploring and base-lining the undefined and unknown. However, this still remains an integral part of the continuous testing framework.<\/p>\n I have read, learnt, experienced and implemented many paradigms of intelligent automation. But, if I have to define it simply, then the features that one should expect from an automation framework in the DevOps world are:<\/p>\n <\/a><\/p>\n Progressive \/ in-sprint automation and Shift-Left is the backbone of continuous testing that is mandatory for ‘validating the expected’ for successful DevOps and intelligent automation framework is what makes it possible. We have implemented different flavours of such intelligent automation frameworks leading to 20-25% savings on total cost of quality ownership for some large enterprises.<\/p>\n There is a testing pattern in which before replacing an existing service with a newer one in production, we replicate and direct the real time production (with older version of service) request traffic to a staging environment (with newer version of service). Then results from new service are validated against production results.<\/p>\n This is defining the unknown and unexpected as to how the new service behaves with the production request data. This is a neat way of Shift Right testing \u2013 without breaking anything in production as such, and without spending too much money on creating huge amounts of test data to mimic all production scenarios.<\/p>\n The idea behind this is fairly simple \u2013 can we avoid 100% of failures in production in complex distributed and hybrid environments \u2013 application issues, environment issues, service failures, configuration issues etc.? If not, then why not induce controlled failures and see how resilient the product or application is under the failure circumstances.<\/p>\n\n
In a nutshell<\/h4>\n
Shift Right in the context of services and APIs testing<\/strong><\/h3>\n<\/div>\n
Chaos Engineering<\/h3>\n