It is quite common to notice words like ‘upstream’ and ‘downstream’ in many business strategy models that outline value-chain fundamentals. Incidentally, or not so, the same undercurrents are now being felt in the world of software too. They have been christened something new though — Shift-Left and Shift-Right. So, what prompted testers or software-makers to let go of the other buttons and press the ‘Shift’ key in such a fresh way?
The Importance of Shift-Left and Shift-Right Testing Approaches
Shift-left and -Right are two new orientations that are redefining how testing, development, defect-corrections and user requirements happen in the modern world. With the advent of new species and implications of software; testing, understandably, is embracing a new flexibility and direction.
The Left side is about testing that is performed earlier on in a lifecycle. It happens by moving the process ‘left’ on a project timeline and follows the tenet of testing early and often. With the growing impact of Continuous integration, features can be tested before being conclusively defined and it is done to deliver quality software with an eye on better speed factors. That’s the ‘Shift-Left’ approach.
As to Shift-Right testing, here, the testing horizon is stretched towards end-user feedback in a brave and unprecedented manner. Testing is pushed towards production stages and characteristics like performance-in-real-context, functionality, failure tolerance and fine-prints of actual user experience are addressed. This is done with an eye on usage scenarios that can often go unnoticed or not-received by either side — testers and users. As can be surmised by now, it takes a certain degree of risk into production deployment; but when done right, it can translate real user needs into a competitive advantage against other rivals.
We can see that the first approach is heavy on ‘getting the code right the first time’, and the second one underpins ‘absolutely user-right code’. The first one ensures considerable savings in time, testing effort, risk and resources. The second one is more concerned about nailing the user and production scenarios no matter how costly or risk-dominant this may get.
Essential parameters one should consider
One should reckon that Agile and DevOps Best-Practices get predominant in case of a Shift-Left approach, and testing engagement is endeavoured at quite an early stage. This may also string in an automation-first mindset, high levels of collaboration, continuous builds, persistent deployment of code; as testing turns more rigorous and entails both regression and functional testing along with stabilisation-checks for various patch updates.
When we assess the salient aspects of the Shift-Right approach, we observe that owing to high stakes and risk elements, Performance testing, as well as practices like Dark Launches, Business Toggles and Canary deployments, find a ready scope and preference here. So do virtual users and proactive feedback from globally-spread users.
The thrust is on real-world results and problems that cannot be anticipated with a left-leaning mindset. The assumption is that no matter how well one intends and tries; simulating a test lab quite near to production environment and real-load levels is just not plausible or possible. Teams and enterprises, especially those furnished with the kind of risk-tolerance warranted here and a sharp hold on the change set in each deployment, find this approach both apt and advantageous.
Best Practices
1. Planning the entire testing lifestyle beforehand
As we noted in the sections above, every approach has its advantages, needs and challenges. Neither of the two ways can be adopted randomly. No matter what method and level of risk one picks, it should be integrated and prepared-for well in advance. Functions and features that work well with a test-early mode cannot be squeezed in a ‘test-on-the-D-day’ context. So it is advisable to have a comprehensive and pragmatic view of one’s expectations, limitations and strategy.
2. Integrating project management process with testing
Studies have often attributed poor tests and sloppy software to a number of reasons that flock at the very stage of picking a testing approach. It doesn’t help when the number of test professionals involved is inadequate at crucial stages like idea-phase, project-initiation phase. Hence, testing and QA is not sufficiently embedded into the development process. A project management lens and the dashboard are crucial to making sure that testing does not jump in when gaps with development are too large to fix or when development is too busy or far-fetched to let QA and testing teams add any value. Smooth and symbiotic integration of testing and coding teams makes the difference between a cobbled product and a fluid software.
3. Specifying quality standards
The levels of quality, features and performance would have various underlying differences in each approach to testing that one undertakes. Having a clear view of quality and non-negotiable areas will help testers apply the right spin, key and rigour to the code — whether it is done early or later.
4. Planning departmental deployments
Barriers and unanticipated issues that debilitate the entire delivery pipeline, often get addressed by how testing is planned and how well silos within the development exercise are wiped away. This helps in weeding out delays, availability issues of dependent-code as well as test environments, services-resources needed at crucial stages; and conflicts between teams that gnaw away efficiency and effectiveness to everyone’s detriment.
5. Induce developers to code with testability in mind
When developers also get a well-drilled and well-explained sense of the ‘Left’ or ‘right’ direction, it becomes very easy and brisk to tap advantages like the improved design, reduced-bottlenecks, identification of bugs, amplified-efficiency and an overall software experience that delivers what was desired. Coding would need to adapt to a production-inclination or a pre-code-testing appetite depending on the kind of testing direction being taken, and this inherent readiness would help both testers and coders. And of course, ultimately the users.
6. Setting up a continuous feedback mechanism
It always helps to have feedback planted and leveraged across the application lifecycle, so the test engineer’s purview is strengthened; and despite unexpected downtime or failure or server issues, gaps can be addressed at the best ability of the tester. In both cases — Shift-Left and Shift-Right testing — this level of feedback-availability is instrumental in giving the tester a better perspective on user needs and application’s weaknesses.
7. Engaging in coding
Gone are the days when testing and coding were buckets that never mixed. Today, it is not only helpful but also necessary for testers to gather enough proficiency in reading and modifying code or in performing quality checks or reviews. Development of reusable and maintainable code comes handy here. Similarly, coders can always gain from some level of distributed testing so that delays on automation frameworks can be avoided and more time is liberated for testers to focus on bugs; and at the same time, the essentials of customer-driven development or BDD (Behavior Driven Development) can be suitably delivered.
This equips either side with useful domain knowledge and skills that can prove very useful in certain stages. It also empowers the entire team with better test coverage, a more-accurate grip on user expectations of features along with a holistic understanding of the application and the system adopted.
8. Regular audits
Every approach needs a proper and well-designed audit that marries the rigour of test efficiency with the impact of test effectiveness. Metrics can vary, but a relevant and prudent coverage of some areas is always worth it. Like the number of tests, a number of problems, test execution effort, delays from dependent systems, test environment provisioning, the accuracy of test environments, accuracy, reliability, outages, proper conduct of load-performance-and-stress testing and presence of high-risk integration points.
Conclusion
It is quite fascinating to see Forrester’s estimates of enterprise spending on software testing services. This is an area slated to grow 2.5% annually and could reach $21.5 billion by 2019 (with 2017-to-2019 overall growth approximating 7.7%). Now with new potential and possibilities that ‘left’ and ‘right’ directions are proffering, enterprises would have a great time picking what direction their testing strategies and wallets are going to move towards. Both approaches come with their unique contexts and benefits. Going Left can chop time needed for testing during the development of software, and this can be quite apt when each build of the application is deployed into an environment and tested. When the element of risk is less or relevant or easy-to-wield or worth-the- wield; then going Right is a good choice, culminating in a better user experience. This is also helpful when one is able or interested in capturing user- feedback and when a controlled audience set is the case. This is more so when the consequences of a defect creeping into production and its level of exposure are not huge. Having a Left key on your side will, anyways, allow you to get the remedies deployed much faster.
It all depends on your inclination and your scale of DevOps. Do you want to fail small and fast? Can you afford a failure that pops into production? Can you have small changes deployed and released incrementally? Can you monitor the application with a close eye?
Can you react swiftly enough to failures?
Above all — how you define ‘release of software’? Is the application cycle a box to be opened and sealed or is it a stream — it all boils down to the perspective one starts with.
