Testing in an Agile Environment

This course is designed to leave delegates more confident in five key areas:

1. How testing is affected by switching from waterfall to agile
2. How testing works in a cross-functional team
3. BDD scenarios: Specifying acceptance criteria with examples of behaviour
4. Gherkin: how clear and concise scenarios can drive automated regression tests
5. Developing an end-to-end testing strategy that supports agility

Course Content

Simulation of Product Delivery in a Non-technical Environment
The workshop begins with a simulation of a product delivery system where the entire class takes part in delivering product in a traditional approach. Small groups work together to complete different stages of a process, and the testing team validate the results. The natural interactions and behaviours of the teams taking part often create quality control issues, and this is compared to similar processes in the real world.

The team is then re-organised into cross-functional teams, where the specialisms from the first line are relaxed and teams are able to organise themselves to get product through in smaller batches, getting fast feedback and allowing quality issues to be identified before too much effort has been wasted. The teams are then able to discuss the benefits and challenges of achieving similar results in the real world.

Testing in a Cross-Functional Team
We look at a range of modern testing practices and consider how and when the following types of testing might be carried out:

• Unit tests
• Functional tests
• Regression tests
• Exploratory tests
• Security penetration tests
• Performance tests
• User acceptance tests

Behaviour-Driven Development
Delegates will learn how to use BDD to collaborate with the business and agree how the software should work before it is built. For example, should the login system allow you to try again if you entered the wrong password? How about if you’ve already tried four times? This course introduces the concept of scenarios structured as preconditions, actions and results. For example:

Given I have entered the wrong password four times, when I try again then I see an error message stating my account is locked.

Delegates will learn that these conversations bring assumptions to the surface that may be clarified before development takes place, and will apply this technique to a simple case study feature – creating a full set of BDD scenarios.

Gherkin and Automated Testing
Gherkin is a name for the syntax or format of BDD scenarios. Delegates will build on the simple “given, when, then” format learned in previous exercises and explore the full range of options for developing clear and expressive scenarios:

• Feature files, documentation and scenario headings.
• Step definition files and options for test automation (overview – no coding involved).
• Scenario backgrounds, outlines and example tables.

This will be applied to a complex case study example that involves making some decisions about how the feature should work. Delegates may play the roles they normally play such as test specialist or business representative, and then reflect on how and when they should do this back at the office.

Creating an Effective Test Strategy
The workshop will conclude with an exercise allowing delegates to model their current software delivery pipeline, and then to identify areas where testing might help to improve outcomes. Typical factors identified include:

• Defect rates and the necessary testing practices to manage them.
• Cost of release incurred though manual regression, and the business case to funding automation.
• Frequency of re-working features that were not clearly understood, and the collaboration required from the business to address this.

Testing in an Agile Environment Outcomes

All attendees will leave the workshop understanding the advantages of an effective agile testing strategy. Practical steps to realise these advantages will have been established, and attendees will know how to put them into action.