Tambora es la plataforma de gestión de QA que construimos y mantenemos nosotros mismos. Es donde las pruebas se organizan, se documentan y se rastrean, y su asistente de casos de prueba convierte un requisito escrito en casos estructurados en minutos.
La mayor parte del esfuerzo de QA vive en hojas de cálculo y documentos sueltos. Eso aguanta hasta que alguien hace la única pregunta que importa. Qué probamos de verdad antes de esa versión, y qué no.
Tambora la responde. Los casos se organizan en módulos y suites, se ejecutan contra una versión, y se reportan. La cobertura deja de ser una afirmación que alguien hace en una reunión de estado. Se vuelve un número pegado a una corrida con nombre.
Existe porque le quedamos grandes a la alternativa. Mientras los equipos de entrega crecían, crecía también la cantidad de proyectos sobre los que un solo estándar de calidad tenía que sostenerse, y los gestores de propósito general no nos daban estructura para sostenerlo. Así que el equipo de producto interno diseñó, construyó y probó Tambora para las dos personas que más la usan: quien escribe los casos y quien tiene que responder por ellos. Desde entonces se extendió a todo el equipo de operaciones.
La construimos y la operamos. La IA lleva más de un año dentro. No es una licencia que revendemos, y no es un gestor con un chat pegado encima. Es aquello de lo que depende nuestra propia práctica de calidad.
Tres cifras, todas medidas contra cómo trabajábamos antes de que existiera.
El asistente de casos de prueba corre sobre nuestros propios agentes, con la API de Claude por defecto, y con selección dinámica de modelo para que alguien de ingeniería pueda cambiar el modelo a mitad de sesión según el trabajo. Le das un requisito escrito en lenguaje simple. Devuelve casos estructurados: el camino feliz, los casos negativos, y los casos borde, que son los que vale la pena escribir. Llena los datos de prueba contextuales sobre la marcha, hasta los números de tarjeta que necesita un flujo de pagos.
Nada de lo que produce es de solo lectura. Cada caso generado es editable, categorizado, priorizado y ligado a su ticket de Jira antes de guardarse, que es toda la diferencia entre un chat y una herramienta.
Contra nuestro propio antes y después, reduce el tiempo de diseño de casos de prueba entre 50 y 75%. Esa es nuestra cifra, no la de un analista. También es la razón por la que la barra de cobertura en nuestros proyectos está donde está. Probar a fondo dejó de ser lo primero que se corta cuando una fecha se mueve, porque dejó de ser la parte cara.
La segunda pieza le importa más a ingeniería. Tambora corre su propio servidor MCP. Alguien de ingeniería o de diseño puede preguntar cuál es la cobertura de una corrida, de una etiqueta, de una severidad o de un criterio de aceptación, desde dentro de su editor. Sin cambio de contexto. Sin preguntarle a alguien en otro canal.
Paso 01
Alguien de ingeniería declara qué se supone que hace la funcionalidad, en lenguaje simple, dentro del módulo al que pertenece.
Paso 02
Los casos positivos, negativos y borde vuelven estructurados, con precondiciones, pasos, resultados esperados y datos de prueba contextuales ya llenos.
Paso 03
Los casos se editan, se priorizan, se asignan a un módulo y se ligan a su ticket de Jira. El criterio se queda con quien lo tiene.
Paso 04
Los casos se guardan, se ejecutan y se marcan como pasó, falló, bloqueado o reprobado, contra una corrida con nombre atada a una versión.
Paso 05
Cobertura, avance de ejecución, contribución e historial, por proyecto y por versión, sin pedirle a nadie que lo arme.
No queríamos una IA que solo escupiera texto. Necesitábamos casos de prueba usables directamente dentro del sistema. Eso fue lo que construimos.
Casos organizados por módulo y submódulo, con suites y subsuites para productos demasiado grandes para caber en una sola lista.
Planear y ejecutar todo lo que QA tiene que hacer antes de una versión, para que la cobertura de una funcionalidad sea un hecho pegado a una corrida.
Construido sobre nuestros propios agentes, con la API de Claude por defecto. Entra un requisito escrito, salen casos estructurados.
El modelo es una configuración, no una decisión de arquitectura. Ingeniería escoge el que le sirve a la sesión, y las sesiones llegan en flujo por un canal de eventos en vez de bloquearse esperando una recarga.
Documentar un escenario una vez, y después declarar cuántas veces corre: por navegador, por tipo de documento, por dispositivo, incluyendo combinaciones.
Cobertura, avance de ejecución y contribución, por proyecto en vez de por anécdota.
Acceso separado para administradores, testers, ingeniería y usuarios de solo lectura.
Los casos y las corridas se ligan a sus tickets y épicas, así que la trazabilidad sobrevive el contacto con el backlog.
Una casa central para los registros operativos: reportes de conformidad de accesibilidad, planes y protocolos de versión, planes de transición.
La cobertura expuesta al editor, para que la pregunta se responda donde está pasando el trabajo.
| Dimension | Antes | Con Tambora |
|---|---|---|
| Diseñar un caso de prueba | Horas de escritura manual, por funcionalidad, a cargo de quien tuviera el contexto. | Un requisito en lenguaje simple, casos estructurados de vuelta en segundos, 50 a 75% menos tiempo de diseño. |
| Dónde viven los casos | Hojas de cálculo y documentos, nombrados por quien los hizo. | Módulos, suites y subsuites, navegables en un producto demasiado grande para una sola lista. |
| Datos de prueba | Inventados en el momento, o copiados de la última vez. | Llenados desde el contexto, hasta los números de tarjeta que necesita un flujo de pagos. |
| Responder "qué probamos" | Un recuerdo, armado a mano antes de la reunión. | Una cifra de cobertura pegada a una corrida con nombre, consultable por etiqueta, severidad o criterio de aceptación. |
| Dónde trabaja ingeniería | Gestor, hoja de cálculo, ticket, chat. Cuatro herramientas, una pregunta. | El editor. El servidor MCP de Tambora responde la cobertura ahí. |
| Visibilidad para los responsables | Preguntarle a cada persona, y después sumar. | Cobertura, avance de ejecución, contribución e historial, por proyecto. |
| Registros operativos | Dispersos, y perdidos cuando la persona que los escribió se va. | Reportes de conformidad, protocolos de versión y planes de transición en un solo módulo de documentos. |
Los casos se ligan a tickets y se ejecutan contra una corrida con nombre. Así la cifra de cobertura en la aceptación de fase apunta a escenarios específicos. Cuando un criterio de aceptación no tiene nada detrás, eso aparece antes de que cierre la fase. No después de que lo encuentre un cliente.
Las entregas fallan por conocimiento sin documentar. El módulo de documentos guarda los reportes de conformidad de accesibilidad, los protocolos de versión y los planes de transición en un solo lugar. La biblioteca de casos hace algo más silencioso y más útil. Describe, en forma legible, cómo se supone que el producto se comporta.
Tambora es herramienta interna y no algo que licencies. Lo que te llega es la salida: los números de cobertura, la trazabilidad, y los registros que hacen sobrevivible una entrega.
Hay dos cosas en curso. Un plan maestro de pruebas que agrupa los casos y las corridas de una funcionalidad bajo un solo ciclo de vida, de borrador a listo, en progreso, completado, en validación y aprobado, para que una funcionalidad se pueda trazar desde su especificación hasta su validación final en un solo lugar.
La segunda es una biblioteca de conocimiento: un asistente entrenado en cómo de verdad corremos calidad aquí, para que "cómo deberíamos probar una aplicación multiinquilino" o "qué va en un plan de pruebas para esta funcionalidad" reciba una respuesta de Koombea y no una genérica.
El módulo de documentos ya va por el mismo camino. Guarda los registros operativos por los que se juzga a una organización de entrega, incluyendo reportes de conformidad de accesibilidad, planes y protocolos de versión, y planes de transición, que es lo que hace posible que alguien se vaya de vacaciones sin que el proyecto aguante la respiración.
Las dos siguen la misma dirección. Tambora empezó como un lugar para guardar casos de prueba y se está volviendo el lugar donde se decide la estrategia de calidad.
Un aliado que alquila una herramienta de pruebas de estante está haciendo una afirmación sobre pruebas. Un aliado que construyó la suya, le metió IA hace más de un año, y corre el trabajo de sus clientes sobre ella está haciendo otra.
En 30 minutos te mostramos qué entregaría primero un Pod y cómo lo cotizaríamos.
