How Software Testers Scrum

Although there are no titles like ?Software Tester? or even ?Software Developer? in Scrum teams, there are Development Team members with a range of skills that all work together to deliver an increment of functional software. Many of those Development Team members were originally hired as Software Testers and they bring a set of skills to the team that are some of the most necessary when delivering a done increment. That said, many software test professionals feel their job lies primarily in verifying functionality, rather than guiding it. This is a symptom of the waterfall way we?ve worked for so long. Development phase came first, and testing came after, thereby practically defining the role of software testers as a verification step.

Scrum calls for asynchronous execution, as do most agile methods. Yet, many Development Teams struggle how testing professionals can engage effectively during a Sprint. Common questions on the topic sound like these:

• How can I test something that doesn?t exist yet?
• We automated all the testing, what do the testers need to do?

While my team and I struggled with the same questions when we first used Scrum back in 2003-ish, I?ve seen the mountain-top on this one, and it?s Acceptance-Test Driven Development (ATDD). Simply put, ATDD is way to develop code in which we write failing automated tests that read very carefully as requirements. You?ve heard this refrain before, and ATDD is a form of Test-First Development as well as a form of executable specification.

I won?t define it here, but I like this article explaining ATDD, and not to be too self serving, but here is an online Pluralsight course that I created to dive deeply into the subject.

The key element of ATDD for Scrum Development Teams is that we can express requirements as failing tests, and do so at interesting levels of our application. The levels most teams find value in are at the Domain Conversation layer and at the UI layer. Acceptance scenarios at these levels may read like so:

Domain Conversation Layer

Given a Contact exists in the Address Book
When the Contact is edited
Then a record of that change is kept in the Change Log

UI Layer

Given I am editing an existing Contact in the Address Book
And I enter an invalid email address
When try to Save the Contact
Then I am presented with an error message

Guess who is amazingly good at creating requirements like these. If you said testers, you win.

In my experience, identifying and capturing these scenarios is exactly where testers excel. In fact, they are typically better at it than developers, who (like me) tend to focus on the happy path. A Scrum Development Team can take great advantage of this skill by having some people on the team focus on creating acceptance criteria like those above as sets of failing automated tests. While a team may never get away from some component of manual verification, the amount of time spent doing this goes way down when we focus on building a regression harness from the requirements themselves.

The basic idea is a work model that often looks like this:

While higher level Product Backlog Items may be brought into the Sprint, the acceptance criteria typically evolves and gets firmer over the course of the Sprint. In an ATDD world, these are simply the first steps of the above model, which can absolutely be done without being a seasoned coder.

1. Create a User Story
2. Define Scenarios (Scrum calls these Acceptance Criteria)

Creating these artifacts is fundamentally an analysis activity. This means the work of a testing professionals on the Development Team tends to move from this:

To this:

and that simply changes the game.

Of course this doesn?t account for things like performance test design and execution, but suffice to say that needs to be occurring each Sprint as well.

Also, this article does not discuss the tools needed to pull this off, so if that is interesting to you, check out these tools for .NET.

• StoryQ
• SpecFlow
• StoreEvil