Moving forward: Agile Testing

Agile methodology is rapidly adopted by many project teams. Traditional methods of software development such as Waterfall, Spiral model, V-Model are becoming more and more outdated. First introduced by Dr. Winston W. Royce in a paper published in 1970, the waterfall model is a software development process. This model emphasizes that a logical progression of steps be taken throughout the software development life cycle (SDLC), much like the cascading steps down an incremental waterfall. Software developers and software testers are positioned as separate entities at different points along a production cycle. Waterfall is a respected methodology, but it’s faced criticism: efficient production is severely hampered if developers are striving to refine their code to a state of perfection before passing it on to a separate testing team, who then strive to break it in as many ways as they can before sending their damage report back to the development team. This two-step process requires time, money, and frequently leads to internal division between a given company’s developers and testers.

This is one of the fundamental problems that agile seeks to resolve.

The essence of agile (development) is that it puts an emphasis on being adaptive to customer and business needs rather than following a rigidly-defined plan with an emphasis on managing costs and schedules of delivering the solution. When properly done, Agile will to deliver quality software amidst frequent releases of newer functionalities. Successful Agile teams focus on testing up front: while they continuously develop, continuously integrate, continuously deliver and also continuously test. Developers and testers are seen as two sides of the same production coin: efficient production is severely hampered if your developers are striving to refine their code to a state of perfection before passing it on to a separate testing team, who then strive to break it in as many ways as they can before sending their damage report back to the development team. This two-step process requires time, money, and frequently leads to internal division between a given company’s developers and testers. Agile suggests that these two essential functions be merged—not necessarily in terms of people, but in terms of time and process—thus bridging the illusory divide between code creators and code breakers, and even reducing the need for robust testing teams, while still respecting the necessity of both roles.

Two Challenges: requirements and change

In Agile the lack of well represented, detailed requirements, short iteration with quick delivery bring light to significant questions to the traditional view of testing. For example: how can end-to-end testing be carried out when the complete application is not available? What level of documentation is sufficient? The Agile Manifesto prefers “Working software over comprehensive documentation.” Agile seeks to minimize waste, so taken to its logical extreme, all documentation is waste. That doesn’t mean documentation can (or should) be done away with entirely; it’s necessary for teams to function (particularly at scale). Agile methods allow for high-level requirements gathering, but suggest that we should stay away from details (prescriptive) requirements because those tend to evolve throughout the project. Agile methods emphasize focus on ―user stories, instead of detailed system requirements. The high-level requirements are helpful in defining the scope of the project and create tentative iteration plans. For testing: if requirements are very high level and (or) are likely to be changed, then writing test cases is going to be pointless as they probably have to be rewritten completely within a few builds. Suggested approach would be using a (the) “Agile Testing Checklist” or combine “Exploratory Testing” with (a list of) compatibility requirements.

Much of the promised velocity of agile development is let down by incremental code changes, specifically their impact on testing and overall system stability. Each sprint typically concludes with concludes with a version of the software that can be shipped to customers. Before this shipment, QA and test will focus on validating the new functionality implemented. Sometimes organizations need to do a full regression as the release approaches. This often uncovers numerous issues late in the cycle, resulting in late hours and difficult business decisions. Even minor changes can impact application stability and ultimately break the system. These unintended consequences are impossible to discover through manual inspection, so testing is critical to mitigate the risk they represent, but unless there is a clear understanding in what needs to be re-rested, no efficient testing practice n be established. Too much testing in each sprint means loosing many of the gains made by Agile development. Testing too little, will expose the team to late-cycle detection. How to identify which tests need to be re-executed and how to balance testing efforts (unit testing, automated functional testing, and manual testing) on validating the features and related code that are impacted by the most recent changes? Using a combination of code analysis engines and intelligent analytics, developers and testers can understand the changes in the code base between builds, and get to the promise of Agile. This is called Change-based testing. The key is knowing which tests are available to validate the code changes. By understanding which files have changed and which specific tests touched those files, Change-Based Testing can analyze the delta between two builds and identify the subset of tests that need to be re-executed.

Until the next great innovation in software process comes along, the future is clearly Agile

Back in the days the waterfall process seemed not only appropriate but also effective. Today, we live in a world where digital downloads dominate sales and where continuous deployment is becoming the norm. The speed of software sales is only increasing (and increasing exponentially at that), and judging by reviews in the app stores, customers’ patience for software glitches seems to be decreasing conversely. For companies to remain competitive, running tests with the right tools as fast as developers can modify code, they have to realize that the future of software development is no longer linear—and perhaps never should have been.

Share this:

Related