Shift Left but Get It First-Time Right: An Interview with Shankar Konda

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.

Josiah Renaudin: Yes, and I like how you said that shift left is not a fad or a buzzword, because a lot of people might think just that, so it's good to dispel these misconceptions.

So, moving along, can you give us a few examples of companies that initially reserved testing until the end, but then moved over to shift-left practices? Most importantly, what were some of the tangible benefits these companies saw?

Shankar Konda: The client benefits achieved from adopting the shift-left approach are clearly visible. The most important benefit is the time it takes to get the delivery out of the door, and improvement in quality. The turnaround time and cost are much lower for a defect to get resolved, as the gap between the requirements, development, and testing teams is eliminated.

To take an example, a banking client that implemented the shift-left approach achieved reduction in test execution time by 20 percent, faster resolution of risk and regulatory compliance requirements, and improvement in quality, with less than 5 percent defect leakage into UAT [user acceptance testing]. The defect injection rate during the development of code reduced by almost 30 percent and thus helped reduce the cost to fix the defects. This helped them achieve accelerated speed to the market.

While shifting left, they also ensured it was first-time right. They were able to achieve these twin results by adopting a test behavior-driven development approach with an integrated set of tools for early continuous automation, implementation of 60 percent minimum execution of automated scripts during the integration testing phase, catalog-based self-service infrastructure, implementing features faster with prioritization and planning (there’s always a next bus principle), one-touch deployment, faster provisioning of infrastructure, and one build-up-to-production approach.

Releases that used to take eight or ten weeks, depending on the release sizes, are now taking place in six to eight weeks with all the teams working together. The entire team feels more confident. There is certainty of better quality with no issues entering into production, thus helping the customer to go to the market faster as well as first-time right.

Josiah Renaudin: You mentioned the certainty of better quality. Why is getting an application or product right in the first instance so critical in today's business environment? It's not like the bugs don't get fixed eventually, so since a patch or fix always comes along, why do we need to nip these problems in the bud beforehand and make sure the application, whether mobile or web, is right before its release?

Shankar Konda: In the current market that we are living in, customer experience is key. Businesses have to ensure the quality is up to par with what the customer is expecting and that the customer experience is superior, to say the least. Every product or release or solution that the business puts out there has a customer interface—whether it's through a mobile or any digital interface. Hence, it is crucial to achieve first-time-right as the customer forms an opinion on a particular app as soon as he or she opens it.

Customer loyalty resulting out of his or her experience, once lost, is difficult if not impossible to regain. Hence, businesses cannot afford to ship something that is incomplete; they have to get it first-time right. Also, here we are talking about market leaders, and market leaders are leaders for a reason; they cannot afford to let their status or brand take a hit. This is especially true in the banking industry, where technological innovation and offering superior customer experience is the norm of the day, every day.

So that's a pretty good reason why assuring first-time right is so important for businesses, and this is also why shift-left is helping to put better quality at the forefront as a part of the everyday activities, as a part of how everybody should look at quality as everybody's job. That's the reason why this and other aspects of shift-left are helping the businesses deliver first-time right, every time.

Josiah Renaudin: I like the way you put that—it's making quality everyone's job, which is very important. Now, let’s talk about the current trend of DevOps and continuous integration, or continuous delivery. How do these complement the shift left world? Most people might see them as mutually exclusive, but what's your point of view?

Shankar Konda: They all complement each other to achieve a common objective. And I will explain to you why I say this. Digital Reimagination™ is compelling most organizations to undergo transformation. In this transformation, there are obviously various aspects of the overall software lifecycle that need to fall into place—whether it be a test advancement, test environment, or how the operations look into the application expectations or requirements. So the business assurance is what I'm talking about here, and DevOps, agile, and continuous integration are all means to achieve the transformation goals.

Businesses today need to focus on collaborating on the development activity and the operational pieces toward that business assurance. Continuous integration helps development teams work in an agile model and complete the development milestones while release automation and continuous deployment help getting the releases delivered in an agile model as well.

To achieve this goal, there is some initial seeding that needs to take place in an organization, and shift-left is one of those. Automation which used to happen at the end of the testing lifecycle is now a thing of the past. Now we are talking about how progressive automation, or holistic automation across the lifecycle, can enable the development teams to accelerate the process to integrate and release teams to accelerate the process to deploy the code on a continuous delivery model.

All of these aspects are getting integrated as a part of the continuous integration, so that more scope and more enhancements can get delivered, more functionality gets delivered, at a faster pace. And once this happens, the next step, obviously, is to deploy continuously.

Once that continuous deployment is automated as well, that's when the overall DevOps transformation is moving in the appropriate direction.

So, to summarize: Shift left, DevOps, CI/CD, etc., are all components in the software lifecycle that can assist or facilitate businesses in their digital transformation journey.

To take an example, for one of our banking customers, TCS implemented shift-left combined with automation and continuous integration tools and techniques. The primary objective, or a starting point, to guide their CI/CD implementation was improvement in the business customer experience. Some of the outcomes were release frequency was done every two weeks for both legacy and digital portfolios, continuous integration in agile and continuous delivery in waterfall, regression automation increased to 80 percent, and testing costs reduced by over 10 percent.

In TCS, we have built accelerators and tools like ITS (Intelligent Testing Systems), with all the tools and testing process steps integrated and automated, and TCS NETRA (Non-Production Environment Tracking and Release Automation), which is a web-based, end-to-end delivery automation platform to offer a complete continuous delivery solution along with environment tracking and management.

Josiah Renaudin: Absolutely. Can you also share your views on agile in testing? Are there any recommendations you could suggest for organizations adopting agile for the first time?

Shankar Konda: At TCS, we recommend organizations embarking on an agile journey should ensure minimal viable functional enhancement for development approach and also real-time collaboration of teams for truly seeing the results of the agile approach. This can be achieved once product owners are well versed with creating good user stories. Organizations should also automate a continuous integration pipeline with standardized tools and environment so that the code is always in a deployable state. They should explore a test-driven development approach by integrating QA with the agile teams with early creation and execution of automation test scripts. And finally, both the legacy and digital applications should be in sync to increase the frequency of releases with reduced release scope.

Josiah Renaudin: Right, that's a great explanation. And I do have one more point to bring up to you, Shankar, and I very much appreciate your time. This is a very long-reaching question. Testing has moved from being an after-the-fact activity to a proactive quality function, from a cost-center activity to a value-center one, from right at the end to shift left, and now continuous. So, what is the future outlook? Will it change, or continue on this path?

Shankar Konda: That's a great question, so let me just explain this. As I mentioned earlier, gone are those days where the traditional model of testing was as a gatekeeper. In the good old days, you are trying to find a defect, and once you find a defect, you're expecting to get it repaired, and then you try to retest that repair and to see if the defect doesn't exist anymore—so traditionally, it was more of a quality control function.

I think the market is not accepting that kind of methodology anymore. In the modern era, what is happening now is testing is not just testing anymore—it is more quality engineering now. It is more how quality can be engineered into the practices of the development lifecycle itself. In fact, for a couple of our customer engagements, TCS has redefined the roles of the quality assurance and testing professionals. They are now being referred to as “quality engineers” instead of quality analysts. They're not any longer just testers because of the fact that they need to enable the other aspects of lifecycle development and become that part of the development team. They are not just part of the testing team anymore; they are part of the development team, working as quality engineers.

Now, that's a big shift that's happening, and many organizations are slowly realizing that, or they are very close to implementing that in the future.

The second aspect is, as I mentioned earlier in the DevOps overall goals, businesses are trying to move towards expecting the quality team to perform an anchor role in getting things done. They don't want them to be over the fence and telling other people that something is wrong. They want something to be anchored and help facilitate between the teams and get things done without raising a red flag, so the anchor role is now between the development teams, the business, and the operations. The operations were never in the picture in the past. QA and testing gets a comprehensive picture of how things need to be and how things can be handled as the development is taking place.

That is, an incremental solution development is being done, so that when things go wrong, they can be edited in a timely manner, or immediately. Things are not even going or flowing into the downstream activities of the software development lifecycle, and that is the kind of paradigm shift that's going to happen in the near future.

Josiah Renaudin: Absolutely. It will be interesting to see that shift happen.

Well, thank you very much for speaking with us today. That was a very interesting discussion on shift left and first-time right with a focus on achieving superior customer experience. We look forward to talking to you again on more topics in the future.

Shankar Konda: Absolutely, thanks so much for your time today to discuss a topic that is very near and dear to me. To know more, you can connect with me at [email protected] or [email protected]. Let’s continue to think assurance!

With more than twenty-five years of experience, Shankar is a passionate QA practitioner and has been working with global organizations to setup and streamline their QA process and practices. He has extensive experience in leading large engagements in a global delivery model and program management, and has successfully led end-to-end QA transformation programs for customers. In his current role, Shankar leads the Banking and Financial Services (BFS) vertical in North America for the Assurance Services Unit of TCS. He is a thought leader and helps BFS organizations in assuring their DevOps and agile implementation journey