Agile Requirements Management Agile Testing

Without requirements how do you know what it is you need to develop and how do you prove the software does what it is supposed to do? These question are as relevant to agile projects as they are to traditional projects, except that the requirements elicitation process on traditional projects is often a long, complex, and notoriously difficult task to achieve; it is estimated that as many as 75% of all projects fail because of issues with requirements.

The time taken to elicit requirements combined with the copious amounts of documentation that commonly need to be created and maintained seem completely at odds with the goals of agile development. This section discusses a number of best practices employed in the case studies that enable requirements to be managed in an agile manner.

The Role of Use Cases and User Stories in Test Case Design

A large number of the case studies(Sewell, Wilson, Kingston, and Warden, for example)report the benefits of use cases and user stories in eliciting the customer requirements for the system. These approaches elicit simple and easily understood examples of how the user interacts with the system that is to be developed(or that is in the process of being developed)to produce some outcome of value to the customer.

From a quality management perspective, the scenarios documented using these practices are not only useful in assisting the developers understand what they need to produce but also map very naturally into test cases. Sewell, for example, describes how involving the testers in the requirements analysis alongside the analyst and customer representative enabled accurate and effective tests to be designed in parallel with use case capture, driving testing earlier into the project life cycle and ensuring that the customer was satisfied with the correctness of the resulting test case.

Reducing Requirements Documentation Overload

Keeping documentation and the need for document maintenance to the minimum level possible is a well-established agile principle, and a number of the case studies Sewell, and Evans, for example)describe specific practices that they have employed to achieve this.

A great deal of documentation on projects is used for communication, such as passing requirements information to developers, testers, and other stakeholders. Sewell describes the value of daily stand-up meetings in improving communications and reducing documentation to manageable levels on a large agile project; the overhead of documentation is avoided because the team members are able to talk to each other about important issues, rather than having to type the information into an email or a change request tool, and can ensure that it is distributed to the people who need to know about it.

Sewell also describes the benefits of having all the stakeholders co-located from the start of the project, and in particular the benefit of having testers work alongside the analyst and customer representative during the requirements elicitation task. In effect, this short-circuits the need to provide long, complex, and potentially out-ofdate requirements information to the test team.

Evans describes a number of techniques for improving communications that can provide direct, honest, speedy, and productive information exchange with the goal of producing fewer and less formal documents(such as the Weaver Triangle.)The techniques that Evans describes can also be usefully applied to the process of requirements elicitation itself.

Denning makes an important point about the role of formal documentation in commercial projects, where it proved essential for a company contracted to perform a large and complex testing task on a commercially critical system to document the roles, responsibilities, and terms of reference for the project. Without this documentation, issues about the scope of the project and the responsibilities of the staff performing the work could have potentially put the profitability of the contract at risk.

From a review of the case studies and the very different perspectives on the role and use of documentation that they provide, a useful approach is to not be dogmatic about documentation but to look for strategies to reduce the project documentation capture and maintenance load. Automation, such as requirements management tools, for example, could provide such a solution.

Look Beyond Requirements to Real Customer Needs

Gilb makes the case in his Evo method for delivering customer value rather than sticking slavishly to traditional requirements elicitation practices. A key principle of Evo states that you cannot know all the customer requirements inadvance, but that you discover them more quickly during the process of delivering valuable working software.

Ensure All Requirements Have Tests

Except on the most trivial of projects, without requirements how do you prove the software does what it is supposed to do? Good testing practice demands that it should be possible to show that each requirement has one or more tests designed and implemented against it. Even though agile development best practice mandates that all units have unit tests associated with them, Sewell, cassidy , and Kingston extend this view by ensuring that any and all requirements can be shown to have tests written against them.

Tilt describes an approach used on a very large project in which rigorous test metrics and their statistical analyses were employed to formally demonstrate complete code and requirements coverage. Similarly, Wilson describes an agile continuous integration and build approach that uses tool support to automatically verify test coverage combined with a powerful graphical display to highlight areas of concern to the project stakeholders. Chana also describes the value of tool support in providing automated requirements management as well as the benefits of traceability that such products can provide(to determine who proposed and who authorized particular requirements or changes to requirements, for example).

Role and Use of Requirements Tools

As discussed in the previous sections, a number of the case studies describe the value of using tool support for requirements management.

Chana describes the use of a commercial requirements management tool to document, manage, and maintain rapidly changing requirements on a smallscale agile project. Traceability is a key benefit that Chana reports, allowing him to quickly and easily use the change history facilities of the tool to identify who had requested and authorized a particular requirement or change to an existing requirement. Other stakeholders were able to review and provide comments on the requirements through a web-based user interface, allowing non-co-located team members to be closely involved in the requirements process.

Wilson describes the role of requirements coverage as part of the wider tool support for a continuous integration build and testing process that he developed. In addition to being able to provide a graphical color-coded display of the underlying code coverage metrics, a specific benefit of this approach is to establish confidence in the testing for any given build or release; as Wilson puts it, “It is better to have an 80% unit test pass rate on 95% of the code, than to have 100% pass rate on 5% of the code.”

As with any tool, care must me taken by the project manager or team leader to avoid letting the tool become the focus of attention, rather than the task the tool has been acquired to achieve; I have seen far too many technical people become obsessed with fiddling and fine-tuning the features and facilities of a tool instead of focusing on the purpose of the tool–to save time and effort, and improve the quality of the delivered product!

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Agile Testing Topics