Difference between revisions of "Agile Acceptance Test-Driven Development: Requirements as Executable Tests"

 
(One intermediate revision by the same user not shown)
Line 38: Line 38:
 
* write requirements as executable tests using a keyword-based and table-based language
 
* write requirements as executable tests using a keyword-based and table-based language
 
* apply the FIT or Robot frameworks  
 
* apply the FIT or Robot frameworks  
 +
* explain the difference between declarative and imperative tests, and why use declarative tests
  
  
 
== Outline ==  
 
== Outline ==  
 
* Acceptance TDD, example-driven development, and story/customer TDD
 
* Acceptance TDD, example-driven development, and story/customer TDD
 +
* Behavior-Driven Development
 
* Requirements and business rules as executable tests
 
* Requirements and business rules as executable tests
 
* Customer tests versus programmer tests
 
* Customer tests versus programmer tests
 
* Table-based and keyword-based requirements/tests  
 
* Table-based and keyword-based requirements/tests  
 +
* Avoiding script testing and moving to declarative tests that emphasize business rules
 
* Collaborative acceptance TDD development: test and requirement workshops
 
* Collaborative acceptance TDD development: test and requirement workshops
* FIT and Robot frameworks
+
* Robot Framework
* Connecting FIT/Robot requirements/tests to the underlying system  
+
* Connecting Robot FW requirements/tests to the underlying system  
 
* Table and example requirements/tests in relationship to other kinds of testing
 
* Table and example requirements/tests in relationship to other kinds of testing
* Five kinds of table-based requirements/tests
+
* Variations of table-based requirements/tests
 
* User stories, conditions of satisfaction, and acceptance TDD
 
* User stories, conditions of satisfaction, and acceptance TDD
 
* Refactoring executable requirements
 
* Refactoring executable requirements

Latest revision as of 20:08, 12 July 2011

Overview

2 days.

Test-driven development (TDD) involves writing an executable test before the solution code. Unit TDD focuses on first writing a small unit test and using that to drive development of a small solution fragment. Similarly, acceptance TDD involves writing one or more systems-level acceptance tests (or “customer tests”) for a customer-centric feature, before the solution. This brings together product management, developers, and testers at the start of each iteration to clarify and align on the iteration goals and requirements, by speaking a common, useful, and relative unambiguous language: requirements as executable tests. This is enabled with free open source technologies such as FIT and Robot, both which support creating keyword-driven table-based executable tests. Thus, acceptance TDD is primarily a method that brings together the stakeholders early on to clarify requirements through examples as executable tests. The traditional lines between requirements and tests become blurred – in a good way.

In this hands-on, skills-rich workshop, you will learn the method of acceptance TDD, including how to approach requirements-as-tests and tests-as-requirements, the different kinds of FIT or Robot tests, how developers, product management and testers can work together from the start, and how to connect FIT or Robot tests to the underlying system.


A closely related concept is known as example-driven development; this is essentially the same as acceptance TDD, but emphasizes that the concepts and tools are used primarily in the context of examples, rather than full requirements clarification.

You will leave with practical skill in doing acceptance TDD and example-driven development, and a new vision of how to do requirements, testing and development.


Methods of Education

Discussion, presentation, Q&A, workshop exercises


Audience

Anyone involved in learning, sharing or executing requirements or tests for systems development: product management, developers, testers, technical leaders.


Level

Intermediate: This course introduces concepts and techniques that the attendee will apply during the workshop.


Prerequisites

general involvement in systems development as a product manager, tester, or developer


Objectives

Upon completion of this course, students should be able to:

  • define acceptance TDD and example-driven development
  • facilitate a workshop where customers, product management, testers, and developers learn to align around a common language of requirements as executable tests
  • write requirements as executable tests using a keyword-based and table-based language
  • apply the FIT or Robot frameworks
  • explain the difference between declarative and imperative tests, and why use declarative tests


Outline

  • Acceptance TDD, example-driven development, and story/customer TDD
  • Behavior-Driven Development
  • Requirements and business rules as executable tests
  • Customer tests versus programmer tests
  • Table-based and keyword-based requirements/tests
  • Avoiding script testing and moving to declarative tests that emphasize business rules
  • Collaborative acceptance TDD development: test and requirement workshops
  • Robot Framework
  • Connecting Robot FW requirements/tests to the underlying system
  • Table and example requirements/tests in relationship to other kinds of testing
  • Variations of table-based requirements/tests
  • User stories, conditions of satisfaction, and acceptance TDD
  • Refactoring executable requirements


Related Courses

Before:


Maximum Participants

20


Environment - Room, Tools, Texts

Course Environment - Workshop Style6