El Viernes Antes Del Release
Viernes 15:00. Release programado para el lunes por la mañana.
El CTO entra en la oficina de QA:
“Marie, ¿estamos listos para lanzar el lunes? ¿Todos los tests pasaron?”
Marie (QA Lead) abre su laptop:
Paso 1: Abrir Excel
- Archivo:
Test_Cases_Release_v2.3_FINAL_v4.xlsx - 87 test cases listados
- Columnas: ID, Descripción, Prioridad, Estado (Passed/Failed/Not Run)
Paso 2: Contar manualmente
- 62 tests marcados “Passed”
- 18 tests marcados “Not Run”
- 7 tests marcados “Failed”
Paso 3: Verificar Jira
- 14 bugs abiertos
- 8 bugs “In Progress”
- 3 bugs “Resolved” (pero no cerrados)
Paso 4: Consultar sus notas
- Post-it: “Testear feature SSO con Microsoft OAuth”
- Email: “No olvides retestear el bug AUTH-247”
- Mensaje Slack: “@marie ¿está arreglado el bug de paginación?”
30 minutos después.
Marie responde:
“Eh… creo que estamos bien. Quedan 18 tests no críticos que no tuve tiempo de hacer. Los 7 fallidos son bugs conocidos en proceso de arreglo. Debería estar bien.”
CTO: “¿Debería?”
Marie: “Sí… bueno, a menos que haya olvidado algo.”
El CTO tiene una opción:
- ✅ Lanzar el lunes (con 18 tests no ejecutados y 7 bugs activos)
- ❌ Retrasar el release (y decepcionar a los clientes)
El CTO elige: Lanzar. “Ya veremos.”
Lunes 10:00: Bug crítico en producción. La feature SSO Microsoft OAuth no funciona.
Causa: Marie había olvidado testearlo (estaba en un post-it perdido).
El Problema Del QA Invisible
La mayoría de los equipos tech gestionan sus tests de esta manera: QA disperso entre herramientas desconectadas, sin visibilidad global.
Los Cinco Síntomas Del QA Invisible
1. Test Cases En Excel (Desconectados Del Desarrollo)
El Escenario: Tu QA mantiene un archivo Excel con todos los test cases:
Test_Cases_v1.xlsxTest_Cases_v2_FINAL.xlsxTest_Cases_v2.3_FINAL_v4.xlsx(¿el archivo real… o no?)
El Problema:
- ❌ Excel no está vinculado a las features en desarrollo
- ❌ Imposible saber qué tests cubren qué feature
- ❌ Sin sincronización con el código (feature añadida = test olvidado)
- ❌ Múltiples versiones de Excel (nadie sabe cuál es la actual)
Resultado Real: Un equipo descubre 3 semanas después de un release que una feature crítica no tenía ningún test case definido - estaba en una versión antigua de Excel perdida.
2. Bugs En Jira (Pero Sin Vínculo Con Los Tests)
El Escenario: Los bugs se trackean en Jira:
[BUG-423] Pagination broken on user list[BUG-424] SSO Microsoft OAuth fails with 500 error[BUG-425] Export PDF crashes on large datasets
El Problema:
- ❌ Sin vínculo entre el bug y el test case que lo detectó
- ❌ Imposible saber si el bug fue retesteado después del fix
- ❌ Sin vista global “¿cuántos bugs bloquean el release?”
- ❌ QA debe cruzar manualmente Excel (tests) y Jira (bugs)
Escenario Real:
Marie (QA): “¿Está arreglado el bug AUTH-247?”
Dev: “Sí, cerrado ayer.”
Marie: “Ok.”
2 semanas después: El bug AUTH-247 reaparece en producción.
¿Por qué? Marie nunca lo retesteó. Pensó que “cerrado” = “validado QA”. El dev pensó que cerrar el bug = QA automático.
3. Resultados De Tests Perdidos (Sin Historial)
El Escenario: Marie testea manualmente una feature. Encuentra un bug, lo reporta en Jira, y luego… olvida que ya había testeado esa feature.
3 semanas después:
Dev: “Marie, ¿retesteaste la feature X después de mi fix?”
Marie: “Eh… ¿creo que sí? Espera, voy a verificar.”
Marie busca:
- Excel: sin rastro de fecha/resultado
- Jira: bug cerrado pero sin comentario QA
- Notas: nada
- Memoria: “Creo que lo testeé pero no estoy segura.”
Marie retestea. (Tiempo perdido: 30 minutos en algo que ya había hecho)
El Problema:
- ❌ Sin historial de ejecuciones de tests
- ❌ Imposible saber “quién testeó qué cuándo”
- ❌ Tests duplicados (mismo test ejecutado 2 veces por error)
- ❌ Tests olvidados (“Pensé que alguien ya lo había testeado”)
4. Cobertura QA Invisible
El Escenario: Vas a lanzar un release con 12 features.
Pregunta del CTO: “¿Cuál es nuestra cobertura de tests para este release?”
Proceso de respuesta:
- Listar las 12 features
- Abrir Excel, contar cuántos test cases por feature
- Contar cuántos tests “Passed” vs “Not Run”
- Reconstruir mentalmente la cobertura
Tiempo necesario: 1-2 horas.
Fiabilidad: 60% (probablemente olvidaste algo).
Respuesta final: “Diría que estamos al 70-80% de cobertura.”
El Problema:
- ❌ Sin vista automática de cobertura
- ❌ Imposible saber “¿La Feature X está bien testeada?”
- ❌ Decisiones de lanzamiento basadas en intuición, no datos
- ❌ Sin métricas QA confiables
5. QA Bloqueado Al Final Del Sprint (El Cuello De Botella)
El Escenario: Lunes-Miércoles: Los devs codean.
Jueves-Viernes: “Marie, aquí hay 8 features para testear para el release del lunes.”
Marie: “¡¿8 features en 2 días?!”
Resultado:
- Marie testea con urgencia
- 50% de los tests son superficiales (no exhaustivos)
- 30% de los tests no se ejecutan (sin tiempo)
- Bugs encontrados el viernes por la noche → sin tiempo para arreglar antes del lunes
El Problema:
- ❌ QA es tratado como una “fase final” en lugar de un proceso continuo
- ❌ Sin visibilidad en tiempo real de lo que está listo para testear
- ❌ Marie no sabe cuándo las features estarán listas para ella
- ❌ Testing se convierte en un cuello de botella
Por Qué El QA Se Vuelve Invisible
Razón 1: Las Herramientas De Dev Y QA Están Separadas
Los Devs Usan:
- Jira/Linear para trackear issues
- GitHub para el código
- CI/CD para tests automatizados
QA Usa:
- Excel para test cases
- Jira para reportar bugs
- Notas personales para seguimiento
Resultado: Dos mundos paralelos que nunca se comunican.
Los devs no saben qué testea QA. QA no sabe qué han desarrollado los devs.
Razón 2: Los Test Cases No Están Vinculados A Las Features
El Problema: En Excel, tienes:
TC-001: Test user login with valid credentialsTC-002: Test user login with invalid credentialsTC-003: Test SSO Google OAuth
Pero sin información sobre:
- Qué feature cubren estos tests
- Qué release requiere estos tests
- Qué desarrollador implementó la feature testeada
- Si la feature cambió desde la creación del test
Resultado: Los test cases flotan en el vacío, desconectados del trabajo real.
Razón 3: Sin Visibilidad En Tiempo Real
El Problema: El CTO pregunta: “¿Dónde estamos con el testing del release?”
Hoy, QA debe:
- Abrir Excel
- Contar manualmente
- Verificar Jira para bugs
- Consultar notas
- Reconstruir mentalmente el estado global
No existe vista en tiempo real que muestre:
- Cuántos tests ejecutados vs restantes
- Qué features están validadas QA
- Cuántos bugs bloquean el release
- Si el release puede salir
Resultado: El QA es invisible hasta que alguien pregunta explícitamente.
El Enfoque Sinra: QA Unificado Con El Desarrollo
Sinra fue diseñado para hacer el QA visible, vinculado al desarrollo, y en tiempo real.
El Concepto: Testings Vinculados A Capabilities Y Releases
En Sinra, los testings (test cases) están directamente vinculados a las capabilities (features) y los releases.
Flujo de trabajo:
- Se crea una capability (ej: “Autenticación SSO”)
- Se añaden issues de desarrollo bajo la capability
- Se crean testings (test cases) y se vinculan a la capability
- QA ejecuta los testings y registra resultados
- La progresión QA se sincroniza automáticamente con el release
Resultado: Dev y QA trabajan en el mismo sistema, con visibilidad compartida.
Anatomía De Una Feature Con Testings Sinra
Paso 1: Crear La Capability “Autenticación SSO”
Descripción:
- Permitir a los usuarios iniciar sesión vía Google y Microsoft OAuth
Issues:
[AUTH-120] Implementar Google OAuth backend[AUTH-121] Implementar Microsoft OAuth backend[AUTH-122] Crear UI selección proveedor SSO[AUTH-123] Añadir gestión tokens y refresh
Paso 2: Crear Los Testings Para Esta Capability
Testings QA:
| ID | Test Case | Prioridad | Vinculado a |
|---|---|---|---|
| TC-AUTH-01 | Login Google OAuth con cuenta válida | Alta | AUTH-120 |
| TC-AUTH-02 | Login Google OAuth con cuenta inválida | Alta | AUTH-120 |
| TC-AUTH-03 | Login Microsoft OAuth con cuenta válida | Alta | AUTH-121 |
| TC-AUTH-04 | Login Microsoft OAuth con cuenta inválida | Alta | AUTH-121 |
| TC-AUTH-05 | Selección proveedor SSO en UI | Media | AUTH-122 |
| TC-AUTH-06 | Gestión refresh token tras expiración | Alta | AUTH-123 |
Beneficios:
- ✅ Cada test está vinculado al issue de desarrollo
- ✅ Cuando el issue AUTH-120 se completa, Sinra alerta a QA que TC-AUTH-01 y TC-AUTH-02 están listos para testear
- ✅ Sin test olvidado (imposible marcar capability “Done” si tests no ejecutados)
Paso 3: Ejecutar Tests Y Registrar Resultados
Marie (QA) ejecuta los tests:
TC-AUTH-01: Login Google OAuth con cuenta válida
- Resultado: ✅ Passed
- Fecha: 2025-12-22 10:34
- Testeado por: Marie
- Notas: Funciona correctamente, redirección OK, token almacenado
TC-AUTH-03: Login Microsoft OAuth con cuenta válida
- Resultado: ❌ Failed
- Fecha: 2025-12-22 11:02
- Testeado por: Marie
- Bug creado:
[BUG-456] Microsoft OAuth retorna error 500 - Notas: Error del servidor durante validación token Microsoft
Beneficios:
- ✅ Historial completo preservado (quién, cuándo, resultado, notas)
- ✅ Bug automáticamente vinculado al test case y al issue de desarrollo
- ✅ Dev recibe notificación: “Bug detectado en AUTH-121 por TC-AUTH-03”
Paso 4: Dev Arregla Bug, QA Retestea
Dev arregla BUG-456:
- Commit:
Fix Microsoft OAuth token validation - Marca bug “Resolved”
- Sinra notifica automáticamente a Marie: “BUG-456 resuelto, retestear TC-AUTH-03”
Marie retestea:
- TC-AUTH-03: Login Microsoft OAuth con cuenta válida
- Resultado: ✅ Passed (retest)
- Fecha: 2025-12-22 15:18
- Notas: Fix validado, funciona correctamente ahora
Beneficios:
- ✅ Sin test olvidado (notificación automática)
- ✅ Historial completo (failed → bug → fix → passed)
- ✅ Sincronización Dev ↔ QA en tiempo real
Vista Global: Progresión QA Por Release
Release: SaaS Platform v2.5 (Entrega: 2025-12-30)
| Capability | Tests Total | Passed | Failed | Not Run | Estado QA |
|---|---|---|---|---|---|
| Autenticación SSO | 6 | 6 | 0 | 0 | ✅ Validado |
| Analytics Dashboard | 8 | 5 | 1 | 2 | ⚠️ En Progreso |
| API Webhooks | 10 | 0 | 0 | 10 | 🚨 No Iniciado |
| Export PDF | 5 | 4 | 0 | 1 | ⚠️ En Progreso |
Progresión Global QA: 15/29 tests pasados = 52% completado
Alertas Automáticas:
- 🚨 API Webhooks: 0 tests ejecutados (entrega en 8 días)
- ⚠️ Analytics Dashboard: 1 bug activo (bloquea validación QA)
Beneficios:
- ✅ Vista en tiempo real del estado QA por release
- ✅ Identificación inmediata de riesgos
- ✅ Respuesta instantánea a “¿Podemos lanzar?”
Respuesta al CTO:
“No, no podemos lanzar el lunes. API Webhooks no tiene tests ejecutados, y Analytics todavía tiene 1 bug activo. Recomiendo retrasar 5 días o quitar API Webhooks del release.”
Tiempo de respuesta: 30 segundos en lugar de 2 horas.
Las Cinco Ventajas Del QA Unificado Sinra
1. Tests Vinculados A Features (No Excel Desconectado)
Antes (Excel):
- Test cases flotan en el vacío
- Sin vínculo con código desarrollado
- Features añadidas = tests olvidados
Después (Sinra):
- Cada testing vinculado a una capability
- Imposible marcar “Done” sin tests validados
- Features nuevas = crear testings sugeridos automáticamente
2. Historial Completo De Ejecuciones
Antes (Notas/Memoria):
- “Creo que testeé eso la semana pasada…”
- Sin rastro de quién testeó qué cuándo
- Tests duplicados
Después (Sinra):
- Historial completo: fecha, tester, resultado, notas
- “TC-AUTH-03 testeado por Marie el 22/12 a las 11:02: Failed, bug BUG-456 creado”
- Búsqueda: “¿Quién testeó Microsoft OAuth?” → Respuesta instantánea
3. Sincronización Dev ↔ QA Automática
Antes (Herramientas Separadas):
- Dev completa issue → QA no sabe que está listo
- Bug arreglado → QA debe adivinar que debe retestear
- Desincronización constante
Después (Sinra):
- Issue completado → QA notificado automáticamente
- Bug resuelto → Test case a re-ejecutar sugerido
- Dev y QA trabajan en el mismo sistema
4. Visibilidad En Tiempo Real De Cobertura QA
Antes (Cálculo Manual):
- “¿Cuál es nuestra cobertura?” → 2h de cálculo
- Fiabilidad 60%
- Decisiones basadas en intuición
Después (Sinra):
- Vista automática: 15/29 tests pasados (52%)
- Por capability: SSO 100%, Webhooks 0%
- Decisiones basadas en datos reales
5. Cuello De Botella QA Eliminado (Testing Continuo)
Antes (QA Al Final Del Sprint):
- Dev codea lunes-miércoles
- QA testea jueves-viernes con urgencia
- Bugs encontrados muy tarde
Después (Sinra):
- QA ve en tiempo real cuándo issues están listos
- Testing continuo (apenas se completa un issue)
- Bugs detectados temprano (tiempo para arreglar antes del release)
Ejemplo Real: HealthTech Solutions
HealthTech Solutions (equipo de 10 personas, plataforma SaaS salud)
Nota: HealthTech Solutions es una empresa real que hemos anonimizado bajo un nombre ficticio para proteger su confidencialidad.
Antes De Sinra: QA Invisible
Stack de herramientas:
- Excel: Test cases (
Test_Cases_v12_FINAL.xlsx) - Jira: Bugs e issues de desarrollo
- Notas personales: Resultados de tests
- Slack: Comunicación Dev ↔ QA
Problemas Encontrados:
- Cobertura invisible: Imposible saber cuántos tests faltaban
- Tests olvidados: 2 features lanzadas sin ningún test (descubierto tras incidentes prod)
- Desincronización: QA testeaba a menudo versiones obsoletas (dev ya había cambiado el código)
- Cuello de botella QA: Marie (única QA) abrumada al final del sprint
- Historial perdido: “¿Ya testeé esto?” (sin rastro)
Incidente Revelador: Release “Patient Portal v3.2” lanzado con feature “Export historial médico PDF”.
1 semana tras el release: 12 clientes reportan que el export PDF falla en historiales >50 páginas.
Análisis: No existía test case para “Export PDF con historiales grandes”. Marie solo había testeado con historiales pequeños (5 páginas).
Costo:
- 3 semanas de fixes urgentes
- 12 clientes descontentos
- Reputación impactada
Después De Sinra: QA Unificado
Flujo de trabajo:
- Cada capability tiene testings definidos desde la concepción
- QA crea test cases directamente en Sinra (vinculados a capability)
- Cuando dev completa issue, Marie es notificada automáticamente
- Marie ejecuta tests, registra resultados, crea bugs si es necesario
- Vista en tiempo real de progresión QA por release
Resultados (Tras 4 Meses):
- Cobertura visible: Vista automática “Release 78% testeado”
- Tests olvidados: 0 (imposible lanzar sin validar testings)
- Sincronización: Dev y QA alineados en tiempo real
- Cuello de botella QA: Eliminado (testing continuo durante todo el sprint)
- Historial completo: “TC-PDF-05 testeado 3 veces: 12/12 failed, 15/12 failed, 18/12 passed”
Cita de Marie (QA Lead):
“Antes, pasaba el 30% de mi tiempo buscando qué había testeado y preguntando a los devs qué estaba listo. Ahora, Sinra me dice exactamente qué testear y puedo trazar todo mi trabajo. Testeo 2x más con cero estrés.”
Cita del CTO:
“Se acabaron los viernes por la noche preguntándose si podemos lanzar el lunes. Abro Sinra, veo la progresión QA en tiempo real, y tomo decisiones basadas en hechos. Game changer.”
Excel + Jira vs. Sinra: Comparación QA
| Aspecto | Excel + Jira | Sinra Testings |
|---|---|---|
| Test cases | Excel desconectado | Vinculados a capabilities |
| Vínculo con features | ❌ Ninguno | ✅ Automático |
| Historial ejecuciones | ❌ Ninguno (notas manuales) | ✅ Completo con fechas/testers |
| Sincronización Dev ↔ QA | ❌ Manual | ✅ Automática |
| Cobertura QA visible | ❌ Cálculo manual (2h) | ✅ Tiempo real (<10s) |
| Alertas tests faltantes | ❌ Ninguna | ✅ Automáticas |
| Testing continuo | ❌ Cuello de botella al final sprint | ✅ Durante todo el sprint |
| Bugs vinculados a tests | ❌ Desconectados | ✅ Vinculados automáticamente |
| Visibilidad release | ❌ “Creo que estamos bien” | ✅ “78% testeados, 2 bugs activos” |
Las Cinco Señales De Que Tu QA Es Invisible
Señal 1: Tu QA Usa Excel Para Test Cases
Si tus test cases viven en un archivo Excel desconectado del desarrollo, tu QA es invisible.
Señal 2: No Sabes Cuántos Tests Quedan Antes Del Release
Si la respuesta a “¿Cuántos tests quedan?” requiere 1h de cálculo manual, tu cobertura QA es invisible.
Señal 3: QA Descubre Features Listas Por Casualidad
Si tu QA debe preguntar “¿Está listo para testear?” en lugar de ser notificado automáticamente, la sincronización está rota.
Señal 4: Lanzas Sin Saber Si Todo Está Testeado
Si respondes “Creo que sí” a “¿Está todo testeado?”, no tienes visibilidad.
Señal 5: Los Bugs Reaparecen Porque QA Olvidó Retestear
Si los bugs “arreglados” regresan porque QA no sabía que debía retestear, tu historial es inexistente.
Cómo Usar Sinra Para QA
Paso 1: Crear Testings Para Cada Capability
Acción:
- Cada capability (feature) tiene sección “Testings”
- Crear test cases con prioridad (Alta/Media/Baja)
- Vincular cada testing a issues de desarrollo relevantes
Resultado: Test cases vinculados al trabajo, no flotando en Excel.
Paso 2: Ejecutar Tests Y Registrar Resultados
Acción:
- Cuando issue completado, notificación QA
- QA ejecuta testing, registra resultado (Passed/Failed)
- Si Failed: crear bug directamente vinculado al test
Resultado: Historial completo, bugs trazados.
Paso 3: Seguir Progresión QA Por Release
Acción:
- Vista release muestra % tests ejecutados
- Alertas automáticas si tests faltantes
- Decisión de lanzamiento basada en datos reales
Resultado: Visibilidad tiempo real, decisiones informadas.
Paso 4: Testing Continuo (No Cuello De Botella Al Final Del Sprint)
Acción:
- QA testea apenas issues completados
- Bugs detectados temprano (tiempo para arreglar)
- Sin acumulación el viernes
Resultado: QA se convierte en proceso continuo, no fase final.
Puntos De Acción: Hacer Tu QA Visible
- Crea tus primeros testings en Sinra. Toma 1 capability, define 5-10 test cases.
- Vincula testings a issues de desarrollo. Asegura visibilidad Dev ↔ QA.
- Ejecuta y registra resultados. Construye historial completo.
- Sigue progresión QA en tiempo real. Usa vista release para visibilidad.
- Adopta testing continuo. Testea cuando esté listo, no al final del sprint.
El Punto Clave
El QA invisible mata la calidad.
Entre test cases Excel desconectados, bugs Jira sin vínculo, resultados perdidos, y cobertura desconocida, nadie sabe si el release puede salir.
Sinra hace el QA visible y unificado con el desarrollo.
Los testings están vinculados a capabilities, el historial es completo, la sincronización es automática, y la progresión es en tiempo real.
El resultado:
- ✅ Tests vinculados a features (no Excel desconectado)
- ✅ Historial completo de ejecuciones
- ✅ Sincronización Dev ↔ QA automática
- ✅ Visibilidad tiempo real de cobertura
- ✅ Cuello de botella QA eliminado (testing continuo)
Sabes exactamente qué está testeado, qué queda, y si puedes lanzar.
Tu yo futuro te lo agradecerá.
¿Listo para hacer tu QA visible? Inicia una prueba gratuita de Sinra →
Descubre gestión de proyectos donde los tests están vinculados al desarrollo, no perdidos en Excel.