Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
X
Want to see Parasoft in action? Sign up for our Monthly Demos! See Demos & Events >>
Reading Time: 5 minutesShift-left testing achieves risk reduction in the following key areas, that I’ll explain in more detail below:
The movement to “shift-left” is about moving critical testing practices to earlier in the development lifecycle. This term is found especially in Agile, Continuous, and DevOps initiatives. So why do you need to perform early software testing?
Many testing activities occur late in the cycle, where it takes longer to figure out what went wrong and costs more to fix. Shifting left is about shifting the identification, and prevention, of defects to earlier. When you don’t, and wait to perform testing practices later in the development cycle, your non-functional business requirements in particular (i.e. security and performance testing) are so fundamentally ingrained in your code that all you can really do is patch them up rather than fix them properly. So how does moving testing “to the left” help the key areas of software?
Compromised application security results in leakage of information, downtime, defacement, and malware installation. These consequences account for 61.6% of security-related outcomes according to the Web Hacking Incident Database.
The traditional approach to security is to simulate direct attacks by a combination of guesswork and experience. The traditional approach is ineffective and outdated due to its overreliance on luck. With shift-left testing, these security risks can be prevented at development time.
One of the biggest risks an organization faces is lack of information upon which to make decisions. Is development progressing at a rate that will meet the deadline? Is the product on track to meet requirements? Does anything need to be done right now to capitalize on an opportunity or soften the impact of an impending customer problem?
Parasoft’s shift-left testing platform gives organizations unprecedented, unmatched, and complete visibility into the entire development process by tying together the data from every piece of the software development infrastructure and applying contextual intelligence against defined corporate policies to both drive an automated process for prevention and deliver the business intelligence required at the highest levels of management.
Failure to comply with safety-critical, government, or OEM regulations can result in recalls, invalidate a contract, enact penalties, or result in legal action. While the sums vary greatly by industry and project, they are often considerable. Through a combination of static analysis, coverage analysis, process definition, and routine measurement, a shift-left testing approach systemizes compliance into an automated, air-tight process that ensures risk containment.
Software reliability continues to be one of the most visible problems that can easily be addressed with shift-left testing. Symptoms such as crashes, downtime, and missed SLAs can severely affect a company’s position in the marketplace. By combining prevention, detection, and verification into a process of continuous improvement, shift-left testing will ensure reduction or elimination of reliability risks.
Among developers, there is an old joke: “If debugging is the process of removing bugs, then development must be the process of putting them in.” In business terms, every code change is a risk.
Shift-left testing removes the risk of introducing new defects by enforcing coding policies that prevent structural and design problems as developers work. Additionally, a shift-left testing strategy will eliminate the risk of compromising existing functionality by allowing for automated generation, execution, and management of regression tests alongside detailed coverage analysis. Automated peer review assignment provides a final layer of risk mitigation that ensures 100% of code is inspected by an appropriate team expert.
Outsourcing is losing popularity as businesses learn painful lessons about the risks of cheap, inexperienced labor in a high-tech field. Nonetheless, many businesses have active offshore development and test teams and will continue on that path. While strategies vary, successful outsourcers establish multiple risk mitigation gates, both on-site and off, to protect against risk injection. shift-left testing is a natural fit to establish and enforce policies for coding standards, unit test coverage, and peer review at each risk mitigation gate.
For the sake of brevity, the shift left testing approach breaks down into two main activities:
Doing earlier stage development practices, such as static code analysis and unit testing, helps both identify and prevent defects earlier in the process.
It’s important to remember that the goal is not to find bugs, but to reduce the number of bugs (especially those that make it into the release). Ultimately, creating fewer bugs in the first place is far more valuable than finding more bugs — and it’s a lot cheaper. That’s why safety-critical coding standards on an proactive, preventative approach by flagging code that may “work” but still not be safe.
Coding standards are the software equivalent of engineering standards, and they are key to reducing the volume of bugs (in addition to finding bugs earlier), to support and get the most value out of your shift left initiative. Coding standards are the embodiment of software engineering knowledge that help you avoid bad/dangerous/insecure code. To use them, you apply static code analysis.
For software security, this is especially important to successfully harden your software. You want to build security into your code, not test it in. Coding standards let you build a more secure application from the beginning (i.e. secure by design), which is both a good idea and a requirement if you’re subject to regulations like GDPR.
Next, you must take the tests that were created at all stages, including the later stages, of the development process, and execute them continuously moving forward. This is critical for teams that are adopting agile development practices to provide continuous feedback throughout the development process. Unit tests can easily be executed continuously, but shifting left the execution of later-stage functional tests is often difficult due to external system dependencies, and this is where you can leverage service virtualization to enable continuous testing.
Service virtualization enables you to simulate dependent systems which might have limited availability, such as mainframes, access fees, 3rd party services, or perhaps systems that just aren’t ready yet. By simulating them, you can perform functional testing without having the whole system available, and you can shift-left test execution all the way to the development desktop.
In terms of performance testing, service virtualization enables you to test before everything is ready, and without having a complete lab of everything in the system. You can even run all kinds of what-if scenarios, like what if the appserver is fast and the database slow (something difficult to make happen in the real world). Or what if my server starts throwing funny errors like a 500 error — how will that affect system performance?
You can push the system as hard as you like and beyond, and do it as early as possible. (Learn more about how to shift-left your performance testing.)
Similarly, you can start doing your security testing earlier. Decoupling from physical systems allows you to do something even more interesting, which is to make the simulated systems behave in an evil fashion. Now you can REALLY get into security testing… Instead of just poking at your system for tainted data and DDoS, you can have a system flood you with packets, or send malformed data, or any of the many other exploits commonly used by attackers. So not only can you test earlier (left-er), but you can also test much deeper than is possible with a test lab or production system.
Jason Schadewald is a Product Manager at Parasoft.