Requirements Driven Testing is not New

As long ago as 1970, when Winston W. Royce described the sequential model which came to be known as ‘Waterfall’, he pointed out the inherent weakness in its lack of feedback loops. This still appears to be a pressing need, highlighted by the advent of new development models, and shortening the feedback loops as far as possible is in turn necessary for successful continuous improvement.

Now companies are looking for continuous integration, development, delivery, deployment, improvement – all are distinct concepts, but with considerable overlap. This overlap relates to one ideal which all five concepts attempt to achieve: the efficient and effective testing and development of valuable software that delivers on constantly changing business and customer requirements.

The “continuous” aspect therefore relates to the ability to shorten test and development cycles to the extent that they can keep up with constantly changing customer needs. Below is a strategy for how this might be achieved.

Requirements Driven Testing and Development

The ability to continually deliver fully tested software starts with the requirements. They must be clear, complete and unambiguous so test and development teams know exactly what the customer and business requires, and how the software might be implemented within an existing system. Given that 56% of defects, and 82% of the money spent fixing them, stems from requirements based errors Bender “Requirements Based testing”, improving the quality of specifications seems a sure-fire way to reduce frustrating, late rework, and the delays it creates.

Clear requirements are therefore also essential to eliminate the time spent parsing feedback, or correcting mistakes when feedback is misinterpreted.

“Active” Requirements”

“Active” requirements is a term we use for those which can be clearly understood by the business, user and technical teams – fostering close collaboration – but which also include all the functional logic included in a system. With “active” requirements, as opposed to static written documents or diagrams, all subsequent test and development materials can be automatically derived.

Using a tool like CA Agile Requirements Designer, this includes optimized test cases and automated tests, linked to the right data and expected results.
Traceability is thereby introduced throughout the development lifecycle, and test cycles are shortened, as teams no longer have to manually create, maintain and execute an ever-growing library of tests.

Automated Change Management

When working from static, written requirements or diagrams, testers have no way to automatically identify the upstream or downstream impact of a change on a system’s logic. Tests have to be checked by hand and often every test case is “burned” and re-written in order to maintain test coverage, or more-and-more test cases are piled up, leading to ‘test case overload’. These then have to be executed manually, causing bottlenecks and an inability to “continually” test. Many of these issues remain even when automating test execution, as ever-growing test script libraries have to be maintained by hand.

Use Modelling for Continuous Delivery

Modelling a system with “active” requirements and by using a flowchart makes the automation of change possible. The flowchart is overlaid by all the functional logic involved in a system, and because complete traceability has been introduced, any affected test cases can be updated or removed, with any new test cases automatically generated. Pushing these out to be automatically executed makes change fully automated, making testing and development “continuous”.

It is only with the ability to automatically derive, re-derive, and execute tests that test cycles can be shortened to the degree that they can keep up with changing customer requirements. In the context of delivering software, this requires the ability to continually deliver fully tested software to market faster, and at less cost, whereby “combining iterative development with automation produces code so quickly, it is now thought of as continuous.”

About the Author

Georgina

Find out more about @georginagt