Category: Agile Testing

Organizations now expect software development teams to deliver more, and more innovative, software within shorter delivery cycles. To meet these demands, teams have turned to lean approaches, such as Agile, DevOps, and Continuous Delivery, to try to speed up the systems development life cycle (SDLC). After accelerating other aspects of the delivery pipeline, teams typically find that their testing process is preventing them from achieving the expected benefits of their SDLC acceleration initiative. Testing and the overall quality process remain problematic for several key reasons:

[[Also Read: Understanding the Continuous Testing in DevOps]]

• Traditional testing processes are too slow. Iteration length has changed from months to weeks or days with the rising popularity of Agile, DevOps, and Continuous Delivery. Traditional methods of testing, which rely heavily on manual testing and automated GUI tests that require frequent updating, cannot keep pace. At this point, organizations tend to recognize the need to extend their test automation efforts.

• Even after more automation is added to the existing test process, managers still lack adequate insight into the level of risk associated with an application at any given point in time. Understanding these risks is critical for making the rapid go/no go decisions involved in Continuous Delivery processes. If tests are developed without an understanding of what the business considers to be an acceptable level of risk, it is possible to have a release candidate that passes all the available tests, but which the business leaders would not consider to be ready for release. For the test results to accurately indicate whether each release candidate meets business expectations, the approach to designing tests must be based on the business’s tolerance for risks related to security, performance, reliability, and compliance. In addition to having unit tests that check code at a very granular bottom-up level, there is a need for a broader suite of tests to provide a top-down assessment of the release candidate’s business risk.

• Even if testing is automated and tests effectively measure the level of business risk, teams without a coordinated end-to-end quality process tend to have trouble satisfying the business expectations within today’s compressed delivery cycles. Trying to remove risks at the end of each iteration has been shown to be significantly slower and more resource-intensive than building quality into the product through defect prevention strategies such as development testing.

• Organizations adopt Continuous Testing because they recognize that these problems are preventing them from delivering quality software at the desired speed. They recognize the growing importance of software as well as the rising cost of software failure, and they are no longer willing to make a tradeoff between time, scope, and quality.

Continuous testing has evolved to become an important phase in modern application development and delivery. Its very important for today’s testers to understand the Shift Left and Continuous Testing practices. It is not possible achieve Shift Left / Continuous Testing without enhancing the skill set to SDET/Full Stack QE

Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests. Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

[[Also Read: Challenges with Traditional Testing and the adoption of Continuous Testing]]

Following Key Points will help in understanding the Continuous Testing:

• Continuous Testing’s primary goal is assessing business risk coverage
• Continuous Testing provides instant insight on whether a release candidate is too risky to proceed through the delivery pipeline
• Continuous Testing establishes a safety net that helps the team protect the user experience in accelerated development processes and avoid software failure headlines
• Continuous Testing expects testing to be embedded within the development process, not tacked on at the end
• Continuous Testing is seamlessly integrated into the software delivery pipeline and DevOps toolchain
• Continuous Testing expects a stable test environment with valid test data to be available for each and every test run
• Continuous Testing embraces everything from “shift left” (unit, component, coverage…) to “shift right” (monitoring/ APM, Testing in Production)
• Continuous Testing involves executing the right set of tests at the right stage of the delivery pipeline—without creating a bottleneck
• Continuous Testing delivers actionable feedback appropriate for each stage of the delivery pipeline
• Continuous Testing evaluates each layer of a modern architecture at the appropriate stage of the delivery pipeline
• Continuous Testing includes end-to-end tests that realistically assess the end-user experience across all associated technologies (front-end and back-end)
• Continuous Testing’s tests must be broad enough to detect when an application change inadvertently impacts functionality that users have come to rely on
• Continuous Testing reduces false positives by prioritizing robust, flexible modern test frameworks over brittle scripts
• Continuous Testing involves continuously reviewing and optimizing the test suite to eliminate redundancy and maximize business risk coverage

source