New article at Ranorex, “Postmodern Agile: A Story of Collaborating Beyond Buzzwords”

postmodern agilePostmodern Agile: A Story of Collaborating Beyond Buzzwords (22-Jun-2018)

Some articles seem slightly embarrassing to me after I see them published. I thought this might be one, but I think the point should be well-taken: we’re way too invested in dogmatic process trappings. This blog post for Ranorex tells the story of a day in a life where we don’t talk about a process, we just live it, with the singular goal of delivering high-quality software frequently.

New webinar video at Ranorex, “Breaking Through the Barriers to BDD”

Breaking Through the Barriers to BDD (14-Jun-2018)

I think I’m getting a better feel for the interview-style webinar, not having done much of them in the past (this is my… um… second one). This webinar is a discussion around things like organizational resistance to BDD, and touches on the core notions for what can make BDD succeed in your organization.

New article at Ranorex, “The ABCs of Acceptance Test Design”

ABCs of acceptance test designThe ABCs of Acceptance Test Design (7-Jun-2018)
In this blog post for Ranorex, I present seven design principles for the tests you’ll craft as part of practicing behavior-driven development (BDD) or acceptance test-driven development (ATDD). Stick to these principles and you’ll create a body of tests that returns many benefits while allowing you to keep your sanity.

Questions Answered! .. for Gurock Webinar, “BDD Testing Skills”

BDD Testing Skills–Q&A

A number of good questions about BDD arose from the Gurock webinar “BDD Testing Skills,” delivered on April 13. I felt like answering them all, though I did so rather hastily. You’ll find the questions-and-answers here. (15-Apr-2018)

New Gurock webinar, “BDD Testing Skills”

BDD testing skills webinarSimon Knight interviewed me for the Gurock webinar “BDD Testing Skills,” delivered on April 13.

During this session we talked about:

  • The background and history of BDD – how we got to where we are now
  • BDD as a tool for facilitating conversations and better collaboration
  • Some of the benefits of using BDD and how best to achieve them
  • The pitfalls and challenges that come along with implementing BDD, and how to include it as part of a broader testing strategy

New article at Gurock, “Can You Have Too Many Tests?”

too many testsCan You Have Too Many Tests? (23-Feb-2018)

Yes you can.

In this blog post for Gurock, I talk about a customer who didn’t realize the pickle they were brining themselves into when they slowly but surely found their way on a path to “too many” tests.

New article at Gurock, “Succeeding With Test-Driven Development at a Distributed Start-up”

Distributed TDDSucceeding With Test-Driven Development at a Distributed Start-up (17-Jan-2018)
In this blog post for Gurock’s blog, I talk about my experiences doing test-driven development (TDD) at a small startup: Where did we succeed, where did we fail, and what would I change?

New article at Gurock, “Clarifying Scope with Scenarios in Behavior-Driven Development”

Scope & scenarios in BDDClarifying Scope with Scenarios in Behavior-Driven Development? (19-Jan-2018)
In this article written for Gurock’s blog, I talk about the values of negotiating around scenarios when doing behavior-driven development (BDD). Rather than delve deep into the narratives (given-when-thens), this focus will help when it comes to negotiating the scope of a given story.

New article at Ranorex, “Should We Automate All of Our Feature Scenarios?”

automate all our feature scenarios?Should We Automate All of Our Feature Scenarios? (8-Feb-2018)
This post for Ranorex’s blog talks about how behavior-driven development (BDD) can help us come to consensus. I share a story about a customer who found value in BDD, even though we were unable to automate their “specs by example.”

A Fitnesse Glossary for Non-Programmers

Fitnesse is designed to be a simple table-driven testing framework that’s accessible to anyone who has a web browser. Just like anything, however, it’s not without its own set of terms, which can be initially overwhelming, particular for folks who don’t program computers for a living. Here’s a glossary you may find useful.

acceptance test
A test whose success indicates that a particular feature meets the expectations of the customer and thus may be delivered.
action fixture
A FIT fixture type that supports tests that capture a series of events. Each row in an action fixture table supports either an action–such as “press” or “enter”–or a verification (“check”) that the system shows a certain value.
camel case
A compound word with no spaces (or other special characters) where the start of each contained word is an upper case letter. For example: ThisIsCamelCase appears in upper camel case; thisIsCamelCase appears in lower camel case.
child page
A page that is conceptually subordinate to another. For example, a page named GovernmentBranches might have three child pages: LegislativeBranch, ExecutiveBranch, and JudicialBranch.
The intersection of a row and column in a table.
A configuration element that tells Fitnesse where to look for fixture code.
collapsible section
A portion of a wiki page that can be “collapsed” (mostly hidden from view) or expanded.
column fixture
A FIT fixture type that supports a number of functional tests. Each row in a column fixture is a collection of inputs and expected outputs.
decision fixture
A SLIM fixture type that is analogous to the FIT column fixture.
do fixture
DoFixture is a FitLibrary fixture type that supports verifying a workflow–an arbitrary set of sequential steps.
The original Fitnesse test system (“Framework for Integration Tests”); see also SLIM.
A third-party collection of additional test fixture types.
A thin layer of code that Fitnesse uses to drive the application being tested from a test table.
fixture argument
A value passed to a fixture, appearing after the name of the fixture, used to initialize the fixture (often used to constrain results returned from a query).
graceful name
An aesthetically pleasing, more readable version of a wiki word or other compound word. For example, “customer name” is a graceful name that translates to “customerName” when Fitnesse runs its tests.
A web page element that navigates to another web page when clicked.
markup language
the set of conventions used by the Fitnesse wiki to “mark up” page text for formatting purposes. For example, to create the italicized word fish in the Fitnesse wiki, you mark it up by surrounding it with double-tics: ”fish”.
markup variable
a Fitnesse mechanism that allows for simple text substitution anywhere in a test page or sub-wiki
page hierarchy
A set of wiki pages organized like an upside-down tree, into parent and child relationships. Each wiki page may have one or more child pages.
Various page attributes. Fitnesse allows customization of features such as editability on a per-page basis.
To restructure some aspect of the Fitnesse wiki. The refactoring features of Fitnesse allow for search & replace, renaming pages, moving pages to another location, and deleting sub-wikis.
To change the currently active Fitnesse page version to an older version.
row fixture
A FIT fixture type that supports verifying the result of a query. A row fixture contains one row for each record expected when the system returns a collection of results.
query fixture
A SLIM fixture type that is analogous to the FIT row fixture.
scenario table
A SLIM fixture type that can be called from other tables.
script fixture
A SLIM fixture type that is similar to the FitLibrary do fixture.
set up
A page that contains a number of common initialization test tables. The SetUp page in Fitnesse is run prior to each test in the sub-wiki where it is defined.
A Fitnesse test system with a thinner client architecture that supports easier porting to new versions and languages than does FIT.
A whole new page hierarchy that lives between a single Fitnesse page.
A sub-wiki that is run as a collection of tests. Any test pages appearing as child pages of a page marked as a suite are executed when the suite is executed.
A variable that appears in a table, allowing you to capture or use the value returned into an output cell from a fixture.
symbolic link
An alias for another page in the wiki
A number of rows and columns grouped together.
tear down
A page that contains a number of common test tables used for cleanup. The TearDown page in Fitnesse is run subsequent to each test in the sub-wiki where it is defined.
test page
Also known as a Fitnesse page. The test page represents a set of steps to be executed for a single test case. A test page is identified by a wiki word and contains one or more test tables.
test runner
An application that executes one or more Fitnesse test pages. For example, the CommandLineTestRunner is used to execute tests from a batch or build process without need for human interaction.
test table
A table that declares inputs and expected outputs for test scenarios.
The contents of a page at a specific point in time. Fitnesse creates a new version each time you change a page’s contents.
a web site that allows all users to directly edit and add web pages, using a simpler formatting convention than HTML.
wiki import
A feature that allows you to import an entire wiki or subwiki from another Fitnesse site.
wiki word
A unique name for a web page that is created by appending two or more words using upper camel-case. For example, FitnessePage.