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?