In this interview, Shankar Konda from TCS discusses the long-term viability of the shift-left movement, how to achieve the best returns when abiding by shift-left principles, and how DevOps and continuous integration fit in to the shift-left world.
Josiah Renaudin: Today I’m joined by Shankar Konda, a practice lead for Banking and Financial Services, North America, for the Assurance Services Unit (ASU) at Tata Consultancy Services. We’ll be speaking on shift left and first-time right, with a focus on the cost of failure in this digitally connected world and how QA and testing teams have a major role in assuring end-customer experience.
To start off, could you tell us a bit about your experience in the industry?
Shankar Konda: I am a certified quality analyst with twenty-four years of experience in quality assurance and testing. My experience includes testing engagements such as setting up testing shared services and TCoEs (testing centers of excellence) and leading end-to-end transformation programs from traditional to more robust and scalable setups.
Josiah Renaudin: With your extensive experience, you’re the perfect person to talk to about this topic. In this era where releases happen on a daily basis, rather than a weekly or monthly basis, “shift left” seems to be the mantra that organizations are adopting. And while we hear about the benefits, we don't really know if it's a trend or a fad. In your opinion, is shift left really helping enterprises in the long term?
Shankar Konda: Thanks, Josiah. Yes. At an overall level, I would say yes. In this digital era, businesses today can no longer stay relevant and competitive with traditional testing lifecycles. Releases no longer take place every six months to one year. Now, we are talking about monthly releases, biweekly releases, and some releases and updates even scheduled on a daily basis. Hence conservative waterfall methodologies where testing is completed at the end of the lifecycle are no longer valid in today’s business context.
Businesses need accelerated speed-to-market with zero compromise on quality. The shift-left approach can help them achieve this objective. Organizations have embraced the shift-left approach and are moving away from a shared services model like the test center of excellence to a more federated model of testing, where quality assurance and testing teams work collaboratively with the development teams to be part of the respective lines of business.
Josiah Renaudin: Absolutely. And similar to agile, when enterprises are adopting shift left, they also need to consider the risks and effort they need to invest before it can be successfully implemented. So, what are the factors that organizations need to keep in mind while adopting shift left in order to gain maximum returns?
Shankar Konda: You are right. “Shift left” is not a buzzword anymore. It cannot be implemented on a whim. Shift left is more of an approach to how things should work from a process point of view, and how it optimizes the overall cost of quality. There are certain risks as well. If roles are not clearly defined and expectations not set right up front, it may lead to conflicts within teams.
As I mentioned earlier, shift left is more about how we accelerate the development activity in conjunction with the testing processes. Testing as a function is shifting. One needs to interpret testing expectations earlier in the lifecycle—during the design or development phase—to be successful. But the most important thing to remember is that quality is not the responsibility of the quality team alone. Everyone owns quality.
The mindset of the business, development, and testing teams needs to change to work together. They now belong to one team and not three separate teams. All of these put together ensure the success of shift left. So what is needed here is a mindset change. The collaboration between all these teams helps reduce defects getting into the software application.
To ensure the shift-left approach is engrained into an organization’s DNA, the organization needs to focus on cultural change, clearer job role descriptions, investments in trainings, testing teams working closely with development teams to complete their tasks, process discipline, matrix discipline, and quality discipline. Some of the metrics that should be maintained are percentage automation covered during integration testing, number of defects detected and resolved during continuous integration testing, requirements stability index, test coverage completed prior to systems integration testing, etc.