Application under test included
QA Lab ships with the system you are validating: web UI, backend API, PostgreSQL, RabbitMQ, worker flow, control plane, and observability stack.
Local-First QA Lab
Experimental
A serious QA sandbox with enough moving parts to earn the name.
QA Lab is a local-first QA, observability, and distributed-systems monorepo with a full application under test, multiple automation lanes, persistent execution history, and a very clear opinion about runtime orchestration.
A complete app under test, not a toy endpoint and a motivational README
Selenium, Playwright, pytest, distributed validation, and observability in one lab
Local-first runtime with Kubernetes as the serious path and Compose as the practical one
Monorepo Shape
web/api/backend
web/ui/web-app
control-plane
tests/api
tests/ui/selenium
tests/playwright
tests/distributed
observability/prometheus
observability/grafana
infra/k8s
infra/compose
infra/terraformWhy It Matters
More than tests. It is the whole proving ground.
QA Lab is built around a stronger premise than “here is a test folder.” It gives the test stack an actual world to exercise: application flows, persistence, messaging, metrics, dashboards, and operator controls.
Multiple automation lanes
This is not a one-framework shrine. The lab deliberately keeps Selenium, Behave, pytest, and Playwright side by side so different test strategies can coexist and be compared.
Runtime strategy with range
Kubernetes is the formal orchestrator, Compose stays for bring-up and debugging, and AWS remains an optional infrastructure path instead of the project identity.
Runtime Strategy
Kubernetes is the formal answer. Compose is the practical friend.
- 1
Local-first on a dedicated Linux host with k3s
- 2
Full-power Docker Compose for fast bring-up and debugging
- 3
Optional AWS deployment while keeping the same overall runtime shape
Observability and control stay in the same conversation
PrometheusGrafanaPostgreSQL metricsRabbitMQ metricsWorker metricsPersistent QA execution history
The lab treats execution history, environment signals, and test visibility as first-class parts of QA instead of postscript accessories.
Test Lanes
Different strategies. Same lab.
UI automation with Selenium + Behave + Page Objects
API testing with pytest
UI and API coverage with Playwright
Distributed-systems validation from the outside
Future-ready voice and mobile lanes
Distributed Lane
RabbitMQ and worker flow belong to the system under test.
One of the strongest ideas in the repo is boundary discipline: the messaging stack lives in the application domain, while the distributed tests validate it from the outside. That keeps the lab honest about what is product behavior and what is test behavior.
Read the full monorepoPositioning
Built for teams who want QA to look less like an afterthought and more like an operational system.
QA Lab is experimental, but not unserious. It is a working argument that validation, runtime architecture, and observability should live in the same design conversation.