What's in the Way of In-Sprint Testing?
Every project, software-related or otherwise, quickly faces that point of impact between what should happen according to plan, and what happens in reality. In agile development, the Scrum and sprint sequence play host to these impact zones more often than not. Testing and reviewing of each functional part of the product easily lead to bottlenecks and frustration, and time is never in adequate supply. The result? In-Sprint Testing rarely happens, if at all.
It is a huge challenge to ensure that sufficient rigorous testing fits into each sprint along the timeline ? the tenet of In-Sprint Testing. In many cases, this must be done while dealing with problems such as unclear requirements, ineffective test case design, and delays in obtaining data. Often there is also a time-consuming manual testing process in which teams are forced to work in sequence.
Is This What Agile Was Supposed to Be?
It appears that the testing process has suffered in the rush to deploy an agile approach to development. This has left testers struggling to test in the middle of changes to code or scope. They work in crisis mode, never having enough time to adequately perform all the necessary tests (functional, integration, regression, usability, security), find and fix defects, and communicate with experts. The sprints never seem to be long enough to get it all done. Lagging behind each sprint, they fail to achieve in-sprint testing time and again.
It appears to be a typical critical path scenario, but at least one expert suggests the challenges of agile testing might not be caused by the sprint length after all.
Katy Sherman, writing in testingexcellence.com, points out that testing often gets split into two parts: first there are tests that are "directly related to the user stories developed in-sprint," and next, there is "everything else." She points out that the "everything else" components invariably get pushed to the end of the release ? the hardening sprint ? which will "increase the risk, compromise quality and [not] use the main advantage of agile - the ability to deliver value to the customers often in small increments."
This final phase, the hardening sprint, should be eliminated, she says, with testing happening on a more even basis "in-sprint" in the project, and each "ending with a set of fully tested features that could potentially be deployed to production or shipped to the customer. There would be no need for the context switch at the end of the release, no last-minute defects and costly delays."
Eliminating the bottleneck of the hardening sprint may appear easier said than done, but the solution is simpler when divided into its parts: Intellectual (clearer project planning), logistic (more testing more frequently and in parallel), and human (greater collaboration and communication).
Minimum WIP
Project planning is about defining milestones all along the timeline, and so must it be within agile production. For example, each sprint should include a minimum Work-In-Progress (WIP) to define the required minimum for fully testing completed work, and to ensure the item is completely finished before moving on to the next.
This is a team effort that includes the use of automated regression tests ? not something that should be placed on the backs of individual testers.
The Human Factor Continues to Emerge
A browse through online testers' forums highlight an ongoing need for feedback and communication all along the agile process. Feedback means reviewing iterative pieces of the software in production, comparing against the project objectives, identifying and communicating problems and defects, and seeking out SME knowledge as needed.
Agile demands a strong culture of interpersonal collaboration that complements the mechanical rigors of testing and time. Human skills, such as communication, leadership, and shared vision can be instrumental in shifting a culture from isolationist and competitive to cooperative and fully productive.
Controlling the Regression Test Sets
A large challenge to in-sprint testing comes from improperly planned regression tests sets. As Clemens Reijnen writes in methodsandtools.com, "...some teams rerun every test every sprint [which] is time consuming and isn't worth the effort. Having a clear understanding of what tests to execute during regression testing raises the return of investment of the testing effort and gives more time to specify and execute test cases for the functionalities implemented during the current sprint."
Regression testing has its value in an incremental knowledge base that builds from each test, making it a highly valuable method of maximizing testing efficacy.
But again, these take skills and time.
How to Overcome These Challenges? Automate the Testing
This is where test automation comes in. It's what we call " Testing at the Speed of Agile." The solution to the challenges of in-sprint testing comes from using a new generation of test automation software that maximizes one's ability to do testing within the sprint. Consequently, rather than having test engineers lurching between always waiting for something or lagging behind, automation shortens the test while improving overall quality.
This is an age where working with manual procedures like spreadsheets, and deploying excessive numbers of test cases simply have no place. The difficulty of fitting "testing" inside sprints cannot be blamed exclusively on any single source. However, a beefed-up standard of human communication and project management, paired with a revitalized automated testing procedure will set the stage for a far more competitive and productive agile platform going forward.
CA offers comprehensive solutions that automates the most difficult testing activities ? from requirements engineering through test design automation and optimization. Start your Free Trial of CA Agile Requirements Designer today and fast track your testing at the speed of agile.
