We have our cultural foundation Essential Steps for Creating a Robust Software Quality Foundation - Culture, Roles & Mindset and our architectural blueprints Proactive Strategies for Pre-Development Success - Requirements, Stories & Planning. Now, it's time to pick up the tools and start building. Welcome to the construction site.
Phase 3: In-Development Quality is all about the practices that happen during a sprint. This isn't a phase that happens at the end. Instead it's the engine room of quality, running continuously. The core principles here are fast feedback loops and deep collaboration. These are the activities that ensure quality is built directly into the product as it's being assembled.
A Fast and Reliable Continuous Integration (CI) Pipeline
WHAT it is: A CI pipeline is an automated process, triggered on every code change, that builds the software and runs a suite of automated tests to ensure the change didn't break anything. It's the team's first line of defense.
WHY it matters: The value of a CI pipeline is directly tied to its speed and reliability.
Slow Feedback Kills Momentum: If a developer has to wait 30 minutes for feedback, they've already moved on to another task. When the failure notification finally arrives, they've lost all mental context, making the fix five times harder. A fast pipeline (under 10 minutes) provides immediate feedback while the code is still fresh in their mind.
Flaky Tests Destroy Trust: A flaky pipeline that fails randomly is worse than no pipeline at all. When the team can't trust the results, they start ignoring failures. This completely defeats the purpose of having an automated safety net.
HOW to achieve it:
Parallelize your tests: Run different suites of tests simultaneously to drastically cut down execution time.
Optimize your build: Use caching for dependencies so you aren't downloading the internet on every run.
Enforce a zero-tolerance flaky test policy: If a test is flaky, it's a bug. Immediately quarantine it or fix it.
Enforced Code Quality Standards & Static Analysis
WHAT it is: Using automated tools, known as linters (like ESLint for JavaScript), to automatically scan code for stylistic errors, potential bugs, and adherence to team-defined standards.
WHY it matters: This is about cognitive load. Humans are slow, inconsistent, and error-prone when performing repetitive, detail-oriented tasks like checking for correct indentation or unused variables. Offloading this work to a machine frees up precious human brainpower during code reviews to focus on what truly matters: the logic, the architecture, and the user experience.
HOW to do it:
Integrate into the editor: Configure the linter to run directly in every developer's code editor, providing instant, private feedback as they type.
Make it a required check: Enforce the standards by making the linting step a mandatory pass/fail check before every commit. This ensures no non-compliant code ever makes it into the repository.
Mandatory, Effective Peer Reviews (Pull Requests)
WHAT it is: The practice where at least one other team member must thoughtfully review and approve a developer's code changes before they can be merged into the main codebase.
WHY it matters: While finding bugs is a benefit, the primary goal of a code review is knowledge sharing. It's the single most effective way to spread context throughout the team, prevent knowledge silos, improve code consistency, and collectively elevate the team's skills.
HOW to make them effective: The tone and focus of the comments are everything. A good review is a dialogue, not a judgment.
❌ Bad Comment: "This is inefficient. Use a hash map." (A command)
✅ Good Comment: "This is an interesting approach. I'm wondering if a hash map might be more performant here for the lookup. What are your thoughts on that?" (A collaborative question)
In-Sprint Dev-QA Collaboration & Pairing
WHAT it is: Direct, real-time collaboration between developers and QAs throughout the lifecycle of a feature, most powerfully realized through pair-testing sessions.
WHY it matters: This practice demolishes the "us vs. them" wall. It creates a tight, immediate feedback loop that resolves ambiguities in minutes instead of days. It fosters a powerful sense of shared ownership over the quality of the feature.
HOW to do it: The pair-testing session is the key ritual.
Schedule a short meeting: Book a 15-minute session once the developer has a working version of the feature.
Dev demonstrates: The developer shares their screen and explains what they built and how it's implemented. This is a mini knowledge-transfer session.
Test together: Both the dev and QA perform a few key tests together, discussing the results in real-time.
Handoff: This session brings instant clarity and serves as the perfect handoff. The QA can then take over to perform deeper, more comprehensive exploratory testing, already armed with full context.
Early and Continuous Exploratory Testing
WHAT it is: A creative, unscripted, and human-driven approach to testing. It's a "tour" of the feature where the tester uses their knowledge, curiosity, and intuition to discover how the software actually behaves. It’s about investigation and learning, not just script execution.
WHY it matters: Automation is excellent at verifying that the software does what you expect. Exploratory testing is essential for discovering what the software does when you do something unexpected. It allows you to feel the application, uncovering usability flaws, confusing workflows, and complex state-related bugs that automation will always miss.
HOW to do it:
Start early: As soon as a piece of functionality is available, start exploring it.
Use charters: Give your testing a mission. Instead of just randomly clicking, create a goal like, "Investigate how the application handles a user losing their network connection while updating their profile."
Definition of "Ready for QA/Review"
WHAT it is: A simple checklist, formally part of the team's Definition of Done (DoD), that confirms a piece of work is truly ready for deeper testing and review.
WHY it matters: This checklist prevents the frustrating "ping-pong" where a ticket is passed back and forth because of missing information, a broken build, or unmet requirements. It creates a smooth, efficient, and respectful handoff process.
HOW to implement it: This checklist is the final gate before the pair-testing session. It should live as a template in your tickets or pull requests and include items like:
✅ All Acceptance Criteria have been implemented.
✅ The CI pipeline is green.
✅ The feature is deployed to the shared testing environment.
✅ A 15-minute pair-testing session has been scheduled.
Conclusion: The Engine of Quality
Phase 3 is the engine room where the blueprints from Phase 2 become a tangible, working product. Powered by the fast feedback of CI and the deep collaboration of pairing and code reviews, these in-sprint practices are what transform a plan into high-quality, functional software.
Now that we've built the feature with quality baked in, it's time to validate our confidence at scale. In the next article, we'll dive into Phase 4: Formal Testing & Automation, where we'll build the strategic, automated safety net that protects our product and our users.
