A tool can exit without producing trustworthy evidence.
Require valid native reports and preserve execution errors separately from findings. A zero exit code alone does not establish a successful scan.
← Selected work
QA systems & evidence
Quality Engineering Toolkit
Bringing link checking and automated accessibility testing into a shared reporting foundation that preserves the evidence behind each finding.
From execution to evidence
Conceptual architecture
- 01
Specialist engines
HTTP crawling and browser accessibility checks retain their own execution models.
- 02
Shared reporting
Adapters preserve findings, review items and errors in consistent JSON, HTML and CSV outputs.
- 03
Human review
Reports provide context for triage. A scan that failed to run must not be presented as a pass.
THE PROBLEM
What needed to change
Separate QA tools produce different outputs and failure signals. A useful integration needs consistent run history and reporting without discarding native evidence or presenting incomplete execution as assurance.
MY CONTRIBUTION
Connecting execution and evidence
My focus is the engineering approach: preserve useful specialist tools, make their findings comparable, and distinguish a failed scan from a clean result. The toolkit brings those decisions together in a local workflow, with a Command Center foundation under development.
ARCHITECTURE
How the pieces fit
- Project policies and versioned profiles define the permitted scope.
- Explicit adapters connect the link crawler and Playwright/axe accessibility scanner.
- SQLite stores run history and ordered events; immutable artifacts preserve native and normalized reports.
- A supervisor handles lifecycle events; production execution remains gated on validated Linux containment.
ENGINEERING DECISIONS
Constraints and solutions
A shared report can erase important differences between tools.
Retain native severity, evidence, and review items alongside common JSON, HTML, and CSV outputs.
Process supervision is not sufficient isolation for a hosted scanner.
Keep Command Center execution disabled until the Linux container boundary and network/resource restrictions are implemented and validated.
RESULTS
What the work delivers
- Integrated two existing engines into a local reporting workflow.
- Implemented a Command Center foundation for policies, durable history, adapters, and evidence storage.
- Implemented supervisor cancellation, deadlines, recovery, and bounded logging; production containment remains unfinished.
Recorded project checks cover local fixture scans, native-report parity, failure handling, persistence, and supervisor behavior. These are scoped development results, not a current public-site audit or proof of Linux isolation.
A report that distinguishes failure
Illustrative, sanitized report excerpt. These fictional paths demonstrate status meaning; they are not measured scan results.
- /example/product — Finding
- A broken destination was observed. Retain the referring page for investigation.
- /example/checkout — Execution error
- The target could not be evaluated. Do not label the run a pass.
- /example/help — Manual review
- Automated evidence needs human judgment before a conclusion.
ACCESSIBILITY
Where human evaluation matters
Automated axe findings support accessibility investigation; they do not establish WCAG conformance. Manual review remains necessary. The future dashboard has not been built or accessibility-validated.