Mythbusters: Shift Left Edition for Software Testing
By Akshita Puram, Product Marketing Manager, SmartBear
Today, the software industry is seeing history repeat itself. In the 1950's, programmers knew that it was better to start testing earlier in the software development lifecycle (SDLC). There was not a dedicated QA team that developers would hand off an application to and hence, testing an application’s functionality happened by the same people who wrote the code and occurred throughout the length of a project. It was an unfortunate misunderstanding of the waterfall model that led to independent test teams and the time lag between development and testing that we have today. Even though testing software earlier in the development cycle is not new, modern approaches such as agile, continuous testing, and shifting left have reintroduced an important way of working.
Shifting left has become one of the key principles in a DevOps practice where quality is considered and testing is performed earlier in the software development lifecycle. By fostering better collaboration between development and testing and by making the process more iterative and fluid, shifting left can significantly decrease the impact associated to downstream defects. The huge cost savings alone should be enough to convince senior leaders to adopt a shift left approach, yet, a few misconceptions have hindered its widespread adoption.
MYTH 1: Shifting left makes QA teams obsolete
There are two schools of thought around shifting left that either entails shifting testing activities to developers or during development. The distinction seems minuscule, but one implies a change to peoples’ primary roles and responsibilities, while the other is a change in process.
Many software teams today run in silos, handing off developed applications to QA teams to test and identify defects. By shifting testing activities to the left, there is a misconception that this work now needs to be completed by developers. However, the purpose of shifting test left is not to combine the responsibilities of a developer and QA engineer, but to increase collaboration between the two disciplines and increase awareness of quality across all software teams.
Testers should be engaged with designers, developers, and operations teams to build a resilient, scalable system. QA teams should work with teams to ensure user and system requirements and code are all built in a test-ready format.
MYTH 2: Shifting testing to the left is not an agile approach
There are many approaches to testing in agile including methodologies such as SAFe for enterprise-wide implementation. Shifting testing activities earlier in the development cycle is also considered an agile approach to testing.  However, like any fast, changing process in the workplace, shifting left can feel like turning the Titanic. Once in the right direction, the ship’s crew can navigate swiftly.
By framing shifting left as an agile approach, development teams will change how they think about their organizational structure. Software teams are encouraged to have a stake in achieving quality at speed regardless of departmental boundaries. Developers will be encouraged to think about how they develop their code so that it is easier for the tester or automation engineer to create test scripts. QA testers will work closely with developers, identifying design and building issues before the testing phase directly in development environments (IDEs). Teams will be able to not only code in sprints, but also test in the same sprint too, releasing quality software at a faster pace. Once there is a collaborative understanding of a common objective, requirements and solutions will naturally evolve from different stakeholders to create alignment and foster a test-ready mindset.
MYTH 3: There is no proven ROI behind shifting testing earlier
When we think about our personal health, we often forget to eat well and live healthy as a means to protect our immune systems from falling sick. Similar to our own health, prevention in an application is better than the cost and effort to fix defects further down the software development cycle.
IBM System Sciences Institute identified that the cost of fixing a defect is six times more costly if found in the implementation versus design phase and more than 15 times more costly if found post-deployment versus the implementation phase. The cost savings experienced by disseminating testing across development will serve as a strong impetus to create executive buy-in to endorse a shift left approach.
Alongside the quantitative value teams will realize from transitioning to a shift left approach, there are numerous qualitative benefits. For example, over the course of the first few years, a team’s testing process and quality results will mature and maximize an application’s test coverage. Teams will be able to execute tests across environments faster and reduce the risks and costs associated with redundancy and defect leakage downstream. As the number of devices and technological platforms available to end users continues to grow, this will become essential to success. With a solidified test process in place, software teams can spend more time focusing on building new features to enhance product quality – ultimately realizing the full value from shifting left.
MYTH 4: There are no tools to help with shifting left
Digital transformation has consistently demanded changes to an organization’s fundamental way of working, driving modern methodologies to software development such as agile, DevOps, and continuous testing to gain mainstream support. Shifting left is an important approach to software development that equally requires changes to an organizations’ people, process, and toolchain. A common misconception about shifting left is that it only requires a change for people and processes.
Test automation tools that support behavior-driven development (BDD) and optical character recognition help accelerate shifting left. BDD is a software development process where teams create simple steps on how an application should behave from a user’s perspective. The steps that are created at the start of a development lifecycle are used by entire product teams to design, build, and test an application with the end in mind, a shift left approach.
With native BDD support in test automation tools, software teams can embrace an end-to-end BDD workflow. With test management, software teams can collaborate on building feature stories and easily formulate stories with an easy-to-use editor that converts action words to scenarios and provides step auto-suggestions. With test automation, teams can then accelerate BDD workflows by converting feature file definitions from user requirements into automated tests instantly.
Optical character recognition (OCR) is the process of translating images of text into computer readable text. Test automation tools with OCR capabilities can easily create test cases based on UX wireframes and mock-up designs. By automating test creation in the design phase, software teams can embrace shifting left to the very beginning of the development lifecycle. Marrying changes to an organization’s workforce and process with appropriate tools will drive adoption toward a shift left mindset and workflow.
FACT: Shift left is transforming the entire SDLC
Shifting left does not only refer to moving testing activities early, but also many supporting tasks along the software development lifecycle. With the demand for frequent, bug-free deployments, software teams look to agile methodologies to employ small, iterative changes to an application that result in faster feedback and less time spent in the requirements phase. Instead of relying on a single release, an agile team delivers value in consumable increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly, increasing the impetus for a shift left approach across the entire development lifecycle.
From design to deployment, a continuous software development strategy is essential to supporting an agile, shift left approach. By peer reviewing code and running test automation and performance monitors throughout an application’s development, software teams can reap the benefits of shifting left with continuous feedback regardless of development phase. To be successful, teams need to operate in small, collaborative units, where developers, business analysts, and testers work together in a more iterative process that leads to shorter delivery cycles and faster feedback.
See More Mythbusters by SmartBear
Mythbusters: Functional Testing Edition
Mythbusters: Mobile Testing Edition