Absolute ATDD: a radical approach to Git
Git Workflow designed for Acceptance Test-Driven Development
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?
Sources and further reading
Comparing Executable Specification tools
For when you want to go ATDD-, BDD- or SpecByExample-stylejp-lambert.me
GIT, GitFlow and Continuous Integration for Dummies
It doesn't hurt to understand how developers workjp-lambert.me
Why so few Agile testers?
Because most companies are faux-Agile…jp-lambert.me
Liked this article? Show it!
Please clap 👏 and share the article! It is because of you that I put my heart and soul into writing.
And follow me on my blog to be notified when I publish new articles!
Thank you so much!