{"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":"

Testing the expected & intelligent automation vs. exploring the unexpected: Shift Left & Shift Right practices<\/strong><\/em><\/h4>\n

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

\n
\n
\n
\n