This is DAT

Many of our stories include a task called DAT (Developer Acceptance Testing). The DAT task is a final task to make sure that the story card matches the implementation. (A note on Agile terminology: for our purposes a story takes about 5 to 10 days; a story is broken down into tasks of about 1/4 to 1 day).

Finding Discrepancies

When starting DAT, it’s useful to temporarily take off your comfortable Developer hat and put on your (tight fitting but compellingly stylish) QA hat. Step through the story card line by line and run the application. Just identify discrepancies for now, and don’t try to fix as you go. Why? You might find a problem that is too big to fix in a reasonable amount of time and need to get guidance on the priority of fixing or you might find a discrepancy which turns out to be a bug in the story card, not the implementation.

Classifying Discrepancies and What to do About Them

I can think of three major classes of discrepancies:

  1. Requirements Bugs. Sometimes the developers and story writers discuss and change details of scope, sometimes removing or deferring scope. Sometimes these changes are not captured in the story cards. If the story card isn’t updated, grief ensues for QA and the customer.
  2. Development Bugs. Most of the time this means finding items in the story card that the team has mis-implemented or missed implementing.
  3. Integration Bugs. Sometimes, with many developers working on the story, the thing just doesn’t come together in the end. E.g., there’s some fundamental mismatch between the front end and the back end.

The first class of bugs, requirements, is pretty easy to deal with (once you’ve recognized them)–just update the story card.

The second class of bugs, development, can for the most part be handled as part of the DAT task (put your comfy Dev hat back on). In the interest of visibility, any bugs that can’t be solved during the time allocated to the DAT task should be added as tasks to the story board with estimates. This allows the team to figure out whether they should be dealt with immediately during the story, logged as bugs to be dealt with later, or removed from the story card and added to a subsequent story card.

The third class of bugs represents BOTH an immediate development problem to be handled like a development bug as above AND a development process problem. Wherever possible, stories should be broken into tasks that allow end-to-end integration as soon as possible. It should not be left to the last task to integrate all of the other tasks. This situation also indicates that appropriate Web or Integration tests have not been written. It may be too late to address these process problems for this story, but these should be kept in mind for subsequent stories or the next retrospective.

What do you think about DAT?

Philosophically, DAT feels like a tactic to deal with a Waterfall environment. That is often the reality in which we find ourselves–integrating with another organization, the client providing BAs and QAs who aren’t totally embedded with the team.

In an ideal world, DAT would not be necessary. Story cards would be kept up to date; developers would implement with a eye for detail and integrate everything ASAP. In practice, I think DAT provides a reduced feedback cycle, rather than waiting for QA to find obvious bugs, and a greater sense of developer ownership for the product.

It's only fair to share...
Share on FacebookGoogle+Tweet about this on TwitterShare on LinkedIn

Leave a Reply