Ambiguous or missing requirements cause waste, slipped schedules, and mistrust with an organization. Implementing a set of misunderstood requirements produces developer and customer frustration. Creating acceptance tests prior to implementation helps create a common understanding between business and development.

Acceptance tests start with communication between the members of the triad- business, developer, and tester. In this session, we specifically examine how to use tables as an effective means of communication. Employing tables as an analysis matrix helps a team discover missing scenarios. Redundant tests increase test load, so we show how performing an analogy of Karnaugh mapping on tables can help reduce redundant scenarios. We demonstrate that examining tables from various aspects, such as column headers, can reduce ambiguity and help form a domain specific language (DSL). A consistent DSL decreases frustration in discussing future requirements.

We briefly show how to turn the tables into tests for Fit and Gherkin syntax.

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

You can either log in below or sign up here.