I have a painfully small manual test team, sometimes 1 tester per 15 developers. The answer to the obvious question “who tests?” is “mostly the developers”. Of course this only works if you’re doing extensive automated testing including Specification by Example with a tool such as Cucumber.

In fact testing responsibilities are shared by the developers, manual testers and the business.

Developer Responsibilities for Testing

I want the developers to take responsibility for quality. The more testers on the team the less responsibility the developers feel for testing. So I don’t give them that luxury.

The main developer testing responsibilities are:

• Tech voice in Three Amigos¹ discussion
• Step Definitions for Gherkin scenarios
• Unit Tests

The developers are involved in the Three Amigos discussions on what the Gherkin scenarios will contain. They provide the technical voice. Basically answering the question “Can I implement what is being discussed?”

Once the scenarios are written the developers write the step definitions, preferably with a test-first outside-in approach. The step definitions are the bit that automates the Gherkin scenarios. They are proper code. Ruby, or Java or C# or whatever.

The last bit are the unit tests. Automated tests for developers by developers.

Manual Tester Responsibilities for Testing

As I said I believe in having a painfully small manual test team. Often only one person even when there are 12-15 developers on the team.

I might have few of them but the testers do test. They contribute:

• Testing voice in Three Amigos discussion
• Exploratory testing
• Testing bits that are hard to automate

Manual testers contribute the Testing voice to the three Amigos meeting. What they add is ways to break the system, i.e. unhappy scenarios. However their main testing contribution is on the bits that can’t be automated or that haven’t been thought of (exploratory testing).

Product Owner Responsibilities for Testing

The last of the Three Amigos is the business representative, i.e. the product owner. They contribute:

• Business voice in Three Amigos discussion
• More or less formal reviews
• User Acceptance

The product owner, not surprisingly, articulates the business requirements in business language. I then orchestrate different opportunities for the product owner to review the product as it evolves. This includes the formal scheduled product demonstrations. It also includes looking over the shoulder of a developer and having a chat about what the developer is working on (chaperoned if necessary).

Towards the end of the process the product owner is also responsible for accepting the software into use (user acceptance testing). They might delegate some of that to a group of users.

Business Analyst Responsibilities for Testing

The product owner explains the business requirements in business language but somebody else turns those requirements into Gherkin scenarios. On my teams I support the product owner with one or more business analysts. They pick up some of the a day to day responsibilities. The business analyst often translates between the business and technical folk including writing the Gherkin scenarios. They are also responsible for checking on progress, peeking over the shoulder of developers to see if the functionality is headed in the right direction. And doing a double check when the developer says “I’m done”. This is a quick way to to evaluate whether that functional warrants releasing in the pipeline to live.

Notes:
(1) “Three Amigos” is how Matt Wynne describes the meeting to discuss the Gherkin scenarios before development starts. It involves the business, development and testing voices. On my current team this has turned into the “Four Amigos”: BA (for product owner), developer, tester, and UX designer.

This post is part of a series on Specification by Example.