Developers and code testers know there is a sweet spot somewhere between regression testing and customer usability. Even 100% code coverage doesn’t guarantee a good customer experience, but smart UI testing gets you closer to test perfection. A fluid UX helps avoid rework, and anyone on the team, from Scrum Master to Dog Walker, can help with UI testing, so it’s a truly Agile practice!

But wait! Isn’t UI testing something that users (or their proxies) are supposed to do at the end of a release? As Agile development practices move many teams closer to continuous delivery, applications need to be user-ready before they reach the UAT stage, or agility goes by the wayside.

Writing test scripts that bridge the gap between automated testing (e.g.; Jenkins, Selenium, Cucumber) and the mind of the customer can be a balancing act, but it doesn’t have to be difficult. In fact, simplicity is the secret. Such simplicity, in fact, that it is easy to forget that Gherkin is a testing language at all. There are many benefits of using Gherkin scripts for multiple test methods, because Gherkin is:

• Logical
• Reusable
• Plain English
• Ready to use for UAT
• Easy to convert to Cucumber
• Easy to convert to Selenium

This interactive presentation includes a brief introduction to Gherkin language, instructions for writing and advice for not writing Gherkin scripts, and many, many examples of simple, successful test plans that test functionality while focusing on the user experience. Two learning activities will help participants to practice trimming their test scripts to include only what is essential, and to focus on every user story’s benefit to the end user.

You must be a Subscriber to view this post and you are currently not logged in.

You can either log in below or sign up here.