In part one of this article I explored QA best practices and I discussed how strong quality starts with the right foundations - through clear understanding of user stories, well-defined QA strategies, and practical test planning.
This part covers execution. Specifically, the test design techniques that produce the highest coverage per test, the traceability that keeps requirements and implementation aligned as scope moves, and a lightweight gap analysis method that catches mismatches before a single line of code is written. All of it comes from delivery work at Dreamix in regulated domains such as insurance and aviation, where a defect that reaches production carries an audit and compliance cost on top of the engineering one.
Drawing from hands-on experience at, particularly in complex regulated domains such as insurance and aviation, it becomes clear that having a strategy is only the first step. The real value comes from how that strategy is applied in practice - through effective test design, continuous alignment, and close collaboration across teams.
In this second part, we dive into how QA practices evolve during delivery, including:
- Designing robust and meaningful test cases:
- Maintaining traceability across requirements, tests, and defects
- Using lightweight gap analysis to uncover inconsistencies early
- Applying practical workflows and collaborative techniques (BDD, CI/CD, retrospectives)
- Measuring real impact through project outcomes and defect analysis
- These elements turn QA from a supporting role into a key driver of product quality, alignment, and continuous improvement.
By connecting structured practices with real project results, this part illustrates how early QA involvement leads not only to better testing - but to better products and more reliable delivery overall.
Key Takeaways:
- Better test design leads to higher coverage with fewer tests
- Traceability prevents requirement drift
- Gap analysis reduces rework costs
- Early QA involvement improves delivery predictability
- Structured QA practices create measurable business value
1. Test design techniques that earn their keep
Test design converts requirements into test cases and test data. Good design covers functional and non-functional behaviour without inflating the test suite.
There are many catalogued techniques: equivalence partitioning, state transition testing, scenario-based testing, data-driven testing. In complex, business-critical systems, two consistently return the most value.
Boundary value analysis
Defects cluster at the edges. Boundary value analysis concentrates effort on minimum values, maximum values, and the values immediately inside and outside an accepted range.
Example: Boundary value analysis in data validation
In a feature involving numerical thresholds (e.g. limits, ranges, validations), we applied
Boundary Value Analysis. Instead of testing random values, we focused on critical edges (min, max, just inside/outside boundaries).
Impact:
- Identified edge-case defects early (before UAT or PROD)
- Reduced unnecessary test execution
Business Value:
- Up to 30% reduction in test execution effort
- Faster feedback cycle
- Lower risk of production issues at boundary conditions
Decision table testing
Example: Reducing complexity with decision tables
In one of our projects involving complex business rules (e.g. pricing and eligibility logic), we applied Decision Tables to structure test coverage.Instead of writing dozens of loosely connected test cases, we mapped all condition-outcome combinations in a single table and derived the minimal set of meaningful scenarios.
Impact:
- Reduced ~40-50% redundant test cases
- Prevented missed rule combinations that previously led to production defects
- Improved clarity for both QA and developers
Business value:
- Estimated ~20–30% reduction in test design time
- Faster onboarding for new team members (clear logic visualization)
- Reduced rework caused by misunderstood business rules
For business stakeholders, this means faster implementation of complex functionality, fewer production issues, and greater confidence that critical business rules are working as expected.
The rest of the toolkit
Exploratory testing covers what planning cannot predict. It relies on domain knowledge and tester judgement to surface unexpected behaviour, usability problems and edge cases outside the written scenarios.
API and contract testing validates service behaviour and data exchange early, before integration problems surface in the UI. In distributed architectures this is where the expensive defects hide.
Non-functional design brings performance, security and accessibility into scope at design time rather than at hardening. Late discovery of a performance ceiling is one of the most common causes of a missed release date.
2. Requirements traceability keeps intent and build aligned
Requirements move. Stories, designs, tests and implementation drift apart quietly, and the drift usually becomes visible at sign-off.
A requirements traceability matrix maps story or requirement IDs to the tests, designs and defects attached to them. Gaps become visible instead of theoretical. Three practices keep it cheap to maintain:
- Review the matrix at milestones rather than continuously, in short sessions.
- Link every defect back to its requirement, which makes impact and priority obvious.
- Keep it in the tools already in use (issue tracker, test management system) rather than in a parallel document.
Example: Preventing scope drift with traceability
By maintaining traceability between requirements → test cases → defects, we identified missing coverage for a newly introduced requirement.
Impact:
- Prevented incomplete testing before release
- Improved confidence during sign-off
Business Value:
- Reduced risk of escaped defects
- Faster regression cycles (clear mapping)
- Improved auditability and stakeholder trust
From a delivery perspective, traceability helps teams adapt to changing requirements without losing visibility of coverage and release readiness.
3. Gap analysis with a one-page gap log
Refinement sessions move fast, and heavy documentation slows them down. What teams need in the room is a quick, visual way to compare what was asked for against what is being built.
I use a simple gap log: a lightweight template that captures mismatches between requirements, stories, designs and implementation without over-engineering the process. It does not replace specifications or test cases. It makes disagreement visible in the session, while everyone is still in the room.
It works best in refinement meetings, design reviews, story rework sessions, and late alignment checks before release.
Colour coding keeps the log scannable during a live session: yellow for an open gap, green for resolved and aligned.
To make the log easy to scan during live sessions, I use color coding:
🟡 Yellow - A gap exists, something is wrong or unclear
🟢 Green - The gap is resolved and everything is aligned
The strength of this gap log is its simplicity. It doesn’t try to document everything - only what matters right now to get the feature aligned and done correctly. Sometimes clarity doesn’t come from more documentation, but from asking the right questions in the right format.
Example: Catching gaps before development
During a refinement session, we used a lightweight Gap Log to compare story vs design vs expected final behavior.
We identified a mismatch in how user roles should behave - something that was not clearly defined in the acceptance criteria.
Impact:
- Prevented incorrect implementation before development started
- Avoided rework across frontend and backend
Business Value:
- Saved approximately 2–3 developer days
- Prevented a potential production defect affecting multiple user roles
- Reduced back-and-forth communication during sprint execution
4. A test case structure that scales
A consistent structure keeps test cases readable, traceable and usable by both manual testers and automation engineers.
Test case template
- Preconditions
- Test steps
- Expected results
- Test data
- Acceptance criteria mapping
The last line is the one teams skip and the one that matters most. Mapping each case back to acceptance criteria is what makes coverage measurable rather than assumed. A good test case is defined by clarity and intent, and excessive detail slows execution without improving either.
How the QA team works around all the test design techniques
Techniques and artifacts only pay off inside a working style that lets QA influence quality early.
- Engage before development starts. Reviewing stories, joining refinement and co-writing acceptance criteria surfaces ambiguity while it is still cheap to fix.
- Use ATDD and BDD where they add value. Given/When/Then scenarios give product, design, development and QA one shared definition of expected behaviour, and they double as living documentation and an automation starting point.
- Balance automation and manual testing deliberately. Automation earns its place in regression, API and contract validation, repetitive high-risk flows and data-heavy checks. Manual testing stays essential for exploratory work, edge cases and usability judgement.
- Wire QA into CI/CD. Tests triggered on every build shorten the feedback loop. Flaky tests get stabilised rather than tolerated, and failures get investigated rather than filtered out.
- Keep artifacts light and shared. One source of truth, clear links between requirements, designs, tests and defects, minimal but meaningful documentation.
- Run a testing-focused retro after each release. Look at gaps found during testing, coverage that arrived late, and improvements in tooling or collaboration. Small changes compound across releases.
Example: Delivering measurable QA impact
In one of the projects in the insurance domain, we reviewed and analysed 170 defects reported during the project's first year to better understand where issues originated, how effectively they were being caught, and what impact early QA involvement had on overall delivery quality.
One of the most notable findings was that the majority of defects originated from functional issues and requirement gaps, highlighting the importance of early collaboration during refinement and requirement reviews. By actively participating in discussions with Product Owners and developers, QA was able to identify ambiguities and missing business rules before they progressed into larger delivery risks.
Results:
- Out of 170 analyzed defects, the majority were identified during development and QA phases rather than after release.
- Only 3 defects were categorized as regression issues, indicating that changes were introduced with minimal impact on existing functionality.
- Only 2 defects reached production, demonstrating the effectiveness of early testing,
- structured test design, and continuous validation throughout the project lifecycle.
- Defects were generally resolved faster because they were detected earlier, when the cost and complexity of fixes were significantly lower.
- Sprint deliveries became more predictable, with less rework and fewer unexpected issues near release dates.
Client Impact:
- Increased confidence in release readiness.
- Reduced need for production support and hotfix activities.
- Better visibility of risks and requirement gaps before implementation.
- Positive feedback regarding QA collaboration, communication, and overall product quality.
Explore next: Our full guide on outsourced software testing services by our QA Practice Lead Polina Ezekieva.
What changes when you apply these test design techniques
Teams that run structured test design, traceability and gap analysis together see a consistent pattern:
- Requirements, designs and implementation stay aligned, so less time goes into debating intent.
- Coverage improves by testing the right things rather than by adding test cases.
- Gaps get raised and resolved during refinement instead of surfacing as late surprises.
- Audits, impact analysis and regression cycles run faster because artifacts are linked.
- Releases become more predictable, with fewer critical defects reaching production.
In financial terms: shorter feedback loops, lower rework costs, fewer hotfixes, and a release schedule the business can plan around.
Quality becomes something the team builds continuously through alignment, collaboration and clarity. Verification at the end is the least effective and most expensive place to find out what went wrong.
Read next: A case study on how we automated bug reports with AI for a client
Conclusion
Execution is where quality is truly proven. It is shaped by the consistency of test design, the visibility provided by traceability, and the ability to identify and resolve gaps as early as possible.
When these practices are applied effectively, testing becomes more than verification - it becomes a way to continuously validate alignment between intent, design, and implementation. This reduces rework, strengthens coverage, and improves confidence in every release.
What stands out most is that quality is not driven by a single technique or tool, but by the combination of structure, collaboration, and continuous feedback.
Teams that embed these habits into their workflow don’t just catch issues earlier - they build systems that are more stable, more predictable, and better aligned with real user needs.
Ultimately, quality is not only an engineering concern. It is a business enabler that drives predictable delivery, reduces operational costs, and builds lasting customer trust. In the end, quality is not something tested into a product at the final stage. It is built continuously through collaboration, early feedback, and shared ownership across the entire delivery lifecycle. Teams that embrace this mindset do not simply find defects earlier, they deliver better products with greater confidence and predictability.
We’d love to hear about your software project and help you meet your business goals as soon as possible.
