Hi all,
so life on the new team was short lived; I am back in the Perl team and working on a new "Acceptance Test Driven Development (ATDD)" project. This is a relatively new approach for the Scrum team I work on and a new part of the product we are testing.
ATDD for this team is basically automating the running of tests that confirm that the product "does what it says on the tin". In other words, we are creating a barrage of tests that run regularly (hourly) and confirm that the product conforms to a set of formal documents. These documents range from standards from industry to product specific behaviours.
Rather than testing edge cases and behaviours, what we are mainly doing is testing the products output in standard situations. Confirming that as it iterates towards the production version the standard outputs remain constant. In our case we are working on something new, so we are coding tests for things as or in places before the product actually does what it should.
So our test dashboards are turning red now, and slowly turning green as other teams enable the functionality we are testing. It is a interesting and rewarding way of working. You setup a test and see it fail, then some time (days or even weeks) later, it magically turns green when the other teams release the latest version of the product and the test starts passing.
One of the key things we did early on was tie our tests to the specification and standards documents. This has proven to be really key as we have in the test results (specifically in the failures) references to shared documents. So when we say to a member of another team "oph hey, feature x is failing because the widget says bing instead of bong" and the person knee jerks a response like "oh thats how it should be". We are able to say "REALLY???… Thats not what document X says. It says it should be bong, see right here on page 42…"
This is helpful for preventing the very human thing of batting things from one team to another as an immediate reaction to someone on another team saying what you have done is wrong. It's a programmatic way of solving a human problem.
We are using code that refers to documents to prevent people arguing. 🙂
Beyond this aspect of $dayjob, the team is continuing to develop it's use of TDD (Test Driven Development) and Pair Programming with mixed results.
Categories: Uncategorised
