# Tambora > Tambora es la plataforma de gestión de QA que Koombea construyó y mantiene. Diseño de casos de prueba desde un requisito escrito, cobertura por versión, y un servidor MCP que responde preguntas de cobertura dentro del editor. Fuente: https://www.koombea.com/es/products/tambora/ --- 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. ## Qué es 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. - Módulos y suites, con jerarquía, para que un producto grande siga siendo navegable - Casos que documentan precondiciones, pasos y resultados esperados - Ejecución con estados reales, incluyendo pasó, falló, bloqueado y reprobado - Cobertura y avance de ejecución visibles por proyecto y no por la memoria de alguien ## Qué cambió Tres cifras, todas medidas contra cómo trabajábamos antes de que existiera. - Menos tiempo diseñando casos de prueba: Medido contra nuestro propio antes y después, no contra el referente de un analista - De un requisito escrito a casos estructurados: El mismo trabajo antes se iba en horas, así que era lo primero que se cortaba - Cobertura pegada a una versión con nombre: En vez de al recuerdo de alguien en una reunión de estado ## La parte que cambió la economía 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. - Casos estructurados generados desde un requisito escrito en lenguaje simple - Casos positivos, negativos y borde, con datos de prueba contextuales ya llenos - Cada caso editable, categorizado y ligado a un ticket antes de guardarse - 50 a 75% menos tiempo diseñando casos, medido contra nuestra propia línea base - Un servidor MCP que responde preguntas de cobertura dentro del editor - Cobertura consultable por corrida de prueba, etiqueta, severidad o criterio de aceptación ## De un requisito a un caso ejecutado Escribir el requisito: Alguien de ingeniería declara qué se supone que hace la funcionalidad, en lenguaje simple, dentro del módulo al que pertenece. (Minutos, no un taller) El asistente propone casos: Los casos positivos, negativos y borde vuelven estructurados, con precondiciones, pasos, resultados esperados y datos de prueba contextuales ya llenos. (Segundos) Ingeniería decide: 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. (El asistente propone, no aprueba) Ejecutar contra una corrida: 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. (La cobertura se vuelve un hecho) Los responsables ven el panorama: Cobertura, avance de ejecución, contribución e historial, por proyecto y por versión, sin pedirle a nadie que lo arme. (Tableros, no una reunión de estado) "No queríamos una IA que solo escupiera texto. Necesitábamos casos de prueba usables directamente dentro del sistema. Eso fue lo que construimos." Felipe Guerrero, Director de Calidad, Koombea ## Qué tiene dentro - **Módulos y suites**: Casos organizados por módulo y submódulo, con suites y subsuites para productos demasiado grandes para caber en una sola lista. - **Test Run**: 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. - **Asistente de casos de prueba**: Construido sobre nuestros propios agentes, con la API de Claude por defecto. Entra un requisito escrito, salen casos estructurados. - **Selección dinámica de modelo**: 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. - **Iteradores**: Documentar un escenario una vez, y después declarar cuántas veces corre: por navegador, por tipo de documento, por dispositivo, incluyendo combinaciones. - **Métricas y tableros**: Cobertura, avance de ejecución y contribución, por proyecto en vez de por anécdota. - **Roles y permisos**: Acceso separado para administradores, testers, ingeniería y usuarios de solo lectura. - **Integración con Jira**: Los casos y las corridas se ligan a sus tickets y épicas, así que la trazabilidad sobrevive el contacto con el backlog. - **Documentos**: Una casa central para los registros operativos: reportes de conformidad de accesibilidad, planes y protocolos de versión, planes de transición. - **Tambora MCP**: La cobertura expuesta al editor, para que la pregunta se responda donde está pasando el trabajo. ## Antes de Tambora, y después de ella | | 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. | ## Por qué esto importa en tu proyecto ### Durante la construcción — Cobertura que puedes ver, no cobertura que te cuentan. 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. - Cada criterio de aceptación trazable a los escenarios que lo comprueban - Cobertura reportada contra una versión, no como una garantía general - Vacíos que salen a la luz mientras todavía hay tiempo de cerrarlos ### En la entrega — El registro sobrevive a las personas que lo hicieron. 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. - Registros operativos guardados donde el siguiente equipo los va a buscar - Una biblioteca de pruebas que documenta el comportamiento buscado, no solo los resultados - Continuidad cuando la responsabilidad se mueve entre equipos 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. ## Para dónde va 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. ## La calidad corre sobre software propio 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.