Chris Schotanus

Independent IT management consultant and trainer (The Netherlands)
Training

SPECIFICATION BY EXAMPLE: FROM USER REQUIREMENTS TO TEST CASES

Specification by Example (SbE) is not primarily about testing. It is a technique that supports clarification of user requirements and, at the same time, leads to test cases that can be used to verify and validate the product. Specification by Example is a relatively easy yet powerful approach to (agile) software development. It supports the process in many ways and during various phases of software delivery: requirements elicitation, functional design, test design, test execution and acceptance.

Because of the joint effort during refinement, it becomes quite clear what the business requirements are and how these requirements should be implemented. There is no misunderstanding regarding the acceptance criteria. SbE reduces the effort needed for acceptance testing by the business since the team can execute the majority of the acceptance tests.

During the actual software development, it becomes possible to continuously determine the quality of the system (both technically and functionally), which enables a continuous integration and delivery process. The result of this approach is an improved design, shorter test process and fewer failures (either design or code) in the production environment. This is when iterative “waterfall” development really becomes agile.

Agenda

Introduction
Requirements
    Different types of requirements
    Why do we need them?
Requirements during backlog refinement
    Requirements elicitation
    Requirements validation
    Requirements documentation
Specification by Example
    Who, What, How
    Documentation
The use of Requirements specification as test cases
The effect of SbE on the Agile development process
Group discussion
Wrap up

Objectives

To understand the positive impact of Specification by Example on the (Agile) development process and how it will lead to:

  • Common understanding: the development team, the product owner and the stakeholders agree on what will be developed. There is no “that’s not what I meant”.

  • Clear acceptance criteria: The software is accepted if all tests (examples) are passed.

  • Implicit and living documentation: The test cases are the documentation. In case of a change, the test cases will be changed first.

  • Easy automatable test cases: There are open source and commercial testing tools that are able of to automate the execution of the examples.

  • Regression tests maintained implicitly: The test cases are executed in every cycle

In short: First-time-right delivery

Target audience

i

Product owner

The Product Owner will be able to specify his or her requirements

Developer

The Developer will understand the details of the requirements

U

Tester

The Tester will be able to create test cases

Your trainer will be:

Chris C. Schotanus

Chris is an IT specialist with over 40 years of experience in IT, of which 27 in testing, test automation and test management. Chris has provided test and agile related training courses in various countries in Europe and beyond. After 35 years of employment with CGI in the Netherlands, he now works as an independent IT management consultant and trainer.