Hawzu
Test management for QA teams.
Hawzu is built around the question every release meeting asks: are we ready to ship? Most test management tools are good at storing test cases. Hawzu tries to answer that question: it connects test runs, coverage, defects and risk, so the evidence is already in one place when someone has to decide.
Later work followed from the same idea. Once the evidence is connected, people want to ask questions of it. So there is now Ask Oracle, which answers plain-English questions about a project, and a read-only connection that lets an AI assistant in a code editor ask the same things, with the same permissions as the person using it.
What I built
All of it, on my own.
Backend: a FastAPI service on MongoDB, with Redis as a cache. It serves the web app, a public API for test automation, and the read-only AI connection.
Search and AI: answers and generated test cases can cite the product docs and a customer’s own specifications, using search that combines meaning and keywords. Each customer’s documents are only ever searched for that customer.
Frontend: a React web app on Mantine, plus three static Astro sites (marketing, docs and blog) that are released separately from the app.
Integrations: Jenkins, GitHub Actions and GitLab CI. Builds can be started from Hawzu, and their results come back as test runs, matched to their test cases.
Decisions worth writing down
Test runs are the core record
Most tools treat the test case as the main thing and runs as history attached to it. Hawzu does it the other way round: a test run is the main record, and the test case is what was run. Coverage, defects and requirements all link to runs, which is what makes “is this release ready?” something the product can answer rather than something a person assembles by hand.
Trade-off
The few views that are really about test cases, like “where is this case used?”, are the awkward ones. That trade is worth it because the release question gets asked far more often.
Freeze the evidence at sign-off
Release reports used to change after the fact. Link a defect to a finished release and last month’s numbers moved.
Locking defects wasn’t the answer: a bug found in production after sign-off still belongs to that release, and its status keeps changing. What shouldn’t change is the evidence the decision was based on. So when a release is completed, its runs and test cases become read-only, and its defect figures are saved as a snapshot taken at that moment.
Trade-off
Every report has to know whether it’s showing live figures or the snapshot, and the screen has to say which.
The AI reads the question, nothing more
Ask Oracle lets people ask questions about a project in plain English. Underneath, a predictable query engine does the actual work, and it’s free to run. The AI’s only job is to turn the question into a query that engine understands, and it can only refer to fields that exist and that the person is allowed to see.
The AI can still misunderstand a question and produce a confident, wrong answer. That can’t be designed out, so every answer shows how the question was understood, as statements the person can edit. Fixing one re-runs the engine without asking the AI again. I wrote more about this in One Shot at Understanding.
No access means a refusal, not an empty list
AI assistants can read Hawzu through a read-only connection. When someone asks for something they aren’t allowed to see, the assistant gets a clear refusal. Returning an empty list would be simpler, but the assistant would then tell the person “there are none”, and present a permissions problem as a fact.
Over a limit, existing work keeps going
When a workspace goes over its plan’s limits, nobody loses access to work that already exists. Everyone can still read, run and edit. What stops is growth: new members, new projects, uploads past the quota. Making the workspace read-only would stop a QA team mid-release over a billing problem, and a hard cap would lock people out of their own test cases.
Trade-off
“Over the limit” became a state the product has to show honestly, not a number quietly capped at the maximum.
Fewer moving parts to run
Background jobs started on a separate queue service and moved into the database the product already uses. Redis stayed as a cache, and the product keeps working without it, just more slowly. For one person running everything, each service that can be removed is one less thing to watch.
Where it is now
Live at hawzu.com, with a free plan. The paid plans differ mainly by how much you use, not by which features you get.
Shipped recently:
- A Chrome extension that records a test as you click through a web app and turns it into test steps.
- Importing test cases from spreadsheets, TestRail, Zephyr and Qase, with images and attachments brought across.
- The read-only connection for AI assistants described above.
- Builds from Jenkins, GitHub Actions and GitLab CI arriving as test runs. Results that can’t be matched to a test case are kept aside, so they never turn into coverage nobody ran.
Next: fewer new features for a while. The work now is getting Hawzu in front of QA teams and fixing whatever they run into first.