Web portal for quality assurance that serves the test strategy — the typologies and topologies with the tooling each one needs, the writing guidelines, and the campaigns that run them. For test managers, testers, and everyone else accountable for quality, which is everyone.
Following the same monorepo-of-standalone-modules convention as dev-hub, api-hub and arch-hub: each component stands alone, with its own chart.
| Component | What it is |
|---|---|
qa-portal/ |
The web frontend. Astro 7, server-rendered, Starlight for /doc/*. |
helm/ |
One chart per component. helm/qa-portal/deploy.sh puts it on a local cluster. |
./helm/qa-portal/deploy.sh
open http://qa-hub.localhostThe release lands in the qa-hub namespace and answers on two ingress hosts:
qa-hub.localhost, the address to open, and qa-portal.localhost, which keeps
the <component>.localhost convention the sibling hubs follow. See
helm/README.md.
Quality-driven software development matters. Quality is not a phase between the code and the release; it is the property that decides what the next change costs. A team that discovers quality at the end has already paid for it at the beginning, at a worse rate.
Shift-left accountability matters. Not shift-left testing — moving the tests earlier without moving the accountability only relocates the bottleneck and renames the queue. The person who can prevent a defect is the person who has to answer for it.
Testing in production is an option. A real one, with entry conditions. Some properties are only observable under real traffic, real data and real scale, and denying that buys a staging environment that lies convincingly. An option, not a default — the documentation says when it applies and what has to be true first.