Testing Experience Issue 16, December 2011

Record card

What the links show

The December 2011 issue was published as testingexperience16_12_11.pdf and mirrored under the issues folder. Twelve referring domains link it. The most specific citation is a research-community wiki page about Gojko Adzic, the author of Specification by Example and Bridging the Communication Gap, which lists an 'Editorial' in the issue among his writings and links the file. The anchor '"Editorial"' appears on four referring domains, all copies or mirrors of that biography page. This record therefore says that the issue carried an editorial associated with Adzic in that citation; it does not reproduce or summarize the editorial, whose text is not in the link data.

A guest editorial by a leading voice on specification by example fits the magazine's late-2011 direction. Acceptance-test-driven development, behaviour-driven development and living documentation were the subjects practitioners argued about that year, and the magazine's readership overlapped heavily with the agile testing community the publisher's conference served. Five domains used the raw URL as anchor, the sign of readers sharing the download; the others are tester blogs and reading lists.

The issue also marks the point at which the magazine's own newsletter tracking begins to show in the link record. From issue 19 onwards the file URLs carry campaign parameters from the publisher's analytics (the pk_campaign and pk_kwd query strings), which is why later issues have many URL shapes. Issue 16 has only the clean names, and both redirect here.

The continuation for a reader who followed the Adzic citation is acceptance test driven development, which explains the discuss-distill-develop-demo cycle and the example tables at the heart of specification by example, and definition of done. Both are in the Agile Testing hub.

The issue 16 anchors are the most lopsided in the run: four of twelve domains use exactly the same anchor, the word Editorial in quotation marks, and all four are the same biography page and its mirrors, so one editorial decision by a wiki produced a third of the issue's referring domains. Five more domains pasted the raw URL. The remaining three are tester blogs and reading lists using the magazine's name. Both file names carry the string testingexperience16_12_11.pdf; the root shape holds nearly all the links. No campaign-tagged shapes exist for this issue, which brackets the start of the newsletter tracking to some time between December 2011 and September 2012. The wiki's entry is titled only Editorial, which is consistent with a guest editorial rather than a feature article, and that is as far as the anchor takes the record.

A reader who followed the biography link wanted the editorial's argument, which is not available here, and behind it the practice Adzic is known for: specifying a feature with concrete examples before building it. The acceptance test driven development guide gives that practice in full. Figure 1 shows the discuss, distill, develop, demo cycle; the five-step three amigos session starts with reading the story aloud for two minutes; the worked example is a discount rule specified in seven example rows that cover every rule, the threshold boundary, the coupon and loyalty collision and the cap; and Table 2 sets ATDD beside BDD and TDD. The definition of done guide's story-layer table then shows where the passing examples are recorded as evidence.

Specification by Example, the book the biography page associates with Adzic, was published in June 2011, six months before this issue, and the practice it named was still contested at the time: teams argued about whether examples were tests, whether business people would write them, and whether the tooling would survive. By 2026 the argument is settled in the practice if not in the vocabulary. The given-when-then form became the common way to write examples, living documentation became a standard expectation for regulated teams, and the three amigos session became a routine sprint ceremony rather than an experiment. What did not survive is the hope that examples would be written by business people alone; the guide's session format assumes a developer, a tester and a product owner in the room, which is where the practice ended up.