# Tambora > Tambora is the QA management platform Koombea built and maintains. Test case design from a written requirement, coverage per release, and an MCP server that answers coverage questions inside the editor. Source: https://www.koombea.com/products/tambora/ --- 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. ## What it is 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. - Modules and suites, with hierarchy, so a large product stays navigable - Cases documenting preconditions, steps, and expected results - Execution with real statuses, including passed, failed, blocked, and retested - Coverage and execution progress visible per project rather than per person's memory ## What it changed Three figures, all measured against how we worked before it existed. - Less time designing test cases: Measured against our own before and after, not an analyst's benchmark - From a written requirement to structured cases: The same work used to run to hours, so it was the first thing cut - Coverage attached to a named release: Rather than to somebody's recollection in a status meeting ## The part that changed the economics 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. - Structured cases generated from a requirement written in plain language - Positive, negative, and edge cases, with contextual test data filled in - Every case editable, categorized, and linked to a ticket before it is saved - 50 to 75% less time designing cases, measured against our own baseline - An MCP server that answers coverage questions inside the editor - Coverage queried by test run, tag, severity, or acceptance criterion ## From a requirement to an executed case Write the requirement: An engineer states what the feature is meant to do, in plain language, inside the module it belongs to. (Minutes, not a workshop) The assistant proposes cases: Positive, negative, and edge cases come back structured, with preconditions, steps, expected results, and contextual test data already filled in. (Seconds) The engineer decides: Cases are edited, prioritized, assigned to a module, and linked to their Jira ticket. Judgment stays with the person who has it. (The assistant proposes, it does not approve) Execute against a run: Cases are stored, executed, and marked passed, failed, blocked, or retested against a named test run tied to a release. (Coverage becomes a fact) Managers see the picture: Coverage, execution progress, contribution, and history, per project and per release, without asking anyone to assemble it. (Dashboards, not a status call) "We didn't just want AI that outputs text. We needed usable test cases directly inside the system. That's what we built." Felipe Guerrero, Director of Quality, Koombea ## What is in it - **Modules and suites**: Cases organized by module and submodule, with suites and sub-suites for products too large to hold in one list. - **Test Run**: Plan and execute everything QA needs to do before a release, so coverage of a feature is a fact attached to a run. - **Test case assistant**: Built on our own agents, defaulting to the Claude API. A written requirement in, structured cases out. - **Dynamic model selection**: 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. - **Iterators**: Document a scenario once, then declare how many times it runs: per browser, per document type, per device, including combinations. - **Metrics and dashboards**: Coverage, execution progress, and contribution, per project rather than per anecdote. - **Roles and permissions**: Separate access for administrators, testers, engineers, and read-only users. - **Jira integration**: Cases and runs link to their tickets and epics, so traceability survives contact with the backlog. - **Documents**: A central home for operational records: accessibility conformance reports, release plans and protocols, transition plans. - **Tambora MCP**: Coverage exposed to the editor, so the question gets answered where the work is happening. ## Before Tambora, and after it | | 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. | ## Why this matters on your engagement ### During the build — Coverage you can see, not coverage you are told about. 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. - Every acceptance criterion traceable to the scenarios that prove it - Coverage reported against a release, not as a general assurance - Gaps surfaced while there is still time to close them ### At handover — The record outlives the people who made 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. - Operational records kept where the next team will look for them - A test library that documents intended behavior, not just outcomes - Continuity when responsibility moves between teams 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. ## Where it is going 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. ## Quality runs on software we built 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.