Day 15 of Learning Testing: Collaboration-Based Test Approaches

Welcome back to Day 15 of my software testing journey!

Over the last few weeks, we have covered a lot of techniques — Black-Box, White-Box, and Experience-based testing. While all of those techniques have one primary goal (finding defects in the software), today we are looking at a completely different approach.

What if we could prevent defects from being coded in the first place?

Today, we are looking at Collaboration-based Test Approaches. This is all about defect avoidance through communication. We will explore how testers, developers, and business stakeholders work together to write User Stories, define Acceptance Criteria, and use Acceptance Test-Driven Development (ATDD) to test software before it even exists!

1. Collaborative User Story Writing

In modern software development (especially Agile), requirements aren’t handed down in massive 200-page documents. Instead, we use User Stories.

A user story represents a specific feature that provides value to the user or purchaser of the system. To write a great user story, teams rely on the “3 C’s”:

1. Card: The physical medium describing the story (like an index card or a digital Jira ticket).
2. Conversation: The discussion that explains exactly how the software will be used.
3. Confirmation: The acceptance criteria that prove the story is actually finished.

The Standard Format Most user stories follow a very simple, fill-in-the-blank format:

“As a [role], I want [goal to be accomplished], so that I can [resulting business value].”

By using techniques like brainstorming and mind-mapping, the team collaboratively authors these stories. This guarantees that the business, development, and testing teams all share the exact same vision of what needs to be built.

The INVEST Rule How do you know if a user story is actually good? It should be INVEST-ed:

• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable

A quick QA tip: If a stakeholder doesn’t know how to test a user story, it is a massive red flag. It usually means the story isn’t clear enough, it doesn’t offer real value, or the stakeholder simply needs the QA team’s help to define it!

2. Acceptance Criteria

Acceptance criteria are the specific conditions that the software must meet to be accepted by the stakeholders. You can think of them as the test conditions that QA will eventually verify.

These criteria are born out of the Conversation phase of the 3 C’s, and they serve several vital purposes:

• They define the strict scope of the user story.
• They help the team reach a consensus.
• They describe both positive scenarios (what should happen) and negative scenarios (what shouldn’t happen).
• They allow for accurate project planning and time estimation.

How to Write Them While a team can use any custom format as long as it is unambiguous, there are two industry standards:

1. Scenario-oriented: This uses the Behavior-Driven Development (BDD) format we learned about in Day 5: Given / When / Then.
2. Rule-oriented: This is a simple bullet-point verification list or a table of inputs and expected outputs.

3. Acceptance Test-Driven Development (ATDD)

We have our user stories and our acceptance criteria. Now, how do we test them? We use ATDD.

ATDD is a test-first approach. This means test cases are created prior to implementing the user story.

The ATDD Process:

1. The Specification Workshop: The developers, testers, and customers meet to analyze the user story. Any incompleteness, ambiguities, or defects in the logic are resolved right here, before any code is written.
2. Creating the Tests: The team (or the tester individually) creates test cases based strictly on the acceptance criteria. Because these tests act as real-world examples of how the software should work, the terms “examples” and “tests” are often used interchangeably here.
3. Execution: Typically, the team starts by writing positive test cases (confirming the “happy path” where everything goes right). Next, they write negative test cases (testing exceptions and errors). Finally, they cover non-functional characteristics (like performance or usability).

The Golden Rules of ATDD Test Cases:

• They must be written in natural language so that non-technical stakeholders can understand them (usually including preconditions, inputs, and postconditions).
• They must cover all characteristics of the user story, but absolutely nothing beyond it.
• No two test cases should describe the exact same characteristic.

The most beautiful part of ATDD? When these natural-language tests are captured in a test automation framework, developers can write code to automatically pass them as they build the feature. Your acceptance tests essentially become executable requirements!

That wraps up Day 15! We have successfully learned how to step out of our testing silos and collaborate with developers and stakeholders to build quality directly into the product.

See you in the next article!