Tambora is the QA management platform we built and maintain ourselves. It is where testing gets organized, documented, and tracked, and its test case assistant turns a written requirement into structured cases in minutes.
Most QA effort lives in spreadsheets and loose documents. That holds up until someone asks the one question that matters. What did we actually test before that release, and what did we not.
Tambora answers it. Cases are organized into modules and suites, executed against a release, and reported on. Coverage stops being a claim someone makes in a status meeting. It becomes a number attached to a named run.
It exists because we outgrew the alternative. As the delivery teams grew, so did the number of projects a single quality standard had to hold across, and general-purpose trackers gave us no structure to hold it with. So the internal product team designed, built, and tested Tambora for the two people who use it most: the engineer writing the cases and the manager who has to answer for them. It has since spread across the whole operations team.
We built it and we run it. AI has been in it for over a year. It is not a license we resell, and it is not a tracker with a chat box bolted on. It is what our own quality practice depends on.
Three figures, all measured against how we worked before it existed.
The test case assistant runs on our own agents, defaulting to the Claude API, with dynamic model selection so an engineer can switch the model mid-session to suit the work. You give it a requirement written in plain language. It returns structured cases: the happy path, the negative cases, and the edge cases that are the ones worth writing down. It fills in contextual test data as it goes, down to the card numbers a payments flow needs.
Nothing it produces is read-only. Every generated case is editable, categorized, prioritized, and linked to its Jira ticket before it is saved, which is the whole difference between a chat box and a tool.
Against our own before and after, it cuts test case design time by 50 to 75%. That is our figure, not an analyst's. It is also why the coverage bar on our engagements sits where it does. Thorough testing stopped being the first thing cut when a date moves, because it stopped being the expensive part.
The second piece matters most to engineers. Tambora runs its own MCP server. An engineer or designer can ask what the coverage is for a run, a tag, a severity, or an acceptance criterion, from inside their editor. No context switch. No asking someone in another channel.
Step 01
An engineer states what the feature is meant to do, in plain language, inside the module it belongs to.
Step 02
Positive, negative, and edge cases come back structured, with preconditions, steps, expected results, and contextual test data already filled in.
Step 03
Cases are edited, prioritized, assigned to a module, and linked to their Jira ticket. Judgment stays with the person who has it.
Step 04
Cases are stored, executed, and marked passed, failed, blocked, or retested against a named test run tied to a release.
Step 05
Coverage, execution progress, contribution, and history, per project and per release, without asking anyone to assemble it.
We didn't just want AI that outputs text. We needed usable test cases directly inside the system. That's what we built.
Cases organized by module and submodule, with suites and sub-suites for products too large to hold in one list.
Plan and execute everything QA needs to do before a release, so coverage of a feature is a fact attached to a run.
Built on our own agents, defaulting to the Claude API. A written requirement in, structured cases out.
The model is a setting, not an architecture decision. An engineer picks the one that suits the session, and sessions stream back over an event-driven channel rather than blocking on a reload.
Document a scenario once, then declare how many times it runs: per browser, per document type, per device, including combinations.
Coverage, execution progress, and contribution, per project rather than per anecdote.
Separate access for administrators, testers, engineers, and read-only users.
Cases and runs link to their tickets and epics, so traceability survives contact with the backlog.
A central home for operational records: accessibility conformance reports, release plans and protocols, transition plans.
Coverage exposed to the editor, so the question gets answered where the work is happening.
| Dimension | Before | With Tambora |
|---|---|---|
| Designing a test case | Hours of manual writing, per feature, by whoever had the context. | A requirement in plain language, structured cases back in seconds, 50 to 75% less design time. |
| Where cases live | Spreadsheets and documents, named by whoever made them. | Modules, suites, and sub-suites, navigable on a product too large to hold in one list. |
| Test data | Invented on the spot, or copied from the last time. | Auto-filled from context, down to the card numbers a payments flow needs. |
| Answering "what did we test" | A recollection, assembled by hand ahead of the meeting. | A coverage figure attached to a named run, queryable by tag, severity, or acceptance criterion. |
| Where an engineer works | Tracker, spreadsheet, ticket, chat. Four tools, one question. | The editor. Tambora's MCP server answers coverage there. |
| Manager visibility | Ask each person, then total it up. | Coverage, execution progress, contribution, and history, per project. |
| Operational records | Scattered, and gone when the person who wrote them moves on. | Conformance reports, release protocols, and transition plans in one documents module. |
Cases link to tickets and execute against a named run. So the coverage figure at phase acceptance points at specific scenarios. When an acceptance criterion has nothing behind it, that shows up before the phase closes. Not after a customer finds it.
Handovers fail on undocumented knowledge. The documents module keeps accessibility conformance reports, release protocols, and transition plans in one place. The case library does something quieter and more useful. It describes, in readable form, how the product is meant to behave.
Tambora is internal tooling rather than something you license. What reaches you is the output: the coverage numbers, the traceability, and the records that make a handover survivable.
Two things are in progress. A master test plan that groups the cases and runs for a feature under one lifecycle, from draft through ready, in progress, completed, validating, and approved, so a feature can be traced from its specification to its final validation in one place.
The second is a knowledge library: an assistant trained on how we actually run quality here, so "how should we test a multi-tenant application" or "what belongs in a test plan for this feature" gets a Koombea answer rather than a generic one.
The documents module is already going the same way. It holds the operational records a delivery organization is judged on, including accessibility conformance reports, release plans and protocols, and transition plans, which is what makes it possible for someone to take leave without the engagement holding its breath.
Both follow the same direction of travel. Tambora started as somewhere to keep test cases and is turning into the place quality strategy is decided.
A partner renting an off-the-shelf test tool is making a claim about testing. A partner that built its own, put AI into it over a year ago, and runs its client work on it is making a different one.
In 30 minutes, we will show you what a Pod would ship first and how we would price it.
