¿Para qué sirve la función «Tabla de datos» de NotebookLM?
La función «Tabla de datos» (ubicada en el Studio de NotebookLM) es una herramienta de extracción y estructuración. A diferencia del chat convencional, que te da respuestas narrativas, esta función busca patrones repetitivos o datos específicos en tus fuentes para organizarlos en columnas y filas.
- ¿Qué tipo de fuente requiere?: Funciona mejor con fuentes que contienen listas, catálogos, registros financieros o descripciones técnicas.
- ¿Qué puedes obtener?: Un resumen comparativo o un listado estructurado que te permite ver «la foto completa» de tus datos sin tener que leer página por página.
Caso de uso aplicado
Utilicé como ejemplo el apartado «1.3.6. Métricas de éxito y dificultades asociadas a la prueba basada en el riesgo» correspondiente al programa de estudios del ISTQB Nivel Avanzado en Gestión de Pruebas, de ahí las siglas RBT.
Como Test Manager o QA Lead debemos tener respuesta a las siguientes consultas:
- ¿Participaron o estuvieron de alguna forma representados todos o la mayoría de las personas implicadas y relevantes para analizar los riesgos?
- ¿Los implicados en analizar los riesgos tuvieron una correcta participación demostrando su conocimiento y compartiendo su experiencia para aportar valor a la reunión?
- ¿Se pudieron encontrar la mayoría de los defectos fijados como de alta prioridad de manera temprana durante la ejecución de las pruebas?
- ¿El equipo de testers involucrados ha podido explicar los resultados de las pruebas, con datos cuantitativos y cualitativos, a los implicados en términos de riesgos y no operativos propios de testing?
Tengamos en cuenta que para responder estas y otras preguntas, debemos procesar cierta cantidad de datos que están registrados en el o en los diferentes sistemas o aplicaciones que tanto el equipo de testers como nosotros (Test Manager o QA Lead) usamos, por ejemplo un Xray integrado a un Jira Software.
Entonces…generé a partir de un prompt framework que tengo armado y preparado para estos casos:
- un informe de métricas
- un registro de las dificultades y la mitigación correspondiente
- un conjunto de datos de ejecución de pruebas según su nivel de riesgo
Debes considerar que todos los datos que surgen de los informes que te mostraré a continuación, fueron definidos previamente por un equipo de proyecto en particular, y luego «curados».
1. Métricas de éxito de la Retrospectiva
Aquí se describe la evaluación del equipo de pruebas sobre los beneficios obtenidos mediante el enfoque RBT (Pruebas Basadas en Riesgos).
| ID Métrica | Pregunta de Evaluación / Indicador | Resultado | Valor (%) | Comentarios de Implicados (Stakeholders) |
| M001 | Participación de implicados relevantes en análisis | Afirmativo | 92% | Representantes de Arquitectura y Negocio presentes. |
| M002 | Adecuación de la participación (calidad del aporte) | Parcial | 75% | El equipo de DevOps participó tarde en el proceso. |
| M003 | Defectos críticos escapados a producción (Resueltos) | Afirmativo | 100% | 2 incidentes críticos detectados y mitigados en post-lanzamiento. |
| M004 | Detección temprana de defectos de alta prioridad | Afirmativo | 88% | El 88% de defectos P1/P2 se hallaron en los primeros 3 ciclos. |
| M005 | Comunicación de resultados en términos de riesgo | Afirmativo | 95% | Los informes semanales usaron el mapa de calor de riesgo. |
| M006 | Riesgo de pruebas omitidas vs. pruebas ejecutadas | Afirmativo | 100% | Todas las pruebas omitidas eran de riesgo «Bajo» o «Muy Bajo». |
2. Registro de dificultades y mitigación
Aquí presento una descripción de un seguimiento de las complejidades encontradas durante el ciclo de gestión de riesgos.
| Dificultad Identificada | Impacto | Estado | Solución Aplicada (ISTQB) | Responsable |
| Dificultad para evaluar nivel de riesgo | Alto | Mitigado | Uso de datos históricos de fallos de 2024 y consulta a expertos. | Test Manager |
| Comienzo entusiasta (Presión corto plazo) | Medio | Activo | Monitorización regular y reportes de riesgo quincenales. | Project Manager |
| Déjà vu (Complacencia en riesgos) | Bajo | Resuelto | Rotación de facilitadores en la identificación de riesgos. | Equipo QA |
| Omisión de riesgos clave | Crítico | Resuelto | Formación intensiva al equipo en análisis de impacto. | Consultor Senior |
| Rotación de implicados | Medio | En curso | Análisis de riesgo declarado como actividad continua e iterativa. | Stakeholders |
3. Datos de ejecución de pruebas según el nivel de riesgos
Distribución del esfuerzo de prueba basado en la criticidad.
- Riesgo Muy Alto: 45 Casos de prueba – Ejecución: 100% – Defectos hallados: 32.
- Riesgo Alto: 60 Casos de prueba – Ejecución: 100% – Defectos hallados: 18.
- Riesgo Medio: 120 Casos de prueba – Ejecución: 85% – Defectos hallados: 12.
- Riesgo Bajo: 200 Casos de prueba – Ejecución: 40% (Omitidas justificadamente) – Defectos hallados: 2.
Contenido publicado en LinkedIn (incluye video de 3 minutos 45 segundos)
