Press "Enter" to skip to content

Absolute ATDD: a radical approach to Git

Git Workflow designed for Acceptance Test-Driven Development

Automating acceptance testing is a hot topic. Depending on how you implement it, it will be called Behavior-Driven Development (BDD), Specification by Example or even Acceptance Test-Driven Development (ATDD).

In any case, at some point you end up with automated acceptance tests:

  • Acceptance tests are written through a strong collaboration with business people, and sometimes written directly by them
  • Often, acceptance tests are written in a pseudo-natural language, enabling business people to take active part in them
  • Acceptance tests are written before the corresponding production code, which makes the acceptance tests akin to specifications
  • As a result, acceptance tests fails at first, since the new expected behavior isn’t implemented yet (as opposed to no-regression tests)

Who writes the test cases?

When a team embraces this way of working, a tough topic appears: how do you keep them in sync with production code?

The best solution is obvious: just push the test cases in GIT along the production code.

But who, in the team, pushes the test cases in GIT?

The team’s QA/tester of course!

  • While pushing the test cases in GIT may seem like an impossible task to many business people, most QA/testers have no trouble doing so
  • QA/testers provides the perfect mix of skills to write test cases: express test cases with business words + take into account the technicalities involved by running the test + follow testing best practices

Having clear-cut responsibilities in GIT

If we say that:

  • QA/testers are the one writing automated acceptance test cases
  • And production code never gets written before the acceptance test cases

… then that means that only QA/testers should create new branches in GIT.

That makes sense: a developer isn’t supposed to work on production code unless the acceptance tests are already written.

I am describing a way of doing where only QA/testers would have the right to create new branches in GIT; developers would merge once development is done.

As a developer, how would you feel with such a way of working? Would you feel denied of a fundamental right?

Shift-left to the max!

I don’t feel like this proposition is ridiculous.

Actually it would be the perfect mirror of how the modern, Agile QA/tester is supposed to work: doing his part right from the beginning.

In the traditional, warden attitude of the QA/tester, checking everything before accepting a release— which is synonym of merging to master.

My proposition is the complete opposite: instead of owning the last step before releasing, QA/testers own the first step before development. Instead of owning the final merge, QA/testers own the first branch creation.

This is the perfect illustration of the shift-left concept: QA/testers working as early as possible on backlog items, instead of working on backlog items at the last possible moment.

What do you think? Want to give it a try?

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top