Matthew Eakin is a Manager with the Managed Testing Practice of Sogeti USA and has over 20 years of technical, leadership and planning experience. His experience in all aspects of the SDLC, combined with development skills, has helped Matthew to be an effective Agile testing practitioner and coach. He talks extensively on Gherkin Scripting and is in high-demand as a BDD (Behavior Driven Development) and ATDD (Acceptance Test Driven Development) coach. His two workshops (Agile Testing and A Manual Testers Guide to the Ruby/Cucumber Framework) have been so successful that Matthew now leads the series nationally and teaches customized variations of the program at client sites.
QUEST 2015 Conference and EXPO Sessions:
Test scripts have always been difficult to write. Do you have enough detail? Is there too much detail? What is the purpose of this script? These questions have bothered testing professionals for a long time. Over the past few years a solution has emerged that solves problems with writing test scripts. With the creation of the cucumber framework came the Gherkin Scripting format (also known as the Given-When-Then format). But its usefulness in writing test scripts is not limited to automation or agile projects. The structure of a Gherkin script is very straight-forward. Given provides you with the background. When tells you what is being created. Then tells you the expected results. Manual and automation testers, business owners and developers in every type of SDLC can benefit from Gherkin Scripts. During this workshop Matthew will walk through the process of crafting a well-written Gherkin Script from a traditional waterfall requirement. Then he will repeat the process using agile user stories and acceptance criteria. He’ll show you how a well crafted Gherkin Script can be a beautiful work of art.
- Learn the Gherkin Scripting syntax: Given-When-Then
- Write scripts in the language of the domain so all team members understand scripts
- Apply Gherkin Scripting to traditional requirements and agile user stories
ATDD (Acceptance Test-Driven Development) was created as part of Dan North’s BDD (Behavior-Driven Development) model and is almost exclusively associated with Agile methodologies. With short sprints and acceptance criteria defined early, ATDD does seem like a natural fit for Agile. When developing software using waterfall methodologies teams rarely have a clear definition of done. It would seem that ATDD would be a difficult fit for a waterfall project. In his presentation, Mr. Eakin shows how making minor tweaks to waterfall projects using ATDD principles and practices can change a waterfall project from ‘destined for failure’ to a ‘smashing success.’
- Apply ATDD principles and practices to waterfall projects
- Get to done faster and still meet the business’s needs
- Start the ATDD process with UAT scripts