Why I built it
I wanted a set of everyday QA tools I could trust with real test material — requirement text, sample data, API documents — without wondering where that material ended up. A lot of QA tooling lives behind an account, or is vague about what happens to whatever you paste into it. I wanted to build something where the honest answer, for most of the tools, is that nothing leaves your machine at all, and where the exceptions to that are named rather than buried.
The test-design side interested me for a different reason: boundary values, equivalence partitions and pairwise combinations are well-established, checkable methods, and I wanted engines that implement them exactly, in a way you could verify by hand rather than take on trust.
How it works
The workbench is a set of individual tools rather than one monolithic application. Most of them are pure engines running in your browser: you describe a field, a set of inputs, a state machine or a specification, and the tool derives boundary values, partitions, pairwise combinations, decision-table rows or state-transition cases from what you gave it, entirely on your own machine.
A small, separate group of tools needs the network to do its job — checking the headers a live site returns, whether a URL is reachable, what a robots.txt or sitemap actually says, or testing a public endpoint. Those tools are marked as online, and the request they make is explicit and visible rather than incidental.
One tool sits between the two categories deliberately. It can parse an API specification and derive test cases from it entirely locally, but actually running a derived request against a live endpoint is a separate, explicit action that goes through the same network boundary as the other online tools — so parsing and execution are kept distinct rather than blurred into one mode.
Saved work in the workspace — the parts of your session you choose to keep rather than discard when you close the tab — is encrypted in the browser before it is stored, rather than held in the clear.
For developers: how the tools were verified
The engines were built against a fixed catalogue of test cases and checked two ways. The first is an ordinary implementation test suite, written alongside the code. The second, written later and deliberately kept separate, checks each engine against an independent authority for that method — brute-force enumeration for pairwise coverage rather than the engine's own coverage verifier, an independent breadth-first search for state-machine reachability, a hand-written parser for one of the supported data formats — on the reasoning that a test written by the same hand that wrote the code can only ever confirm what that code already does.
That second pass found real defects the first suite had missed, and the pattern in them is worth naming: the arithmetic in the engines held up well, but the tools occasionally described their own results inaccurately — reporting success where the underlying combinations were actually impossible to satisfy, for instance, or an analyser flagging ordinary, safe code as a problem worth stopping over. A QA tool that quietly misreports its own findings can cost a tester more time than it saves, which is why fixing what a tool says about itself was treated as seriously as fixing what it computes.
A further round of tests drove the actual rendered pages through simulated keystrokes and clicks rather than calling the underlying engines directly, and it found at least one case where a correct, already-tested guard in the engine was simply unreachable from the interface — a negative number typed into a numeric field was silently overwritten before the guard ever saw it. A passing engine test had given false confidence about a path no user could actually take, which is the reason both layers are now tested rather than just the one that is easier to test.
Where it may go
Every one of the 650 cases in the specification’s test catalogue is now mapped to a test that actually runs, so the next work is not coverage for its own sake. It is widening the set of format and specification edge cases the tools handle correctly, because that is where most of the real-world defects have turned up so far.
I am not planning to move the offline tools onto a server. Keeping them genuinely local is the property that makes the privacy claim checkable rather than promised, and I would rather add tools within that constraint than relax it for convenience.