Know what your tests are missing.

How to do it yourself

First, choose a journey that matters to the business. It might be approving a laboratory result, completing an order, or recording a production step. Write down the starting conditions, the expected result, and the consequences of getting it wrong. Include a rejected or interrupted operation as well as the successful case.

Next, follow that journey through the existing tests. Note which business rules, interfaces, and screens are checked. Read the assertions: a test that reaches a page may never verify that the correct record was saved. A simple table linking expected behavior to a test or a manual check makes gaps visible.

Then examine recent failures. Compare escaped defects with the tests that were supposed to catch them. Run the relevant checks more than once using controlled data, and investigate inconsistent results. Separate a product defect from an unreliable test environment so the team knows what actually needs attention.

Now rank the gaps by their consequences, likelihood, and detectability. An untested calculation or permission boundary may deserve attention before a cosmetic edge case. Give each finding a reproducible example and a concrete next action, such as adding a rule-level test or making test data repeatable.

Finally, review the findings with someone who owns the workflow. Agree which gaps matter for the next release and which can wait. Keep the resulting coverage map, examples, and priorities together. They are the starting point for improvement; a single coverage percentage cannot explain that whole picture.

How we approach the work

Our plan draws on testing and architecture work around .NET applications, scientific software, and industrial workflows. We start with the behavior people rely on, then inspect how the code and tests represent it. Domain knowledge helps us distinguish an inconvenient defect from a failure that invalidates a result or disrupts an operation.

We combine repository review, selected test execution, and conversations with the team. Each finding connects an observed gap to its business effect and a proposed correction. The audit ends with a prioritized plan and a walkthrough, so your team can choose the next investment with evidence in front of them.

The tools behind the work

For a .NET system, xUnit or the existing test framework lets us examine business rules and service behavior. Playwright helps exercise browser journeys and inspect failures. We also read build results and application logs. The exact selection follows the application and the tests your team already maintains.

We use SDD, Specs Driven Development, to connect the expected behavior to specifications, test cases, and findings. For this audit, that means being able to trace a missing check back to the requirement it should protect, and follow the resulting issue through review.

Explore the tools

• SDD · Specs Driven Development ↗
• .NET testing ↗
• Playwright ↗