In our previous article Essential Steps for Creating a Robust Software Quality Foundation - Culture, Roles & Mindset, we laid the cultural foundation for quality. We established that quality is a shared mindset, not just a department. But a strong foundation is useless without a solid plan. A nothing huge is built on hopes and good intentions. Instead it's built from a detailed architectural blueprint.
Welcome to Phase 2: Pre-Development. This is the architect's table.
This phase is about designing quality into your product from the very start. Every activity here is designed to prevent entire classes of bugs before a single line of code is written. This is where an hour of careful planning saves ten hours of painful debugging later. Let's dive into it.
Crafting High-Quality, Testable User Stories
WHAT it is: A high-quality user story clearly and concisely describes a feature from an end-user's perspective. It's not a technical task list, but a statement of user value.
WHY it matters: Vague stories are the root of most misunderstandings. They force developers and QAs to make assumptions, which leads to building the wrong thing, extensive rework, and features that completely miss the user's needs.
-
HOW to do it: You can use the standard BDD (Behavior Driven Development) style
As a [persona], I want [action], so that I can [achieve an outcome]format. This structure forces clarity. Now, compare a bad story to a good one:- ❌ Bad: "User login"
- ✅ Good: "As a registered user, I want to log in with my email and password so that I can access my account dashboard."
The second version is instantly testable and leaves no room for guessing who the user is or what the goal is. A good approach is to use the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) as a checklist for every story.
Defining Concrete Acceptance Criteria (ACs)
WHAT they are: Acceptance Criteria are a set of specific, binary (pass/fail) conditions that a user story must meet to be considered "done". They are the formal contract for the feature.
WHY they matter: The greatest strength of binary ACs is that they eliminate assumptions. When an AC is subjective ("The page should load fast"), it leads to arguments. When it's binary ("The page must load in under 2 seconds on a 4G connection"), it's a simple, verifiable fact. This robustness is key to shipping with confidence.
-
HOW to write them: Focus on clear, testable outcomes. While a format like Gherkin (
Given/When/Then) can be useful, the principle is more important than the syntax.- ❌ Bad: "The login process should be user-friendly." (Subjective)
- ✅ Good: "When the user enters an incorrect password, the error message 'Invalid credentials' is displayed." (Pass/Fail)
-
✅ Good: "Upon successful login, the user is redirected to the
/dashboardpage." (Pass/Fail)
Implementing "Three Amigos" Sessions
WHAT it is: A focused working session bringing together the three key perspectives: Product (what is the problem to solve?), Development (how can we build a solution?), and Quality (how could this solution break?).
WHY it matters: This session is the ultimate defense against ambiguity. It demolishes silos and ensures a shared understanding of the feature, its requirements, and its risks before the first line of code is written. It’s a high-leverage activity that prevents countless hours of wasted work.
-
HOW to run it:
- Keep it small: It's the "Three Amigos", not the "Thirty Amigos". Only the three core perspectives should be present.
- Have a strict agenda: Start with the initial user story requirements and ACs as a foundation. The goal is to brainstorm the story requirements and to set ACs foundation.
- Define responsibilities: The Product representative clarifies requirements, the Developer discusses implementation strategy, and the QA probes for edge cases and testability. The goal is to leave the session with crystal-clear, agreed-upon ACs.
Identifying Edge Cases & Negative Paths Upfront
WHAT it is: The practice of systematically thinking through what happens when things go wrong or when users behave unexpectedly (e.g., entering bad data, losing network, clicking things out of order). This is a critical activity for story grooming sessions.
WHY it matters: Thinking about negative paths is a core "shift-left" activity. Uncovering a major edge case in a 15-minute grooming session is infinitely cheaper and faster than discovering it through a production bug that impacts thousands of users. This is where a QA's mindset adds immense value.
-
HOW to do it: The QA should lead this by asking probing "What if...?" questions.
- "What if the user tries to register with an email address that already exists?"
- "What if the API call fails while they are submitting the form?"
- "What if the user's session times out while they have items in their cart?"
Defining and Integrating Non-Functional Requirements (NFRs)
WHAT they are: NFRs define how the system should operate, rather than what it should do. The most common examples are performance, security, and accessibility.
WHY it matters: Leaving NFRs until the end is a recipe for disaster. You can't "add" security or performance to a product after it's built. It has to be designed in. Thinking about NFRs while planning the functional story is crucial because you have the full context to make smart architectural decisions.
-
HOW to do it: NFRs can be tracked as their own stories, but they must be discussed alongside the related functional story. For example, while grooming a "File Upload" story, ask:
- Performance: "What is the maximum file size we need to support? What's the target upload time?"
- Security: "What file types are allowed? How will we scan for viruses?"
- Accessibility: "How will a screen reader announce the upload progress?"
Risk-Based Prioritization of Quality Efforts
WHAT it is: A strategy to focus your most intense testing efforts on the areas of the application that pose the greatest risk to the business and your users.
WHY it matters: You can't test everything with 100% depth, since it's not practical or economical. This approach ensures your limited time is spent where it matters most. It’s about being effective, not just busy.
-
HOW to do it: Use a simple Impact vs. Likelihood matrix to categorize features and guide your testing strategy.
- High Impact / High Likelihood (e.g., the main payment flow): This requires deep, rigorous testing, including end-to-end automation and extensive exploratory testing.
- High Impact / Low Likelihood (e.g., data restoration from a backup): This needs a clear test plan for key scenarios but doesn't require exhaustive daily testing.
- Low Impact / High Likelihood (e.g., a form validation error): This is a perfect candidate for lightweight, automated checks.
- Low Impact / Low Likelihood (e.g., updating a profile's bio): This can be covered sufficiently by quick exploratory testing.
Making Quality a Factor in Story Estimation
WHAT it is: The practice of including all quality-related activities (writing unit tests, developing automation test scripts, pair testing, exploratory testing, etc.) within the story point estimation for every user story.
WHY it matters: Testing is not a separate phase, It's part of the development work. Creating separate "testing tickets" breaks the "Whole Team" mentality and hides the true cost of delivering a feature. Including it in the estimate makes it clear that a story isn't "done" until it's "done and high-quality".
HOW to do it: During estimation, the team must explicitly discuss the effort required for quality. A developer might say a story is "3 points", and the QA can then ask, "Does that estimate include the time to write the new automated tests and for us to do a 30-minute exploratory session together?" This conversation ensures the full scope of work is accounted for.
Early Test Data & Environment Planning
WHAT it is: The strategic process of defining the specific data and infrastructure needed to properly test a feature, and doing so before development begins.
WHY it matters: "Blocked by test data" or "The test environment is broken" are two of the most common and frustrating bottlenecks in the development cycle. They are almost always preventable with upfront planning.
-
HOW to do it: Before a story is considered "ready for development", the team must be able to answer these questions:
- Data: What specific data states do we need? (e.g., A brand new user? A user with 1000+ orders? A user with an expired subscription? A user in a different country?)
- Environment: Does this feature depend on a new third-party service or a change in our infrastructure? If so, how will we make that available for testing?
Conclusion: From Foundation to Framework
Phase 2 transforms the cultural values from Phase 1 into a concrete plan of action. By focusing on clarity, collaboration, and risk mitigation before development, you build a sturdy framework that prevents defects and ensures you're building the right product, the right way.
With the blueprints now finalized, it's time to pick up the tools and start the construction. In our next article, we'll dive into Phase 3: In-Development Quality, where we'll explore the in-sprint practices that ensure quality is built in, not bolted on.
Top comments (0)