In today’s world of lightning-fast deliveries, where you expect your package almost before you finish your coffee, the spotlight is on quality. We’re talking about making sure everything—whether it’s easy to use (Usability), works like a charm (Performance), and keeps your data safe (Security)—is up to snuff. But how do we guarantee that the software systems driving the supply chain deliver on these quality promises across the board? Our choices in quality engineering processes have a profound impact on business operations and customer satisfaction. We know that the software development and testing have been tightly integrated. In the end-to-end process, starting from discovery and going all the way to delivery, testing often occupies the space between development and deployment in the traditional waterfall model. However, in recent years, the terms “Shift Left” and “Shift Right” have gained popularity, promising effective solutions to quality issues.
As we embark on this quality journey, the pivotal question arises: Do we elegantly “Shift Left,” strategically “Shift Right,” or maintain the status quo with a “Stay Put”?
Join us as we go through the realm of quality engineering in the supply chain, enriched with real stories. We’ll explore various scenarios and help you determine the right approach in different situations.
Shift Left Approach: The Front-Loaded Quality Path
The Shift Left approach, as shown in the picture above, starts testing right from the inception, without waiting until the development is complete. To put it simply, it’s like double-checking the recipe and ingredients before you start baking a cake. The quality becomes a shared responsibility affair where everyone must be on the same page from the word go.
- The Management Team: Facilitates the QA team to get involved at all the needed discussions, right from the beginning.
- The Development Team: Facilitates the QA team to get involved at all the needed discussions, right from the beginning.
- The QE Team: Plays the devil’s advocate, meticulously examining each requirement to ensure thorough consideration. Documents and outlines assumptions, open points, and clarifications with precision. Steps beyond their comfort zone to craft code for testing, validating Junit(s), and ensuring proper unit test coverage. Demonstrates technical breadth, actively contributing to design discussions.
A Case in Point:
A telecom company had implemented an order management solution and wanted to roll out a new feature where the customer could place an order by adding different items to his cart and make the payment using multiple modes as described below.
Approach:
Shift Left approach was used to handle the business and the technical aspects for this use case. By shifting left, the testing team was involved in the requirement & design discussions, thereby scrutinizing the customer and functional requirements as early as possible. The key customer requirements were well defined & prioritized before actual software development, thereby tackling the business aspect. The quality engineering process for the project was well laid out where the developers were responsible for code quality & the unit tests and the testers were responsible for gatekeeping at each level in terms of processes and validations.
Shifting left in technology meant the functional & non-functional requirements needed to be addressed and planned right from the beginning. An exhaustive test strategy addressing Performance/Security/Usability requirements in terms of scope, timelines, skills, milestones, the risks & the mitigation steps was laid out well before the implementation was ready to be tested.
Key Considerations:
Navigating the intricacies of testing a complex telecom order posed a myriad of challenges in both functional and non-functional testing domains. The test scenarios demanded a diverse scope, spanning numerous items, composite products, and varying payment modes. Thorough integration testing became imperative, encompassing the intricate validation of social, data, and voice plans within the bundle. Acquiring a new cell phone from the vendor and facilitating the trade-in of old mobile devices required meticulous integration testing, involving vendor interactions for trade-in value, pickup, and checks. Addressing user-specific preferences and dynamic content generated by Value-Added Services (VAS) became crucial, alongside ensuring secure integrations with diverse payment methods. System performance considerations, especially regarding dynamic roaming functionality and high transaction values, had to be envisaged right from the project’s inception. Telecom regulation compliance stood as a top priority, necessitating adherence to evolving standards and legal requirements. The rationale for adopting a Shift Left strategy became evident in this dynamic telecom environment, offering a more predictive landing and preventing critical oversights that might have occurred if left to the last minute (Shift Right). Staying somewhere in the middle (Stay Put) was deemed suboptimal, considering the significant effort already invested by the time critical issues might surface. In essence, for the successful testing of critical telecom use cases, the Shift Left approach proved instrumental in proactively tackling the challenges posed by evolving technologies and dynamic customer needs.
Benefits Leveraged:
- Reduced risks of costly defects in the later stages.
- Enhanced understanding of the project’s complexity in the team.
- Saved time & resources in the long run by minimizing the rework effort.
- Better collaboration between Dev & QA
- Embracing Shift Left allowed for more adaptability to changes, turning the ship smoothly without causing a storm.
- Identifying and mitigating risks in the early stages helped with the smooth sailing, thereby avoiding treacherous waters later.
In the realm of supply chain quality, ‘Shift Left’ approach has emerged as a proactive and collaborative strategy, injecting quality considerations from the project’s inception. As we witnessed in our telecom order management use case, involving the testing team in early requirement and design discussions not only mitigates risks but also fosters a shared responsibility for quality across different teams.
In the next edition, we are exploring the twists of “Shift Right” and when it makes sense to do the “Stay Put” shuffle.
Author: Sheetal Raina
Subscribe to our blog and stay updated!
Share This Story, Choose Your Platform!
