Testers must take the lead in redefining testing when Agile development processes are introduced to their organisation. Seapine Software’s solutions evangelist, Peter Varhol shows how testers can redefine testing for Agile development.

Enterprise application development teams are increasingly adopting Agile software development techniques. In its January 2010 report, ‘Agile Development: Mainstream Adoption Has Changed Agility’, Forrester Research reports that 35 percent of respondents stated Agile most closely reflects their development process. Agile methodologies enable teams to rapidly and iteratively develop applications with participation from the end user community, resulting in higher quality software delivered more quickly.

When Agile development processes are adopted by an organisation, testers must take the lead in defining just how their roles must change to suit the Agile methodology. By understanding Agile processes and the changing roles of testing, testers can define their role as essential to building quality software. Here’s how testers can redefine testing for Agile development.

Traditional testing and the transition to Agile

Traditional testing practices have taken their lead from the Waterfall model of software development, where requirements gathering, software design, and implementation follow a deliberate and often lengthy path. In these methodologies, testers focus on developing plans and individual tests to validate the software against the requirements. Testers not only look for obvious software bugs, but also for deviations from the business requirements. In this manner, they ensure both a defined level of software quality and a specific fitness for the original purpose.

While developers are translating requirements into specifications, testers are writing test plans and test cases. This documentation can easily run into the hundreds or even thousands of pages. Once the development team starts building the software, testers execute the test plan, running relevant test cases as the features gradually become available. Bugs and deviations from requirements are logged and described, and developers fix bugs as well as write new code.

Agile methodologies work differently because they put a premium on immediate and rapid code development, and less on upfront documentation like test plans. They do this through involvement of one or more product owners from the user community, who work closely with the development team to define and validate the software. These product owners define the functional requirements of the software through less-formal user stories, which are high-level scenarios of how the prospective software would be used as a part of a business process.

The Agile team, including the product owner, developers, and testers, take these user stories, organise them, and use them as a basis for designing and building applications incrementally and rapidly. Typically taking two to five user stories at a time, developers will reserve anywhere from a week to a month to implement that subset of stories, depending on the Agile approach used and the complexity of the stories. The features supporting those stories are coded, and at the end of that time those features are working and operational. During coding, the project owner works with developers to answer questions and resolve ambiguities as the stories are translated from business processes to software features.

Because the software features must be complete, operational, and validated by the product owner at the end of each sequence, it can ideally be deployed to the business at almost any point in time. As a result, there doesn’t have to be a year-long development cycle, during which the business needs have likely changed. Applications can be deployed early and often, making some features available to users in the short term, while later features can be easily adjusted in response to user feedback and changing business needs.

Agile and testers – It only makes sense

At first glance, an Agile process seems to leave little for testers to accomplish. The connection between the end user and the developer appears to be direct, so a need to ensure that the final product was what users wanted seems unwarranted. And that direct connection to the users makes mid-course corrections seem seamless and straightforward. Developers can find and fix the bugs, while product owners ensure fitness for purpose.

However, independent testing is still vital. Quality is still one of the most important requirements in an enterprise application, and testing is the primary way of verifying quality and assuring that the development process produces quality software. But testers have to substantially change their approach to doing their jobs in order to assume an essential role in Agile development.

Because of their unique position in the application development lifecycle, testers are best equipped to connect business needs with the working application. In particular, testers are in an ideal position to codify user stories, and to determine how to objectively measure their completion. This is a business aspect of testing that is not typically the focus in traditional methodologies.

If the product owner is the principal author of the user story, it’s likely that he or she is making assumptions about the domain or the business process that are implicit in the story but probably not apparent to the development team. Such assumptions can lead to misunderstandings with the developers, who may not fully comprehend the product owner’s assumptions or point of view. Testers are in an ideal position to work with the product owner to identify assumptions and make them explicit, and to clarify any ambiguities in those stories before developers start coding from them.

Testing to meet user needs

Because testing is accelerated, it must be focused on the needs of the user community, in addition to a technical vision of quality. All test cases should tie back to user stories, rather than formal requirements. By enabling testers and product owners to work together to define the scope of the software, testers are best positioned to determine how to test the stories once they have been implemented.

Agile methodologies leave acceptance criteria up to the product owner, but that person is unlikely to be an expert in evaluating software, even against criteria he or she defined. Testers are especially qualified to play a key role here, because it is the essence of the profession. To facilitate acceptance testing, testers need to be intimately involved with translating user stories into application features. Doing so provides the ability for them to understand what the user community intended, and how it was translated into the application.

This level of up-front involvement makes getting from user story to acceptance test significantly easier. Tracing the implementation of user stories has the potential to be much faster and simpler, and require far less overhead. Because developers aren’t writing extensive specifications, testers can go right to building test cases that reflect the particulars of one or more user stories. An acceptance test case should enable the product owner to verify and validate that the user story has been implemented as expected.

Virtually all of these activities can be improved and accelerated with automation. Tracking a story from inception to acceptance test can be done manually, but requires testers to spend time examining documentation to perform that activity. A requirements and test management package will enable testers to record user stories and resulting features, while tracking acceptance test results back to both features and user stories.

Steps to quality software with Agile processes

For testers to take a leadership role in assuring quality in Agile software development and delivery, they have to work with, and at the pace of, the project. This means working with both users and developers in defining the project and ensuring its quality and fitness for the user business needs.

Here are the key steps to preparing and executing testing of an Agile project:

1. Get to know the product owner and user community. Understand fundamentally the business goals of the application. Your testing goals serve that group.

2. Break down user stories into prioritised testing requirements and track those requirements to completion. Use automated systems to capture user stories, distil requirements, and trace requirements through to implementation and back to user stories.

3. Translate testing requirements into test cases as early as possible. Work with users and business analysts to ensure that the test cases reflect real business needs. Work with developers to devise technology-facing tests.

4. Automate test cases and test execution so that tests can be rerun automatically, as part of the build process. This ensures that any regression is caught and corrected quickly.

5. Track test case execution to ensure the fitness of the application. Be able to report on test execution at any time, so that decisions can be made on application deployment.

6. Trace requirements from inception to delivery to ensure that business needs have been adequately addressed. This may mean adding requirements and tests later in the process, or deleting obsolete requirements.

These are the major ways that testers can demonstrate value and make essential contributions to software development and delivery in an Agile process. An equal focus on both the business and the technology, with support for the Agile team plus the development project, is critical in ensuring testers make a complete contribution to project success. And automation of these activities can ensure timeliness and repeatability of testing activities, not only in the current iteration, but future iterations as well.

www.seapine.com