Freelance project · SaaS
Know whether a release is safe before it reaches users
TestGuard is a QA and deployment monitoring dashboard that tracks test coverage, risk levels, release confidence and staging performance in one place. It is for engineering and QA teams who want safer, faster releases without reading raw test reports. I designed the product and built its front-end.
01The problem
Before a release, teams piece together test results, coverage reports and staging metrics from different tools. Each signal is useful on its own, but nobody has one view that says whether a build is safe to ship. The hard part was turning many technical signals into a decision people could trust.
Who it’s for
QA engineers
See which areas lack coverage and which tests fail or flake most often.
Engineering leads
Get a clear go or no-go view before each release.
Developers
Find the failing test or slow endpoint behind a warning without digging.
02The main flow
01
New build arrives
02
Tests and coverage update
03
Review release confidence
04
Drill into risky areas
05
Decide to ship
03Structure
Overview
Coverage
Risk
Staging
Settings
04Key decisions
Decision 01
A single release confidence level is easy to read but easy to distrust. If people can’t see why it dropped, they ignore it.
Considered
Show only a pass or fail badge for each build.
Chosen
I paired the confidence level with the signals that moved it most, each linked to its detail screen.
Why it works
People trust a score they can question. Showing the reasons turns the overview into a starting point for action, not a verdict.
Decision 02
A flat list of failing tests hides where the risk sits. A few failures in a core module matter more than many in minor screens.
Considered
A long sortable table of every test result as the main view.
Chosen
I grouped coverage and failures by module and showed a risk level for each area, with the test list one click below.
Why it works
Leads decide by area, not by test. The full table is still there for the person who has to fix it.
Decision 03
Tests can pass while staging gets slower, and that often shows up only after release.
Considered
A separate performance tab that nobody opens before shipping.
Chosen
I put staging response times and errors on the same overview as tests and coverage, compared with the previous build.
Why it works
A release decision needs both views at once. Keeping them together makes a slow build as visible as a failing one.
05What’s inside
One view of whether a build is ready, with the reasons beside it.
Coverage by module and over time, so gaps are easy to spot.
Areas with rising risk or flaky tests are flagged before release.
Response times and errors on staging, next to the test results.
Every build with its tests, coverage and confidence, ready to compare.
06How it was built
I designed it and wrote the code, so the design survived contact with reality.
Interface
Services
Data
Infrastructure
07Outcome
Delivered
What I learned
A score earns trust only when people can see what moved it.
Dashboards for engineers work best when each screen answers one question and the rest sits one click down.
Next step
Pick a time that suits you. You'll leave the call with a clear next step, whether we work together or not.
