Test-Driven Development in the Larger Context: Pt 1. Audience

One difference between ATDD and UTDD becomes clear when you examine who is involved in the process.  We will call this the “Audience” for the process in this blog.

Audience

 

ATDD

Acceptance tests should be created by a gathering of representatives from every aspect of the organization: business analysts, product owners, project managers, legal experts, developers, marketing people, testers, end-users (or their representatives), etc.  

ATDD is a framework for collaboration that ensures complete alignment of the development effort that is to come with the business values that should drive it.  These business values are complex and manifold, and so a wide range of viewpoints must be included.  Acceptance tests should be expressed in a way that can be written, read, understood, and updated by anyone in the organization.  They should require no technical knowledge, and only minimal training.

The specific expression of an acceptance test should be selected based on the clarity of that form given on the nature of the organization and its work.  Many people find the “Given, When, Then” textual form (often referred to as “Gherkin”) to be the easiest to create and understand.  Others prefer tables, or images, or other domain-specific artifacts.

We once worked with an organization that did chemical processing.  We noted that in all their conversations and meetings, they used images like this in their PowerPoint slides and on the whiteboards, etc.:

To most people (including myself) these would not be easy to understand, but for this organization it was obvious and clear.  For them, expressing their acceptance tests this way lowered the bar of comprehension.  Why make them convert this into some textual or other representation?  Use their language, always.

Typical business analysts spend much of their time looking at spreadsheets, or Gantt charts, or Candlestick charts, etc…  The point is, once the stakeholders of a given piece of software are identified, then the form of the expression chosen should be whatever is clearest for them.  They should be able to write the tests, read the tests, and update the tests as needed, without any understanding of computer code (unless the only stakeholders are literally other developers).

The notion of automating these tests should never drive their form.  Any representation of acceptance can be make executable given the right tools, even if those tools must be created by the organization.  Choosing, say, Robot or Fit or Specflow to automate your acceptance tests before you identify your stakeholders is putting the cart before the horse.

 

UTDD

Unit tests should be written by technical people: developers and sometimes testers as well.  They are typically written in the computer language that will be used to develop the actual system, though there are exceptions to this.  But in any case, only people with deep technical knowledge can write them, read them, and update them as requirements change. 

To ensure the suite of tests itself does not become a maintenance burden as it grows, developers must be trained in the techniques that make the UTTD effort sustainable over the long haul.  This includes test structure, test suite architecture, what tests to write and how to write them, tests that should be avoided, etc.   Training of the development team must include these critical concepts, or the process rapidly becomes too expensive to maintain.

Intro
Part 1
Part 2
Part 3
Part 4

Test-Driven Development in the Larger Context: TDD & ATDD (Introduction)

Introduction

A question that often arises in our consulting and training practices concerns the relationship between Test-Driven Development (TDD) and Acceptance-Test-Driven Development (ATDD).  Which is “really” TDD, and which should an organization focus on in terms of which comes first, and which should achieve the most attention and resources?

It’s not uncommon for someone to refer to TDD as “developers writing unit tests before the production code”.  That is one form of TDD, certainly, but is a subset of a larger set of ideas and processes.

Similarly, it’s not uncommon for someone to refer to ATDD as “acceptance tests being written before the development cycle begins”.  Again, this is not incorrect, but it is usually seen as a separate thing from what the developers do which is typically thought of as “TDD”.

The truth is they are both TDD.  They are not conducted in the same way nor by the same people (entirely), and the value they provide is different (but compatible) … but at the end of the day TDD is the umbrella that they both fall under.  TDD is a software development paradigm.

This blog series will begin by investigating the differences between these two forms of the overall “Test-Driven” process, which we will call (for clarity) ATDD and UTDD (or “Unit-Test-Driven Development”, which most people think of as TDD).  We will see how they differ in terms of:

1. Who is involved?  Who creates these “tests”, updates them, and can ultimately read and understand them in the future?  We will use the term “Audience” to describe the different groups that conduct ATDD and UTDD.
2. When they are done, and the granularity of their activities.  This “Cadence”, as we shall see, is quite different and for good reason.
3. Finally, we will examine the difference in the value and the necessity of the effort to automate these two different processes.  Both certainly can be automated, but how critical is such automation, what value is derived with and without it, and where should the effort to automate fall in the adoption process?  We will call this section “Automation”.

After having examined the differences between ATDD and UTDD, we will then address how they are the same, why they both fit under the overall rubric “TDD” and how, ultimately, they synergize into a very powerful way to create alignment around business value in software development.  These similarities include:

1. Shared understanding of the valuable behaviors that make up a requirement, and the way those behaviors satisfy the expectations of the stakeholders.
2. The preservation of high-worth enterprise knowledge in a form that can retain its value over time.
3. The creation of a high-quality architecture and design, and all the value that this brings in terms of the ability of the organization to respond to market challenges, opportunities, and changes.

Regardless of your process, every activity conducted by every individual in a software development organization should be ultimately traceable back to business value: every bit of code that’s written, every test that is defined and executed, every form that’s filled out, every meeting that’s called, everything.  We want to show that TDD is in complete alignment with this concept, and, when properly conducted, increases the value of every investment of time and effort, and its ultimate return to the bottom line.

Links to the parts of the blog:

Intro
Part 1
Part 2
Part 3
Part 4