Test-driven Project

Written on

Definition

A test-driven project is a (software development) project, which applies the development of automated tests based on acceptance criteria throughout the project as the central theme of getting work done.

The main artifacts are Gherkin test specifications, which are the communication medium between customer, project manager, and implementers (concepter, designers, developers). The test specifications are meant to walk all parties through all stages of the project, from the initial requirements gathering until the final acceptance test phase and project hand-over.

The test-driven approach applied with test-driven projects is called behavior-driven development (BDD).

Other approaches, such as unit testing, should be considered to increase the stability of the resulting software, but are not the main focus of this approach (because they are typically tech-centric).

Stages of the Process

  1. Initial Requirements Gathering: Acceptance Criteria (draft documents, clustering, Gherkin)
  2. Concept: Acceptance Criteria (refinement, Gherkin), Epics / draft User Stories
  3. Epics: User Stories (drafts), Acceptance Criteria (attached or linked to Epics or User Stories) [1]
  4. User Stories: (refinement, Grooming meetings) any “ready” User Story is covered by (at least) a test specification.
  5. Design: (designers, if required to refine User Story) designs and wire frames are attached or linked to User Stories.
  6. Implementation: any User Story requires a Gherkin test to exist (product owner requires any developer to ensure this is the case! – Definition of Done)
  7. Automated Testing: when a feature is completed and pushed to develop all acceptance tests run over the whole project.
  8. Hand-over to Customer: no laborious Acceptance Test phase (with a lot of features, “big bang” release); instead single features can be demonstrated to customer as soon as they are completed.

Important Note

This is a safe process provided that all Acceptance Criteria (checked in steps 7 and 8) fully and pedantically cover the customer’s requirements. Ideally, the Acceptance Criteria have been specified to a significant portion by your client autonomously (and were refined with the help of your project manager)!

Notes / Recommendations:

[1]project managers (Product Owners) should save all acceptance test specifications (Gherkin tests) directly in the team’s version control platform (GitHub, Bitbucket, etc.).

Hints

Python/Django:

  • Gherkin test specifications can be written in any natural language (English, German, French, Italian, etc.) – run behave --lang-list for a list of available languages.
  • Tests can be executed by developers in their development environment (e.g. Vagrant boxes) using python manage.py behave or python manage.py behave --use-existing-database.

See Also

External Resources

comments powered by Disqus