Collaboration-Based Test Approaches
Historically, software development was a game of telephone: business wrote a document, developers coded it, and testers found out what was broken weeks later. Collaboration-based approaches flip the script - bringing testers, developers, and business together before any code is written.
~10 min read
The core ideas, explained
Collaborative Writing of User Stories
A User Story represents a small piece of business value, and writing them collaboratively ensures all perspectives are covered. The golden rule is the 3 C's: the Card (a placeholder, usually "As a [role], I want [feature], so that [value]"), the Conversation (the most important part - the discussion between the Three Amigos: Business Analyst, Developer, and Tester, that fleshes out details and edge cases), and Confirmation (the acceptance criteria and tests that prove the story works). To be effective, stories should follow the INVEST principle: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
Story: "As a user, I want a new database architecture so the app is better." This fails because it isn't Valuable to the end-user (they don't care about databases), and it's likely not Small either.
Acceptance Criteria
Acceptance Criteria (AC) are the conditions a software product must satisfy to be accepted by a user, customer, or other stakeholder - they define the boundaries of a User Story. They can be rule-oriented (a simple bulleted list of rules) or scenario-oriented (written as specific usage flows, often paving the way for BDD).
For a password reset story: AC1 - password must be 8 characters. AC2 - must contain a number. AC3 - link expires in 24 hours.
Scenario: user enters an expired link. The system displays "Link Expired" and shows a "Resend" button.
Acceptance Test-Driven Development (ATDD)
In Acceptance Test-Driven Development, the team writes the acceptance tests before writing the code. The Three Amigos meet, look at the Acceptance Criteria, and collaboratively translate those criteria into executable tests - the developer then writes just enough code to make those tests pass. This prevents developers from writing code based on assumptions, acting as a massive Shift-Left technique that catches misunderstandings during the requirements phase.
Before coding a discount feature, the team writes a test: "Input $100 cart, input 'VIP' code -> expect $80 total." The developer now has a concrete, mathematical target to code against.
Behavior-Driven Development (BDD)
Behavior-Driven Development is an evolution of ATDD, focused on defining system behavior using a Ubiquitous Language - a shared vocabulary that business people, developers, and testers all understand identically. It strictly uses Given/When/Then syntax (often via Gherkin): Given the initial state or setup, When the action the user takes, Then the expected outcome. These scenarios are often hooked up to automation tools like Cucumber, turning requirements directly into automated tests - a form of "Living Documentation."
Given the customer's account balance is $100
And the ATM has enough cash
When the customer requests $20
Then the ATM should dispense $20
And the account balance should be $80This scenario reads like plain English but can be wired directly to automation - if the ATM logic ever breaks this behavior, the scenario fails and the "documentation" turns red.
Key points to remember
- Three Amigos - the core collaboration triad: Business (what we want), Dev (how we build it), Tester (what could go wrong).
- The 3 C's: Card, Conversation, Confirmation - the Conversation is where the actual collaboration happens.
- INVEST defines a good user story - if a story isn't Testable, it's not a valid story.
- ATDD vs. BDD: ATDD focuses on defining acceptance tests first; BDD focuses on defining behavior using Given/When/Then.
- Shift-Left - all collaboration-based approaches are designed to prevent defects in the requirements phase.
Terminology
A few terms from this topic worth knowing precisely.
The collaboration triad of Business (what we want), Development (how we build it), and Testing (what could go wrong) meeting together before code is written.
The Card is the placeholder statement for a user story; the Conversation is the collaborative discussion that fleshes out details; Confirmation is the acceptance criteria and tests that prove it works.
A checklist for a good user story: Independent, Negotiable, Valuable, Estimable, Small, and Testable.
The conditions a software product must satisfy to be accepted by a user, customer, or other stakeholder, written as either a rule-oriented list or scenario-oriented flows.
The whole team - business, dev, and test - collaboratively writes acceptance tests before development starts, and code is written to satisfy them.
Expressing expected behavior in a natural-language format anyone can read, typically structured as Given/When/Then.
A shared, standardized vocabulary used by business, development, and testing roles alike, so the same term means exactly the same thing to everyone on the team.
The practice of moving testing activities as early as possible in the SDLC, so defects are caught and prevented before they're built further into the system.
Summary
Collaboration-based approaches destroy the old "siloed" way of making software. By forcing Business, Development, and QA into the same room (Three Amigos) to write User Stories, teams rely on Conversations rather than massive documents. By writing Acceptance Criteria and using frameworks like ATDD and BDD (Given/When/Then), the team defines exactly how the software will be tested before it is coded, drastically reducing rework and building a shared ubiquitous language.
| Concept | One-line memory hook |
|---|---|
| Three Amigos | Business, Dev, and QA collaborating together |
| 3 C's of User Stories | Card (placeholder), Conversation (details), Confirmation (tests) |
| INVEST | The checklist for a perfect User Story |
| Acceptance Criteria | The exact rules a story must meet to be considered "Done" |
| ATDD | Team writes the tests first, then the developer codes to pass them |
| BDD (Behavior-Driven) | Given (Setup) / When (Action) / Then (Outcome) |
Check your understanding
20 questions, easy to hard - click an option to see if you got it right.