Forma a tu equipo sin coste para tu empresa. Este curso de ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad es hasta 100% bonificable a través de FUNDAE.
Potencia las competencias clave de tus profesionales.
Accede a una formación práctica, actualizada y orientada a resultados.
Prepara a tu equipo para los retos del entorno laboral actual.
Nos ocupamos de la gestión con FUNDAE si tu empresa lo necesita.
A medida
Formación en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad a medida
Descubre el mejor curso de ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad para empresas con nuestra Aula Virtual Personalizada:
Sesiones en vivo por videoconferencia.
Temario totalmente personalizado.
Fechas y horarios adaptados a tu empresa.
Acceso a grabaciones.
Aprende practicando
Totalmente Práctico y Aplicable
Formación diseñada para que apliques cada concepto en situaciones reales de tu trabajo, con enfoque práctico y útil desde el primer momento.
Aprendizaje 100% práctico, enfocado en lo que realmente necesitas.
Casos reales y ejercicios adaptados a tu entorno profesional.
Aplica cada conocimiento directamente en tus tareas diarias.
Mejora tu rendimiento y el de tu equipo desde el primer día.
¿Por qué un curso en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad?
Sirve como ayuda conceptual alineada con fundamentos reconocidos
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
¿A quién va dirigida esta formación en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad?
Pensado para quienes deben dominar ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad en su día a día
Testers, QA Engineers y perfiles de calidad
Este curso encaja con profesionales que participan directamente en la validación de software y necesitan consolidar un enfoque riguroso de testing. Aprenderán a distinguir objetivos, niveles, tipos, técnicas, criterios de cobertura, gestión de defectos, trazabilidad, riesgos y métricas para pasar de probar “a ojo” a diseñar pruebas con intención, evidencia y valor.
Desarrolladores backend, frontend y full stack
Los equipos de desarrollo podrán comprender mejor cómo se diseñan pruebas útiles, por qué aparecen defectos, cómo mejorar la testabilidad del código y cómo colaborar con QA desde fases tempranas. La formación les ayuda a escribir software más verificable, participar en revisiones y reducir retrabajo antes de llegar a validación final.
Product Owners, analistas funcionales y perfiles de negocio
Los perfiles de producto y análisis aprenderán a formular requisitos, criterios de aceptación, ejemplos y escenarios de forma más comprobable. El curso les ayuda a colaborar en enfoques como ATDD, BDD, revisiones tempranas y análisis de riesgos, reduciendo ambigüedad antes de que el equipo desarrolle o pruebe.
Scrum Masters, Project Managers y responsables de entrega
Los perfiles de gestión podrán entender cómo planificar, monitorizar y controlar actividades de prueba en proyectos tradicionales, ágiles o DevOps. La formación aporta criterios para interpretar métricas, priorizar riesgos, gestionar defectos, revisar criterios de salida y evitar que la calidad se mida solo al final.
Equipos DevOps, SRE y plataformas de entrega
Los equipos orientados a delivery continuo podrán conectar testing con pipelines, automatización, despliegues frecuentes, feedback rápido, observabilidad y calidad en producción. El curso no se limita a pruebas manuales, sino que integra testing dentro de un flujo moderno de entrega y operación.
Responsables de calidad, auditoría y mejora de procesos
Los perfiles que supervisan calidad de software, cumplimiento, auditoría interna o mejora continua encontrarán una base estructurada para definir procesos de prueba, evidencias, trazabilidad, defectos, métricas y criterios de aceptación. El curso permite elevar la madurez del testing sin imponer burocracia innecesaria.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
No. El curso está inspirado en los fundamentos públicos del nivel Foundation de ISTQB y ayuda a adquirir una base útil, pero no sustituye una formación oficial acreditada ni garantiza la superación de ningún examen ofrecido por partners oficiales.
Sí, se toma como referencia conceptual para no dejar fuera los bloques habituales de fundamentos de testing, ciclo de vida, testing estático, diseño de pruebas, gestión de actividades de prueba y herramientas. El enfoque, sin embargo, es corporativo y aplicado al puesto.
Es útil para ambos. Los testers profundizan en diseño, gestión y técnicas de prueba; los desarrolladores entienden mejor cobertura, defectos, pruebas unitarias, revisiones, testabilidad y colaboración con QA desde fases tempranas.
No es imprescindible. El curso empieza por fundamentos, vocabulario y principios, pero avanza hacia técnicas y gestión profesional. Ayuda haber participado en proyectos de software, incidencias, validaciones, soporte o entregas.
Sí. Se trabajan partición de equivalencia, análisis de valores límite, tablas de decisión, transición de estados, cobertura de sentencias, cobertura de ramas, testing exploratorio, error guessing, checklist-based testing y enfoques colaborativos.
Sí. El curso incluye Scrum, Kanban, Definition of Done, criterios de aceptación, ATDD, BDD, pipelines, automatización, feedback rápido, shift-left, shift-right, observabilidad y relación entre testing y delivery continuo.
Sí. Se trabaja el ciclo de vida del defecto, severidad, prioridad, triage, causa raíz, defectos escapados, métricas de ejecución, métricas de defectos, reporting, criterios de salida y comunicación ejecutiva de calidad.
Es práctico. Cada bloque incorpora aplicación a casos reales: revisión de requisitos, diseño de casos, matrices de riesgo, defectos, métricas, criterios de aceptación, estrategia de pruebas y un proyecto final integrador.
El curso puede adaptarse a Jira, Azure DevOps, TestRail, Xray, Zephyr, Confluence, GitLab, SonarQube, Postman u otras herramientas corporativas. Lo importante es aprender el criterio antes de depender de una herramienta concreta.
Sí. Al tratarse de una formación corporativa en testing, calidad de software, gestión de defectos, herramientas y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
No. El curso está inspirado en los fundamentos públicos del nivel Foundation de ISTQB y ayuda a adquirir una base útil, pero no sustituye una formación oficial acreditada ni garantiza la superación de ningún examen ofrecido por partners oficiales.
Sí, se toma como referencia conceptual para no dejar fuera los bloques habituales de fundamentos de testing, ciclo de vida, testing estático, diseño de pruebas, gestión de actividades de prueba y herramientas. El enfoque, sin embargo, es corporativo y aplicado al puesto.
Es útil para ambos. Los testers profundizan en diseño, gestión y técnicas de prueba; los desarrolladores entienden mejor cobertura, defectos, pruebas unitarias, revisiones, testabilidad y colaboración con QA desde fases tempranas.
No es imprescindible. El curso empieza por fundamentos, vocabulario y principios, pero avanza hacia técnicas y gestión profesional. Ayuda haber participado en proyectos de software, incidencias, validaciones, soporte o entregas.
Sí. Se trabajan partición de equivalencia, análisis de valores límite, tablas de decisión, transición de estados, cobertura de sentencias, cobertura de ramas, testing exploratorio, error guessing, checklist-based testing y enfoques colaborativos.
Sí. El curso incluye Scrum, Kanban, Definition of Done, criterios de aceptación, ATDD, BDD, pipelines, automatización, feedback rápido, shift-left, shift-right, observabilidad y relación entre testing y delivery continuo.
Sí. Se trabaja el ciclo de vida del defecto, severidad, prioridad, triage, causa raíz, defectos escapados, métricas de ejecución, métricas de defectos, reporting, criterios de salida y comunicación ejecutiva de calidad.
Es práctico. Cada bloque incorpora aplicación a casos reales: revisión de requisitos, diseño de casos, matrices de riesgo, defectos, métricas, criterios de aceptación, estrategia de pruebas y un proyecto final integrador.
El curso puede adaptarse a Jira, Azure DevOps, TestRail, Xray, Zephyr, Confluence, GitLab, SonarQube, Postman u otras herramientas corporativas. Lo importante es aprender el criterio antes de depender de una herramienta concreta.
Sí. Al tratarse de una formación corporativa en testing, calidad de software, gestión de defectos, herramientas y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
Comprensión del testing como actividad orientada a aportar información sobre calidad, riesgo y confianza, no como una simple búsqueda final de errores.
Diferenciación entre probar para encontrar defectos, prevenir problemas, validar requisitos, apoyar decisiones y reducir incertidumbre del negocio.
Análisis de por qué el testing no puede demostrar ausencia total de defectos, sino aportar evidencia razonable según contexto, riesgo y cobertura.
Revisión de los siete principios clásicos de testing y su aplicación práctica en proyectos reales, evitando interpretaciones puramente memorísticas.
Identificación de errores humanos, defectos en productos de trabajo, fallos observables y causas raíz dentro del ciclo de vida del software.
Relación entre coste de corrección y momento de detección, mostrando por qué los defectos encontrados tarde suelen ser más caros y dañinos.
Separación entre verificación y validación para distinguir si el producto se construye correctamente y si realmente resuelve la necesidad esperada.
Reconocimiento del papel del tester como proveedor de información crítica para negocio, desarrollo, producto, soporte y dirección.
Evaluación de cómo el testing contribuye a confianza, cumplimiento, reputación, experiencia de usuario, seguridad, mantenibilidad y continuidad operativa.
Creación de una definición compartida de calidad para el equipo, alineada con producto, usuario, riesgo, negocio y contexto técnico.
Comprensión del testing como actividad orientada a aportar información sobre calidad, riesgo y confianza, no como una simple búsqueda final de errores.
Diferenciación entre probar para encontrar defectos, prevenir problemas, validar requisitos, apoyar decisiones y reducir incertidumbre del negocio.
Análisis de por qué el testing no puede demostrar ausencia total de defectos, sino aportar evidencia razonable según contexto, riesgo y cobertura.
Revisión de los siete principios clásicos de testing y su aplicación práctica en proyectos reales, evitando interpretaciones puramente memorísticas.
Identificación de errores humanos, defectos en productos de trabajo, fallos observables y causas raíz dentro del ciclo de vida del software.
Relación entre coste de corrección y momento de detección, mostrando por qué los defectos encontrados tarde suelen ser más caros y dañinos.
Separación entre verificación y validación para distinguir si el producto se construye correctamente y si realmente resuelve la necesidad esperada.
Reconocimiento del papel del tester como proveedor de información crítica para negocio, desarrollo, producto, soporte y dirección.
Evaluación de cómo el testing contribuye a confianza, cumplimiento, reputación, experiencia de usuario, seguridad, mantenibilidad y continuidad operativa.
Creación de una definición compartida de calidad para el equipo, alineada con producto, usuario, riesgo, negocio y contexto técnico.
Tema 1: Fundamentos del testing de software y valor real para la empresa
Comprensión del testing como actividad orientada a aportar información sobre calidad, riesgo y confianza, no como una simple búsqueda final de errores.
Diferenciación entre probar para encontrar defectos, prevenir problemas, validar requisitos, apoyar decisiones y reducir incertidumbre del negocio.
Análisis de por qué el testing no puede demostrar ausencia total de defectos, sino aportar evidencia razonable según contexto, riesgo y cobertura.
Revisión de los siete principios clásicos de testing y su aplicación práctica en proyectos reales, evitando interpretaciones puramente memorísticas.
Identificación de errores humanos, defectos en productos de trabajo, fallos observables y causas raíz dentro del ciclo de vida del software.
Relación entre coste de corrección y momento de detección, mostrando por qué los defectos encontrados tarde suelen ser más caros y dañinos.
Separación entre verificación y validación para distinguir si el producto se construye correctamente y si realmente resuelve la necesidad esperada.
Reconocimiento del papel del tester como proveedor de información crítica para negocio, desarrollo, producto, soporte y dirección.
Evaluación de cómo el testing contribuye a confianza, cumplimiento, reputación, experiencia de usuario, seguridad, mantenibilidad y continuidad operativa.
Creación de una definición compartida de calidad para el equipo, alineada con producto, usuario, riesgo, negocio y contexto técnico.
Tema 2: Psicología del testing, sesgos y colaboración entre roles
Comprensión de cómo sesgos cognitivos, familiaridad con el producto y presión por entregar pueden reducir la capacidad de detectar defectos relevantes.
Análisis de la independencia del testing, diferenciando autocontrol del desarrollador, revisión entre pares, QA independiente y validación externa.
Revisión de ventajas e inconvenientes de distintos niveles de independencia, evitando convertir la separación de roles en falta de colaboración.
Identificación de tensiones habituales entre QA y desarrollo: defectos discutidos, prioridades cambiantes, requisitos ambiguos y presión de fechas.
Desarrollo de habilidades de comunicación para reportar defectos con claridad, evidencia, reproducibilidad y tono profesional.
Creación de conversaciones orientadas a riesgo y valor, no a culpa, cuando aparece un defecto en una fase avanzada del proyecto.
Uso de revisiones, refinamientos y ejemplos compartidos para que la calidad se trabaje antes de que exista código ejecutable.
Reconocimiento del impacto de la cultura del equipo en la calidad: confianza, transparencia, aprendizaje, responsabilidad compartida y mejora continua.
Preparación de acuerdos de equipo sobre cuándo probar, quién revisa, cómo se priorizan defectos y qué significa “terminado”.
Construcción de una mentalidad donde testing no es un departamento al final, sino una actividad distribuida durante todo el desarrollo.
Tema 3: Testing dentro del ciclo de vida del desarrollo de software
Comparación entre modelos secuenciales, iterativos, incrementales, ágiles y DevOps, identificando cómo cambia la estrategia de prueba en cada caso.
Ubicación de actividades de prueba desde requisitos y diseño hasta desarrollo, integración, aceptación, despliegue y operación.
Revisión del concepto shift-left para detectar defectos antes, mediante revisiones, análisis de requisitos, pruebas tempranas y criterios de aceptación claros.
Análisis del concepto shift-right para aprender de producción mediante observabilidad, monitorización, feedback de usuarios e incidencias reales.
Relación entre testing y entregas frecuentes, donde el feedback rápido y la automatización ayudan a reducir riesgo en cambios pequeños.
Identificación de productos de trabajo que pueden probarse sin ejecutar código: historias, especificaciones, diseños, modelos, datos y documentación.
Diseño de actividades de prueba alineadas con cada fase: análisis, diseño, implementación, integración, validación, despliegue y mantenimiento.
Comprensión de cómo los cambios evolutivos, correcciones y refactorizaciones requieren pruebas de regresión proporcionales al riesgo.
Revisión de cómo la gestión de configuración permite saber qué versión se probó, con qué datos, en qué entorno y bajo qué condiciones.
Elaboración de un mapa de actividades de testing integrado en el ciclo real de la empresa, sin crear fases artificiales desconectadas.
Tema 4: Niveles de prueba: componente, integración, sistema y aceptación
Diferenciación entre pruebas de componente, integración, sistema y aceptación, atendiendo al objetivo, alcance, responsable y tipo de defecto esperado.
Diseño de pruebas de componente para validar unidades pequeñas de software con foco en lógica, límites, errores y comportamiento esperado.
Revisión de pruebas de integración para detectar fallos en interfaces, contratos, dependencias, APIs, colas, bases de datos y servicios externos.
Planificación de pruebas de sistema para evaluar el producto completo desde la perspectiva funcional y no funcional esperada.
Comprensión de pruebas de aceptación orientadas a usuarios, negocio, contrato, regulación o preparación para puesta en producción.
Identificación de pruebas alfa, beta, UAT, pruebas operacionales y validaciones internas según madurez y contexto del producto.
Relación entre nivel de prueba y entorno necesario, evitando validar integraciones críticas en entornos incompletos o datos no representativos.
Revisión de trazabilidad entre requisitos, historias, niveles de prueba, defectos y criterios de aceptación.
Detección de solapamientos y huecos cuando un equipo prueba muchas veces lo mismo, pero deja interfaces o riesgos sin cubrir.
Creación de una matriz de niveles de prueba para un producto realista, asignando objetivos, responsables, evidencias y riesgos.
Tema 5: Tipos de prueba funcionales, no funcionales, estructurales y asociados al cambio
Diferenciación entre pruebas funcionales, no funcionales, estructurales y pruebas relacionadas con cambios, según objetivo y tipo de información buscada.
Diseño de pruebas funcionales para comprobar reglas de negocio, flujos, validaciones, cálculos, permisos, estados y resultados visibles.
Revisión de pruebas no funcionales: rendimiento, usabilidad, accesibilidad, seguridad, compatibilidad, portabilidad, fiabilidad y mantenibilidad.
Comprensión de pruebas estructurales basadas en la arquitectura interna, código, ramas, rutas, componentes o cobertura.
Aplicación de pruebas de confirmación para verificar que un defecto corregido realmente deja de reproducirse.
Aplicación de pruebas de regresión para comprobar que un cambio no rompe funcionalidades existentes o dependencias relacionadas.
Análisis de cómo seleccionar tipos de prueba según riesgo, criticidad, impacto en usuario, tecnología y frecuencia de cambio.
Identificación de pruebas que deben automatizarse, pruebas que requieren exploración humana y pruebas que se ejecutan por muestreo.
Revisión de errores frecuentes: llamar “regresión” a cualquier prueba repetida o tratar pruebas no funcionales como actividad opcional al final.
Elaboración de una estrategia equilibrada de tipos de prueba para una aplicación corporativa con riesgos funcionales y operativos.
Tema 6: Testing en contextos ágiles, Scrum, Kanban y DevOps
Integración del testing dentro de sprints, refinamientos, planificación, desarrollo, revisión, retrospectiva y entrega incremental.
Uso de criterios de aceptación para convertir historias de usuario en unidades verificables, evitando ambigüedad y expectativas implícitas.
Participación de QA en refinamiento para detectar riesgos, dependencias, casos límite y escenarios no definidos antes de comenzar el desarrollo.
Definición de Definition of Ready y Definition of Done con criterios de calidad, pruebas, revisión, automatización y evidencias.
Diseño de pruebas en Kanban cuando el flujo se basa en trabajo continuo, límites WIP, políticas explícitas y entrega bajo demanda.
Conexión entre testing y DevOps mediante pipelines, automatización, feedback rápido, despliegues controlados y monitorización.
Revisión de cómo los equipos ágiles equilibran pruebas manuales, automatizadas, exploratorias y colaborativas en ciclos cortos.
Identificación de riesgos del falso “ágil”: probar al final del sprint, acumular deuda de calidad o saltarse pruebas por presión de entrega.
Uso de retrospectivas para mejorar proceso de prueba, defectos escapados, colaboración, entornos, datos y criterios de aceptación.
Creación de un flujo de calidad ágil donde QA aporta criterio desde el inicio sin convertirse en cuello de botella final.
Tema 7: Testing estático: detectar defectos antes de ejecutar software
Comprensión del testing estático como análisis de productos de trabajo sin ejecutar el software, incluyendo revisiones y análisis estático.
Identificación de productos revisables: requisitos, historias, criterios de aceptación, diseños, contratos API, código, modelos, datos y manuales.
Análisis del valor de detectar defectos antes de programar, cuando todavía es más barato corregir ambigüedad, inconsistencia o falta de cobertura.
Revisión de defectos típicos encontrados en estático: contradicciones, omisiones, ambigüedad, incumplimiento de estándares y casos límite olvidados.
Aplicación de checklists para revisar historias, requisitos, pantallas, APIs, reglas de negocio y documentación funcional.
Comparación entre revisión informal, walkthrough, revisión técnica e inspección, atendiendo a rigor, roles y evidencia generada.
Uso de análisis estático de código para detectar vulnerabilidades, complejidad, duplicidad, estilo, errores potenciales y deuda técnica.
Relación entre testing estático y shift-left, integrando revisiones en refinamiento, diseño y pull requests.
Prevención de discusiones improductivas mediante criterios claros, foco en el producto de trabajo y registro de defectos o acciones.
Creación de una práctica de revisión sobre una historia ambigua para identificar defectos antes de diseñar casos de prueba.
Tema 8: Revisiones eficaces: roles, proceso, checklist y seguimiento
Diseño de un proceso de revisión con planificación, preparación individual, reunión opcional, registro de hallazgos, corrección y cierre.
Definición de roles habituales: autor, moderador, revisores, escriba, responsable de seguimiento y observadores cuando procede.
Creación de criterios de entrada para evitar revisar documentos inmaduros, incompletos o sin contexto suficiente.
Uso de checklists específicas por producto de trabajo, evitando listas genéricas que no detectan problemas relevantes.
Priorización de hallazgos según severidad, impacto, probabilidad, coste de corrección y fase del ciclo de vida.
Seguimiento de acciones derivadas de la revisión para asegurar que los defectos encontrados se corrigen y no se archivan sin resolver.
Medición de eficacia de revisiones mediante defectos encontrados, retrabajo evitado, defectos escapados y tiempo invertido.
Integración de revisiones en pull requests, refinamientos, sesiones Three Amigos, diseño técnico o control documental.
Manejo de dinámicas humanas para que la revisión no se perciba como crítica personal al autor.
Construcción de un modelo de revisión ligero o formal según criticidad, regulación, complejidad y madurez del equipo.
Tema 9: Técnicas de diseño de pruebas: visión general y criterio de selección
Comprensión de las técnicas de prueba como métodos para derivar casos con más cobertura, menos improvisación y mejor justificación.
Diferenciación entre técnicas de caja negra, caja blanca, basadas en experiencia y colaborativas.
Selección de técnicas según tipo de requisito, nivel de prueba, riesgo, información disponible, tiempo, experiencia y criticidad.
Revisión de cómo las técnicas ayudan a encontrar defectos diferentes, por lo que no deben verse como opciones excluyentes.
Aplicación de técnicas para evitar probar solo el “camino feliz” y olvidar límites, combinaciones, estados o reglas alternativas.
Relación entre técnica, condición de prueba, caso de prueba, dato de prueba, resultado esperado y cobertura.
Diseño de casos de prueba con trazabilidad hacia requisitos, historias, riesgos o criterios de aceptación.
Identificación de cuándo una prueba debe ser manual, automatizada, exploratoria, revisada por negocio o integrada en pipeline.
Revisión de errores comunes: casos sin resultado esperado, datos poco realistas, pasos ambiguos y pruebas duplicadas sin valor.
Creación de una plantilla corporativa de caso de prueba que sea útil sin convertirse en burocracia innecesaria.
Tema 10: Caja negra I: partición de equivalencia y análisis de valores límite
Aplicación de partición de equivalencia para agrupar datos que deberían comportarse de forma similar y reducir pruebas redundantes.
Identificación de clases válidas e inválidas a partir de reglas de negocio, validaciones, rangos, formatos y restricciones de entrada.
Diseño de casos representativos para cada partición, explicando por qué un dato cubre un conjunto y no solo un ejemplo aislado.
Uso de análisis de valores límite para probar bordes donde suelen aparecer defectos: mínimos, máximos, justo dentro y justo fuera.
Revisión de reglas numéricas, fechas, importes, longitudes de texto, edades, cantidades, porcentajes y límites de configuración.
Combinación de equivalencia y límites para construir pruebas compactas pero con alta capacidad de detección de errores.
Detección de errores típicos: operadores `<` frente a `<=`, redondeos, validaciones inconsistentes y límites no documentados.
Diseño de datos de prueba que permitan reproducir claramente cada partición y cada valor límite seleccionado.
Aplicación práctica sobre un formulario corporativo con importes, fechas, estados, campos obligatorios y reglas de validación.
Documentación de cobertura para justificar qué particiones se probaron, cuáles no y por qué.
Tema 11: Caja negra II: tablas de decisión y pruebas de reglas de negocio
Uso de tablas de decisión para modelar combinaciones de condiciones y acciones cuando las reglas de negocio dependen de varios factores.
Identificación de condiciones, acciones, reglas válidas, combinaciones imposibles y resultados esperados.
Reducción de combinaciones redundantes manteniendo cobertura suficiente de reglas relevantes.
Aplicación a procesos de descuentos, elegibilidad, aprobación, permisos, cálculo de tarifas, estados de pedido o validaciones complejas.
Detección de reglas contradictorias, incompletas o ambiguas antes de implementar o ejecutar pruebas.
Diseño de casos de prueba a partir de reglas de la tabla, con datos, pasos y resultados esperados claros.
Revisión de cómo las tablas de decisión ayudan a dialogar con negocio cuando una especificación en texto no es precisa.
Gestión de combinaciones explosivas mediante priorización basada en riesgo y eliminación de casos imposibles.
Integración de tablas de decisión con criterios de aceptación y pruebas automatizadas cuando el comportamiento es estable.
Elaboración de una tabla de decisión para una funcionalidad de aprobación con condiciones de importe, rol, país y tipo de cliente.
Tema 12: Caja negra III: transición de estados y pruebas de flujos
Aplicación de pruebas de transición de estados cuando el comportamiento depende del estado actual y de eventos que cambian ese estado.
Identificación de estados, eventos, transiciones válidas, transiciones inválidas, acciones y condiciones de bloqueo.
Modelado de ciclos de vida como pedido, ticket, contrato, incidencia, usuario, suscripción, pago, reserva o flujo de aprobación.
Diseño de casos que cubran transiciones principales, rutas alternativas, intentos no permitidos y estados finales.
Detección de defectos típicos: saltos de estado no autorizados, imposibilidad de volver, estados huérfanos o acciones permitidas tarde.
Uso de diagramas o tablas de transición para discutir flujos con negocio y desarrollo de forma visual.
Priorización de pruebas de estados según frecuencia de uso, impacto de negocio y riesgo de corrupción de datos.
Combinación de transición de estados con pruebas de permisos para validar quién puede ejecutar cada evento.
Diseño de pruebas de regresión cuando un cambio añade un nuevo estado o modifica una transición existente.
Creación de una práctica sobre un flujo de ticketing donde se prueban estados, roles, acciones y restricciones.
Tema 13: Caja blanca: cobertura de sentencias, ramas y estructura interna
Comprensión de pruebas de caja blanca como técnicas basadas en estructura interna del código, diseño o lógica de procesamiento.
Diferenciación entre cobertura de sentencias y cobertura de ramas, entendiendo qué información aporta cada una y qué no garantiza.
Diseño de casos para ejecutar líneas de código relevantes sin asumir que alta cobertura equivale a ausencia de defectos.
Identificación de ramas condicionales, decisiones, bucles y caminos que requieren atención en lógica crítica.
Revisión de cómo la cobertura ayuda a detectar código no probado, ramas muertas, condiciones no ejercitadas y huecos en tests unitarios.
Relación entre pruebas unitarias de desarrollo y técnicas de caja blanca, especialmente en lógica de negocio compleja.
Análisis de límites de la cobertura: puede ejecutar código sin comprobar resultados correctos o sin validar reglas de negocio.
Uso de métricas de cobertura como indicador de apoyo, no como objetivo aislado que incentive tests de baja calidad.
Coordinación entre QA y desarrollo para revisar cobertura de módulos críticos sin invadir responsabilidades del equipo técnico.
Creación de un ejemplo sencillo donde se diseñan pruebas para cubrir sentencias y ramas de una función con condiciones múltiples.
Tema 14: Técnicas basadas en experiencia: exploración, error guessing y checklist
Uso de error guessing para anticipar defectos probables a partir de experiencia, historial, conocimiento técnico y patrones de fallo recurrentes.
Diseño de pruebas exploratorias con misión clara, límites de tiempo, notas, evidencias y aprendizaje incremental sobre el producto.
Aplicación de checklist-based testing para cubrir riesgos conocidos sin escribir casos de prueba excesivamente detallados.
Diferenciación entre prueba exploratoria profesional e improvisación sin objetivo, sin registro y sin trazabilidad mínima.
Preparación de charters de exploración para investigar áreas de riesgo, flujos nuevos, integraciones, usabilidad o regresión sensible.
Uso de heurísticas para descubrir defectos de navegación, datos, permisos, errores, rendimiento percibido, accesibilidad o consistencia visual.
Captura de evidencias durante exploración: entorno, datos, pasos, vídeos, capturas, logs, condiciones y observaciones relevantes.
Priorización de exploración cuando hay requisitos incompletos, cambios recientes, funcionalidades complejas o poco tiempo para diseño formal.
Combinación de experiencia con técnicas formales para aumentar detección de defectos sin abandonar cobertura justificada.
Creación de una sesión de exploración guiada sobre una aplicación con defectos sembrados y documentación de hallazgos.
Tema 15: Enfoques colaborativos: historias, criterios, ATDD y BDD
Redacción de historias de usuario comprobables, con actor, necesidad, valor y alcance suficientemente claro para diseñar pruebas.
Mejora de criterios de aceptación mediante ejemplos concretos, reglas de negocio, casos límite, restricciones y resultados observables.
Uso de conversaciones Three Amigos para alinear negocio, desarrollo y testing antes de implementar.
Aplicación de ATDD para definir ejemplos de aceptación que guían el desarrollo y validan el comportamiento esperado.
Uso de BDD y lenguaje Gherkin cuando aporta claridad compartida entre perfiles técnicos y de negocio.
Diferenciación entre escribir escenarios útiles y convertir Gherkin en una capa burocrática que repite pasos de interfaz sin aportar valor.
Diseño de ejemplos que cubren reglas normales, excepciones, límites, permisos, datos inválidos y flujos alternativos.
Revisión de cómo los enfoques colaborativos reducen ambigüedad y defectos derivados de interpretaciones distintas.
Integración de escenarios colaborativos con automatización cuando el comportamiento es estable y aporta feedback recurrente.
Taller práctico para convertir una historia ambigua en criterios de aceptación, ejemplos y escenarios verificables.
Tema 16: Casos de prueba, datos de prueba y trazabilidad
Diseño de casos de prueba con precondiciones, pasos, datos, resultado esperado, prioridad, trazabilidad y criterios de evaluación.
Diferenciación entre condición de prueba, caso de prueba, procedimiento de prueba, dato de prueba y suite de prueba.
Creación de datos representativos para clientes, usuarios, permisos, importes, fechas, estados, errores y combinaciones relevantes.
Gestión de datos sensibles evitando usar información real no autorizada en entornos de prueba o documentos de evidencia.
Uso de trazabilidad para conectar requisitos, riesgos, casos, ejecuciones, defectos y criterios de salida.
Revisión de casos demasiado detallados que bloquean mantenimiento frente a casos demasiado vagos que no permiten reproducibilidad.
Preparación de suites por funcionalidad, riesgo, nivel, tipo de prueba, sprint, release o regresión.
Mantenimiento de casos cuando cambian requisitos, interfaz, reglas, datos o prioridades de negocio.
Identificación de pruebas candidatas a automatización por estabilidad, repetición, valor de regresión y coste de ejecución manual.
Creación de una matriz de trazabilidad para una funcionalidad con requisitos, riesgos, casos, ejecuciones y defectos.
Tema 17: Automatización de pruebas: alcance, criterios y límites
Comprensión de la automatización como apoyo al testing, no como sustituto completo del análisis, diseño, exploración y juicio humano.
Identificación de pruebas candidatas a automatizar: repetitivas, estables, críticas, de regresión frecuente y con resultado verificable.
Revisión de pruebas que suelen ser malas candidatas: funcionalidades volátiles, exploración, usabilidad subjetiva o flujos con datos inestables.
Relación entre automatización y pirámide de pruebas, equilibrando unitarias, integración, API, end-to-end y pruebas manuales.
Análisis de costes de automatización: creación, mantenimiento, falsos positivos, datos, entornos, flakiness y revisión de fallos.
Definición de criterios de diseño para pruebas automatizadas: independencia, claridad, velocidad, mantenibilidad y diagnóstico rápido.
Integración de pruebas automatizadas en pipelines CI/CD para aportar feedback temprano antes de promover cambios.
Revisión de herramientas habituales por nivel: frameworks unitarios, API testing, UI automation, contract testing y performance básico.
Gestión de resultados automatizados para que los fallos se investiguen y no se ignoren por ruido acumulado.
Preparación de una estrategia de automatización realista que combine valor, riesgo, frecuencia y capacidad técnica del equipo.
Tema 18: Gestión de actividades de prueba: planificación, estimación y control
Definición de objetivos, alcance, enfoque, recursos, entornos, datos, calendario, riesgos y entregables de prueba.
Selección de una estrategia de prueba alineada con criticidad, modelo de desarrollo, arquitectura, normativa, equipo y objetivos de negocio.
Estimación de esfuerzo de pruebas usando experiencia histórica, complejidad, riesgos, tamaño funcional, regresión y disponibilidad de entornos.
Diseño de criterios de entrada y salida para evitar comenzar pruebas sin condiciones mínimas o cerrar validaciones sin evidencia suficiente.
Planificación de ciclos de prueba, regresión, aceptación, smoke testing, pruebas exploratorias y validación de correcciones.
Monitorización del progreso con métricas útiles: casos preparados, casos ejecutados, bloqueos, defectos abiertos, cobertura y riesgos pendientes.
Control de desviaciones cuando se reduce alcance, falta entorno, se acumulan defectos o cambian requisitos en mitad de la validación.
Coordinación de pruebas con desarrollo, producto, soporte, operaciones, negocio y usuarios clave.
Creación de informes de avance que aporten información para decidir, no solo porcentajes vacíos de ejecución.
Elaboración de un plan de prueba ligero pero completo para una release corporativa con riesgos y dependencias reales.
Tema 19: Riesgos de producto y testing basado en riesgo
Comprensión del riesgo como combinación de probabilidad e impacto, aplicado a defectos que pueden afectar al producto o al proyecto.
Diferenciación entre riesgos de producto, riesgos de proyecto, riesgos técnicos, riesgos de negocio y riesgos operativos.
Identificación de áreas críticas mediante impacto en usuario, ingresos, cumplimiento, reputación, seguridad, datos y continuidad.
Priorización de pruebas según riesgo, evitando distribuir esfuerzo por igual en funcionalidades de valor y criticidad muy diferentes.
Uso de matrices de riesgo para decidir profundidad, técnica, tipo de prueba, entorno, datos y frecuencia de regresión.
Revisión de cómo los riesgos cambian durante el proyecto y deben actualizarse con defectos, cambios, feedback y nueva información.
Comunicación de riesgos residuales cuando no se puede probar todo con la profundidad deseada antes de una entrega.
Gestión de trade-offs entre fecha, cobertura, automatización, defectos abiertos y nivel de confianza.
Integración del testing basado en riesgo en contextos ágiles mediante refinamiento, sprint planning y revisión de prioridades.
Creación de un análisis de riesgos para una funcionalidad crítica y derivación de pruebas proporcionales.
Tema 20: Gestión de defectos: ciclo de vida, severidad, prioridad y análisis
Definición de defecto con información suficiente: título, entorno, versión, datos, pasos, resultado actual, resultado esperado y evidencias.
Diferenciación entre severidad técnica o funcional y prioridad de negocio, evitando discusiones por usar ambos conceptos como sinónimos.
Diseño de estados de defecto: nuevo, analizado, asignado, corregido, listo para retest, reabierto, cerrado, diferido o rechazado.
Revisión de causas de rechazo de defectos: no reproducible, comportamiento esperado, duplicado, fuera de alcance o información insuficiente.
Gestión de defectos duplicados, intermitentes, bloqueantes, regresivos y dependientes de configuración o datos.
Análisis de causa raíz para defectos relevantes, diferenciando síntoma visible y origen real en proceso, requisito, diseño, código o entorno.
Medición de defectos escapados a producción para mejorar revisiones, cobertura, datos, automatización y criterios de salida.
Creación de informes de defectos útiles para desarrollo, producto, soporte, dirección y mejora de proceso.
Definición de reuniones de triage donde se priorizan defectos con criterios de riesgo, impacto, coste y fecha de entrega.
Taller de redacción y clasificación de defectos para transformar hallazgos ambiguos en tickets accionables y reproducibles.
Tema 21: Métricas, reporting y seguimiento de la calidad
Selección de métricas que aportan información accionable sobre avance, riesgo, defectos, cobertura, estabilidad y preparación de entrega.
Revisión crítica de métricas engañosas como número bruto de casos ejecutados, porcentaje sin contexto o defectos contados sin severidad.
Uso de métricas de ejecución: casos planificados, ejecutados, bloqueados, fallidos, no aplicables y pendientes.
Uso de métricas de defectos: abiertos, cerrados, reabiertos, severidad, prioridad, edad, tendencia y defectos escapados.
Incorporación de métricas de calidad de proceso: retrabajo, defectos por fase, revisiones, automatización útil y tiempo de ciclo.
Preparación de dashboards que permitan tomar decisiones de release, no solo mostrar actividad del equipo.
Comunicación de estado de calidad con semáforos razonados, riesgos pendientes, bloqueos, recomendaciones y próximos pasos.
Definición de criterios de salida basados en evidencia, riesgos aceptados, defectos críticos, cobertura mínima y preparación operativa.
Revisión de cómo las métricas pueden distorsionar comportamientos si se usan para culpar o premiar cantidades sin valorar calidad.
Creación de un informe ejecutivo de calidad para una release con datos, interpretación, riesgos y recomendación de decisión.
Tema 22: Herramientas de soporte al testing y gestión de calidad
Revisión de categorías de herramientas: gestión de pruebas, defectos, requisitos, automatización, CI/CD, análisis estático, performance y observabilidad.
Identificación de cuándo una herramienta aporta valor y cuándo solo digitaliza un proceso mal definido.
Comparación funcional de herramientas habituales como Jira, Azure DevOps, TestRail, Xray, Zephyr, GitLab, SonarQube, Postman o Playwright.
Gestión de trazabilidad entre requisitos, historias, casos, ejecuciones, defectos, commits, builds y releases.
Evaluación de riesgos de herramienta: curva de aprendizaje, mantenimiento, bloqueo de proveedor, mala configuración y baja adopción.
Definición de criterios de selección: integración, permisos, reporting, escalabilidad, coste, usabilidad, auditoría y soporte corporativo.
Configuración de flujos mínimos para que la herramienta facilite trabajo real, no genere burocracia paralela.
Uso de plantillas, campos obligatorios y workflows para mejorar consistencia sin impedir agilidad.
Medición de adopción de herramientas mediante uso real, calidad de datos, reducción de retrabajo y mejora de visibilidad.
Creación de una matriz de herramientas recomendadas por necesidad, equipo, madurez, tipo de prueba y entorno técnico.
Tema 23: Testing de APIs, servicios e integraciones
Comprensión de las APIs como contratos entre sistemas que requieren pruebas de datos, errores, autenticación, rendimiento y compatibilidad.
Diseño de pruebas de endpoints con métodos, headers, payloads, códigos de estado, esquemas, validaciones y respuestas de error.
Aplicación de partición de equivalencia, límites y tablas de decisión a servicios REST o integraciones entre sistemas.
Validación de contratos mediante OpenAPI, ejemplos, mocks, contract testing o comparaciones entre consumidor y proveedor.
Pruebas de autenticación, autorización y permisos para evitar accesos indebidos a operaciones o datos.
Revisión de errores frecuentes: estados HTTP incorrectos, mensajes ambiguos, validaciones inconsistentes, datos parciales y cambios incompatibles.
Gestión de datos de prueba para APIs, evitando dependencias frágiles entre ejecuciones o uso de entornos productivos.
Integración de pruebas API en pipelines como capa rápida de regresión antes de pruebas UI más costosas.
Documentación de defectos de API con request, response, entorno, usuario, payload, correlación y resultado esperado.
Creación de una colección de pruebas API para un flujo corporativo con casos positivos, negativos, límites y permisos.
Tema 24: Testing no funcional: rendimiento, seguridad, usabilidad y accesibilidad
Comprensión de que la calidad no se limita a que una funcionalidad “funcione”, sino también a cómo se comporta bajo condiciones reales.
Identificación de características no funcionales relevantes según producto: rendimiento, seguridad, usabilidad, accesibilidad, fiabilidad y compatibilidad.
Diseño de pruebas iniciales de rendimiento con escenarios, carga esperada, tiempos de respuesta, capacidad y umbrales de aceptación.
Revisión de pruebas de seguridad desde una perspectiva de QA: autenticación, autorización, validación de entrada, exposición de datos y errores.
Evaluación de usabilidad mediante tareas reales, claridad de mensajes, navegación, prevención de errores y facilidad de aprendizaje.
Incorporación de accesibilidad básica: contraste, teclado, textos alternativos, foco visible, estructura y compatibilidad con lectores.
Priorización de pruebas no funcionales según riesgo, normativa, usuario final, exposición pública y criticidad del sistema.
Integración de controles no funcionales en Definition of Done, pipelines o revisiones tempranas cuando sea posible.
Identificación de límites del equipo QA y necesidad de especialistas en seguridad, rendimiento o accesibilidad para validaciones profundas.
Creación de una matriz de pruebas no funcionales para una aplicación web corporativa con criterios, herramientas y responsables.
Tema 25: Testing en mantenimiento, regresión y evolución continua
Gestión de pruebas cuando el producto ya está en producción y recibe cambios, correcciones, mejoras y refactorizaciones constantes.
Diseño de suites de regresión equilibradas para cubrir funciones críticas sin convertir cada release en una validación interminable.
Priorización de regresión según impacto del cambio, módulos tocados, defectos históricos, dependencias y riesgo de negocio.
Uso de análisis de impacto para decidir qué probar cuando cambia una API, una regla de negocio, una pantalla o una integración.
Mantenimiento de casos de prueba obsoletos, duplicados o frágiles para evitar que la suite pierda credibilidad.
Gestión de defectos reabiertos o regresivos como señal de problemas en cobertura, comunicación, automatización o revisión.
Integración de feedback de soporte y producción para reforzar casos de prueba que antes no existían.
Coordinación de pruebas con ventanas de despliegue, hotfixes, rollback y validaciones postdeploy.
Revisión de métricas de defectos escapados para ajustar estrategia de regresión y riesgos.
Diseño de un plan de regresión para una release incremental con cambios funcionales, técnicos y correcciones.
Tema 26: Calidad en equipos distribuidos, proveedores y proyectos externalizados
Definición de responsabilidades de calidad cuando intervienen proveedor, cliente, equipo interno, QA externo y usuarios de negocio.
Establecimiento de criterios de aceptación contractuales, evidencias de prueba, defectos, SLAs y entregables mínimos.
Revisión de riesgos cuando un proveedor entrega software sin trazabilidad, sin pruebas suficientes o con defectos mal documentados.
Creación de plantillas de reporte que permitan comparar avance, defectos, cobertura y riesgos entre equipos distintos.
Gestión de entornos, datos y accesos compartidos entre organizaciones sin comprometer seguridad ni confidencialidad.
Coordinación de pruebas de aceptación con usuarios clave, evitando que la validación final sea improvisada o puramente subjetiva.
Revisión de entregables de calidad en contratos: plan de pruebas, casos, evidencias, resultados, defectos y criterios de salida.
Integración de testing en modelos nearshore, offshore o equipos híbridos donde la comunicación asíncrona es crítica.
Definición de mecanismos de escalado para defectos bloqueantes, discrepancias de prioridad o incumplimiento de calidad.
Creación de un marco de colaboración donde la calidad es verificable, no una promesa informal del proveedor.
Tema 27: Ética, responsabilidad profesional y límites del tester
Comprensión de la responsabilidad del tester al comunicar riesgos, defectos y evidencias sin ocultar información relevante para la decisión.
Manejo de conflictos cuando negocio quiere liberar con defectos conocidos, fechas presionan o se minimizan riesgos críticos.
Diferenciación entre recomendar, informar y decidir, entendiendo que el tester aporta evidencia, pero la decisión de release puede ser de negocio.
Protección de datos durante pruebas, evitando usar información real de clientes, empleados o producción sin autorización.
Gestión responsable de accesos, credenciales, datos sensibles, capturas y evidencias almacenadas en herramientas de testing.
Revisión de implicaciones éticas en pruebas de IA, sesgos, accesibilidad, privacidad, seguridad y sistemas que afectan a personas.
Comunicación honesta de limitaciones: qué se probó, qué no se probó, qué riesgos quedan y qué confianza se puede tener.
Evitación de métricas manipuladas para aparentar avance, ocultar bloqueos o cerrar defectos sin validación real.
Fomento de una cultura donde reportar problemas temprano se valora como prevención, no como obstáculo a la entrega.
Creación de un código de conducta interno para pruebas, datos, evidencias, comunicación de riesgos y colaboración profesional.
Tema 28: Taller de síntesis: mapa de estudio y uso profesional de fundamentos ISTQB
Organización de los contenidos del curso según bloques de fundamentos, ciclo de vida, estático, diseño de pruebas, gestión y herramientas.
Relación de cada bloque con prácticas reales del puesto, evitando estudiar términos sin saber cómo aplicarlos en proyectos corporativos.
Revisión de conceptos clave que suelen generar confusión: error, defecto, fallo, verificación, validación, nivel, tipo, técnica y cobertura.
Creación de tarjetas de repaso para principios, niveles, técnicas, roles de revisión, defectos, métricas y herramientas.
Simulación de preguntas conceptuales para entrenar razonamiento, comprensión de vocabulario y selección de la respuesta más adecuada.
Aclaración de que esta formación ayuda a construir base, pero no sustituye un curso oficial acreditado ni materiales oficiales de preparación.
Identificación de temas que requieren práctica adicional si el objetivo personal del alumno es presentarse a un examen oficial.
Preparación de un plan de continuidad hacia automatización, testing ágil, QA avanzado, test management, rendimiento, seguridad o calidad DevOps.
Evaluación de madurez individual mediante checklist de competencias: diseñar pruebas, revisar requisitos, reportar defectos y comunicar calidad.
Creación de un compromiso de aplicación en el puesto para trasladar lo aprendido a procesos reales del equipo.
Tema 29: Proyecto final integrador: estrategia de pruebas y gestión de calidad para una release
Análisis de una funcionalidad completa con requisitos, historias, criterios de aceptación, riesgos, dependencias y restricciones de negocio.
Revisión estática de la documentación para detectar ambigüedades, contradicciones, omisiones y defectos antes de diseñar casos.
Definición de niveles y tipos de prueba necesarios, justificando qué se probará en componente, integración, sistema y aceptación.
Diseño de casos con partición de equivalencia, valores límite, tablas de decisión, transición de estados y pruebas basadas en experiencia.
Preparación de datos de prueba, precondiciones, resultados esperados y trazabilidad hacia requisitos, riesgos y criterios de aceptación.
Definición de un mini plan de prueba con alcance, enfoque, recursos, entorno, criterios de entrada, criterios de salida y calendario.
Creación de un modelo de gestión de defectos con severidad, prioridad, estados, evidencias y procedimiento de triage.
Selección de métricas e informe de seguimiento para comunicar avance, bloqueos, defectos, riesgos y recomendación de release.
Propuesta de herramientas de soporte y automatización candidatas según valor, frecuencia, estabilidad y coste de mantenimiento.
Presentación final ante un comité simulado de producto, desarrollo y negocio, defendiendo cobertura, riesgos residuales y decisión recomendada.
Forma a tu equipo sin coste para tu empresa. Este curso de ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad es hasta 100% bonificable a través de FUNDAE.
Potencia las competencias clave de tus profesionales.
Accede a una formación práctica, actualizada y orientada a resultados.
Prepara a tu equipo para los retos del entorno laboral actual.
Nos ocupamos de la gestión con FUNDAE si tu empresa lo necesita.
A medida
Formación en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad a medida
Descubre el mejor curso de ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad para empresas con nuestra Aula Virtual Personalizada:
Sesiones en vivo por videoconferencia.
Temario totalmente personalizado.
Fechas y horarios adaptados a tu empresa.
Acceso a grabaciones.
Aprende practicando
Totalmente Práctico y Aplicable
Formación diseñada para que apliques cada concepto en situaciones reales de tu trabajo, con enfoque práctico y útil desde el primer momento.
Aprendizaje 100% práctico, enfocado en lo que realmente necesitas.
Casos reales y ejercicios adaptados a tu entorno profesional.
Aplica cada conocimiento directamente en tus tareas diarias.
Mejora tu rendimiento y el de tu equipo desde el primer día.
¿Por qué un curso en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad?
Sirve como ayuda conceptual alineada con fundamentos reconocidos
Una plataforma practica, con IA integrada y pensada para que mejores desarrollando. Se adapta a tu ritmo, te corrige al instante y te muestra tu progreso real.
Correccion magica
Feedback inteligente
Aprende de cada acierto y fallo con explicaciones claras
Comprensión del testing como actividad orientada a aportar información sobre calidad, riesgo y confianza, no como una simple búsqueda final de errores.
Diferenciación entre probar para encontrar defectos, prevenir problemas, validar requisitos, apoyar decisiones y reducir incertidumbre del negocio.
Análisis de por qué el testing no puede demostrar ausencia total de defectos, sino aportar evidencia razonable según contexto, riesgo y cobertura.
Revisión de los siete principios clásicos de testing y su aplicación práctica en proyectos reales, evitando interpretaciones puramente memorísticas.
Identificación de errores humanos, defectos en productos de trabajo, fallos observables y causas raíz dentro del ciclo de vida del software.
Relación entre coste de corrección y momento de detección, mostrando por qué los defectos encontrados tarde suelen ser más caros y dañinos.
Separación entre verificación y validación para distinguir si el producto se construye correctamente y si realmente resuelve la necesidad esperada.
Reconocimiento del papel del tester como proveedor de información crítica para negocio, desarrollo, producto, soporte y dirección.
Evaluación de cómo el testing contribuye a confianza, cumplimiento, reputación, experiencia de usuario, seguridad, mantenibilidad y continuidad operativa.
Creación de una definición compartida de calidad para el equipo, alineada con producto, usuario, riesgo, negocio y contexto técnico.
Comprensión del testing como actividad orientada a aportar información sobre calidad, riesgo y confianza, no como una simple búsqueda final de errores.
Diferenciación entre probar para encontrar defectos, prevenir problemas, validar requisitos, apoyar decisiones y reducir incertidumbre del negocio.
Análisis de por qué el testing no puede demostrar ausencia total de defectos, sino aportar evidencia razonable según contexto, riesgo y cobertura.
Revisión de los siete principios clásicos de testing y su aplicación práctica en proyectos reales, evitando interpretaciones puramente memorísticas.
Identificación de errores humanos, defectos en productos de trabajo, fallos observables y causas raíz dentro del ciclo de vida del software.
Relación entre coste de corrección y momento de detección, mostrando por qué los defectos encontrados tarde suelen ser más caros y dañinos.
Separación entre verificación y validación para distinguir si el producto se construye correctamente y si realmente resuelve la necesidad esperada.
Reconocimiento del papel del tester como proveedor de información crítica para negocio, desarrollo, producto, soporte y dirección.
Evaluación de cómo el testing contribuye a confianza, cumplimiento, reputación, experiencia de usuario, seguridad, mantenibilidad y continuidad operativa.
Creación de una definición compartida de calidad para el equipo, alineada con producto, usuario, riesgo, negocio y contexto técnico.
Tema 1: Fundamentos del testing de software y valor real para la empresa
Comprensión del testing como actividad orientada a aportar información sobre calidad, riesgo y confianza, no como una simple búsqueda final de errores.
Diferenciación entre probar para encontrar defectos, prevenir problemas, validar requisitos, apoyar decisiones y reducir incertidumbre del negocio.
Análisis de por qué el testing no puede demostrar ausencia total de defectos, sino aportar evidencia razonable según contexto, riesgo y cobertura.
Revisión de los siete principios clásicos de testing y su aplicación práctica en proyectos reales, evitando interpretaciones puramente memorísticas.
Identificación de errores humanos, defectos en productos de trabajo, fallos observables y causas raíz dentro del ciclo de vida del software.
Relación entre coste de corrección y momento de detección, mostrando por qué los defectos encontrados tarde suelen ser más caros y dañinos.
Separación entre verificación y validación para distinguir si el producto se construye correctamente y si realmente resuelve la necesidad esperada.
Reconocimiento del papel del tester como proveedor de información crítica para negocio, desarrollo, producto, soporte y dirección.
Evaluación de cómo el testing contribuye a confianza, cumplimiento, reputación, experiencia de usuario, seguridad, mantenibilidad y continuidad operativa.
Creación de una definición compartida de calidad para el equipo, alineada con producto, usuario, riesgo, negocio y contexto técnico.
Tema 2: Psicología del testing, sesgos y colaboración entre roles
Comprensión de cómo sesgos cognitivos, familiaridad con el producto y presión por entregar pueden reducir la capacidad de detectar defectos relevantes.
Análisis de la independencia del testing, diferenciando autocontrol del desarrollador, revisión entre pares, QA independiente y validación externa.
Revisión de ventajas e inconvenientes de distintos niveles de independencia, evitando convertir la separación de roles en falta de colaboración.
Identificación de tensiones habituales entre QA y desarrollo: defectos discutidos, prioridades cambiantes, requisitos ambiguos y presión de fechas.
Desarrollo de habilidades de comunicación para reportar defectos con claridad, evidencia, reproducibilidad y tono profesional.
Creación de conversaciones orientadas a riesgo y valor, no a culpa, cuando aparece un defecto en una fase avanzada del proyecto.
Uso de revisiones, refinamientos y ejemplos compartidos para que la calidad se trabaje antes de que exista código ejecutable.
Reconocimiento del impacto de la cultura del equipo en la calidad: confianza, transparencia, aprendizaje, responsabilidad compartida y mejora continua.
Preparación de acuerdos de equipo sobre cuándo probar, quién revisa, cómo se priorizan defectos y qué significa “terminado”.
Construcción de una mentalidad donde testing no es un departamento al final, sino una actividad distribuida durante todo el desarrollo.
Tema 3: Testing dentro del ciclo de vida del desarrollo de software
Comparación entre modelos secuenciales, iterativos, incrementales, ágiles y DevOps, identificando cómo cambia la estrategia de prueba en cada caso.
Ubicación de actividades de prueba desde requisitos y diseño hasta desarrollo, integración, aceptación, despliegue y operación.
Revisión del concepto shift-left para detectar defectos antes, mediante revisiones, análisis de requisitos, pruebas tempranas y criterios de aceptación claros.
Análisis del concepto shift-right para aprender de producción mediante observabilidad, monitorización, feedback de usuarios e incidencias reales.
Relación entre testing y entregas frecuentes, donde el feedback rápido y la automatización ayudan a reducir riesgo en cambios pequeños.
Identificación de productos de trabajo que pueden probarse sin ejecutar código: historias, especificaciones, diseños, modelos, datos y documentación.
Diseño de actividades de prueba alineadas con cada fase: análisis, diseño, implementación, integración, validación, despliegue y mantenimiento.
Comprensión de cómo los cambios evolutivos, correcciones y refactorizaciones requieren pruebas de regresión proporcionales al riesgo.
Revisión de cómo la gestión de configuración permite saber qué versión se probó, con qué datos, en qué entorno y bajo qué condiciones.
Elaboración de un mapa de actividades de testing integrado en el ciclo real de la empresa, sin crear fases artificiales desconectadas.
Tema 4: Niveles de prueba: componente, integración, sistema y aceptación
Diferenciación entre pruebas de componente, integración, sistema y aceptación, atendiendo al objetivo, alcance, responsable y tipo de defecto esperado.
Diseño de pruebas de componente para validar unidades pequeñas de software con foco en lógica, límites, errores y comportamiento esperado.
Revisión de pruebas de integración para detectar fallos en interfaces, contratos, dependencias, APIs, colas, bases de datos y servicios externos.
Planificación de pruebas de sistema para evaluar el producto completo desde la perspectiva funcional y no funcional esperada.
Comprensión de pruebas de aceptación orientadas a usuarios, negocio, contrato, regulación o preparación para puesta en producción.
Identificación de pruebas alfa, beta, UAT, pruebas operacionales y validaciones internas según madurez y contexto del producto.
Relación entre nivel de prueba y entorno necesario, evitando validar integraciones críticas en entornos incompletos o datos no representativos.
Revisión de trazabilidad entre requisitos, historias, niveles de prueba, defectos y criterios de aceptación.
Detección de solapamientos y huecos cuando un equipo prueba muchas veces lo mismo, pero deja interfaces o riesgos sin cubrir.
Creación de una matriz de niveles de prueba para un producto realista, asignando objetivos, responsables, evidencias y riesgos.
Tema 5: Tipos de prueba funcionales, no funcionales, estructurales y asociados al cambio
Diferenciación entre pruebas funcionales, no funcionales, estructurales y pruebas relacionadas con cambios, según objetivo y tipo de información buscada.
Diseño de pruebas funcionales para comprobar reglas de negocio, flujos, validaciones, cálculos, permisos, estados y resultados visibles.
Revisión de pruebas no funcionales: rendimiento, usabilidad, accesibilidad, seguridad, compatibilidad, portabilidad, fiabilidad y mantenibilidad.
Comprensión de pruebas estructurales basadas en la arquitectura interna, código, ramas, rutas, componentes o cobertura.
Aplicación de pruebas de confirmación para verificar que un defecto corregido realmente deja de reproducirse.
Aplicación de pruebas de regresión para comprobar que un cambio no rompe funcionalidades existentes o dependencias relacionadas.
Análisis de cómo seleccionar tipos de prueba según riesgo, criticidad, impacto en usuario, tecnología y frecuencia de cambio.
Identificación de pruebas que deben automatizarse, pruebas que requieren exploración humana y pruebas que se ejecutan por muestreo.
Revisión de errores frecuentes: llamar “regresión” a cualquier prueba repetida o tratar pruebas no funcionales como actividad opcional al final.
Elaboración de una estrategia equilibrada de tipos de prueba para una aplicación corporativa con riesgos funcionales y operativos.
Tema 6: Testing en contextos ágiles, Scrum, Kanban y DevOps
Integración del testing dentro de sprints, refinamientos, planificación, desarrollo, revisión, retrospectiva y entrega incremental.
Uso de criterios de aceptación para convertir historias de usuario en unidades verificables, evitando ambigüedad y expectativas implícitas.
Participación de QA en refinamiento para detectar riesgos, dependencias, casos límite y escenarios no definidos antes de comenzar el desarrollo.
Definición de Definition of Ready y Definition of Done con criterios de calidad, pruebas, revisión, automatización y evidencias.
Diseño de pruebas en Kanban cuando el flujo se basa en trabajo continuo, límites WIP, políticas explícitas y entrega bajo demanda.
Conexión entre testing y DevOps mediante pipelines, automatización, feedback rápido, despliegues controlados y monitorización.
Revisión de cómo los equipos ágiles equilibran pruebas manuales, automatizadas, exploratorias y colaborativas en ciclos cortos.
Identificación de riesgos del falso “ágil”: probar al final del sprint, acumular deuda de calidad o saltarse pruebas por presión de entrega.
Uso de retrospectivas para mejorar proceso de prueba, defectos escapados, colaboración, entornos, datos y criterios de aceptación.
Creación de un flujo de calidad ágil donde QA aporta criterio desde el inicio sin convertirse en cuello de botella final.
Tema 7: Testing estático: detectar defectos antes de ejecutar software
Comprensión del testing estático como análisis de productos de trabajo sin ejecutar el software, incluyendo revisiones y análisis estático.
Identificación de productos revisables: requisitos, historias, criterios de aceptación, diseños, contratos API, código, modelos, datos y manuales.
Análisis del valor de detectar defectos antes de programar, cuando todavía es más barato corregir ambigüedad, inconsistencia o falta de cobertura.
Revisión de defectos típicos encontrados en estático: contradicciones, omisiones, ambigüedad, incumplimiento de estándares y casos límite olvidados.
Aplicación de checklists para revisar historias, requisitos, pantallas, APIs, reglas de negocio y documentación funcional.
Comparación entre revisión informal, walkthrough, revisión técnica e inspección, atendiendo a rigor, roles y evidencia generada.
Uso de análisis estático de código para detectar vulnerabilidades, complejidad, duplicidad, estilo, errores potenciales y deuda técnica.
Relación entre testing estático y shift-left, integrando revisiones en refinamiento, diseño y pull requests.
Prevención de discusiones improductivas mediante criterios claros, foco en el producto de trabajo y registro de defectos o acciones.
Creación de una práctica de revisión sobre una historia ambigua para identificar defectos antes de diseñar casos de prueba.
Tema 8: Revisiones eficaces: roles, proceso, checklist y seguimiento
Diseño de un proceso de revisión con planificación, preparación individual, reunión opcional, registro de hallazgos, corrección y cierre.
Definición de roles habituales: autor, moderador, revisores, escriba, responsable de seguimiento y observadores cuando procede.
Creación de criterios de entrada para evitar revisar documentos inmaduros, incompletos o sin contexto suficiente.
Uso de checklists específicas por producto de trabajo, evitando listas genéricas que no detectan problemas relevantes.
Priorización de hallazgos según severidad, impacto, probabilidad, coste de corrección y fase del ciclo de vida.
Seguimiento de acciones derivadas de la revisión para asegurar que los defectos encontrados se corrigen y no se archivan sin resolver.
Medición de eficacia de revisiones mediante defectos encontrados, retrabajo evitado, defectos escapados y tiempo invertido.
Integración de revisiones en pull requests, refinamientos, sesiones Three Amigos, diseño técnico o control documental.
Manejo de dinámicas humanas para que la revisión no se perciba como crítica personal al autor.
Construcción de un modelo de revisión ligero o formal según criticidad, regulación, complejidad y madurez del equipo.
Tema 9: Técnicas de diseño de pruebas: visión general y criterio de selección
Comprensión de las técnicas de prueba como métodos para derivar casos con más cobertura, menos improvisación y mejor justificación.
Diferenciación entre técnicas de caja negra, caja blanca, basadas en experiencia y colaborativas.
Selección de técnicas según tipo de requisito, nivel de prueba, riesgo, información disponible, tiempo, experiencia y criticidad.
Revisión de cómo las técnicas ayudan a encontrar defectos diferentes, por lo que no deben verse como opciones excluyentes.
Aplicación de técnicas para evitar probar solo el “camino feliz” y olvidar límites, combinaciones, estados o reglas alternativas.
Relación entre técnica, condición de prueba, caso de prueba, dato de prueba, resultado esperado y cobertura.
Diseño de casos de prueba con trazabilidad hacia requisitos, historias, riesgos o criterios de aceptación.
Identificación de cuándo una prueba debe ser manual, automatizada, exploratoria, revisada por negocio o integrada en pipeline.
Revisión de errores comunes: casos sin resultado esperado, datos poco realistas, pasos ambiguos y pruebas duplicadas sin valor.
Creación de una plantilla corporativa de caso de prueba que sea útil sin convertirse en burocracia innecesaria.
Tema 10: Caja negra I: partición de equivalencia y análisis de valores límite
Aplicación de partición de equivalencia para agrupar datos que deberían comportarse de forma similar y reducir pruebas redundantes.
Identificación de clases válidas e inválidas a partir de reglas de negocio, validaciones, rangos, formatos y restricciones de entrada.
Diseño de casos representativos para cada partición, explicando por qué un dato cubre un conjunto y no solo un ejemplo aislado.
Uso de análisis de valores límite para probar bordes donde suelen aparecer defectos: mínimos, máximos, justo dentro y justo fuera.
Revisión de reglas numéricas, fechas, importes, longitudes de texto, edades, cantidades, porcentajes y límites de configuración.
Combinación de equivalencia y límites para construir pruebas compactas pero con alta capacidad de detección de errores.
Detección de errores típicos: operadores `<` frente a `<=`, redondeos, validaciones inconsistentes y límites no documentados.
Diseño de datos de prueba que permitan reproducir claramente cada partición y cada valor límite seleccionado.
Aplicación práctica sobre un formulario corporativo con importes, fechas, estados, campos obligatorios y reglas de validación.
Documentación de cobertura para justificar qué particiones se probaron, cuáles no y por qué.
Tema 11: Caja negra II: tablas de decisión y pruebas de reglas de negocio
Uso de tablas de decisión para modelar combinaciones de condiciones y acciones cuando las reglas de negocio dependen de varios factores.
Identificación de condiciones, acciones, reglas válidas, combinaciones imposibles y resultados esperados.
Reducción de combinaciones redundantes manteniendo cobertura suficiente de reglas relevantes.
Aplicación a procesos de descuentos, elegibilidad, aprobación, permisos, cálculo de tarifas, estados de pedido o validaciones complejas.
Detección de reglas contradictorias, incompletas o ambiguas antes de implementar o ejecutar pruebas.
Diseño de casos de prueba a partir de reglas de la tabla, con datos, pasos y resultados esperados claros.
Revisión de cómo las tablas de decisión ayudan a dialogar con negocio cuando una especificación en texto no es precisa.
Gestión de combinaciones explosivas mediante priorización basada en riesgo y eliminación de casos imposibles.
Integración de tablas de decisión con criterios de aceptación y pruebas automatizadas cuando el comportamiento es estable.
Elaboración de una tabla de decisión para una funcionalidad de aprobación con condiciones de importe, rol, país y tipo de cliente.
Tema 12: Caja negra III: transición de estados y pruebas de flujos
Aplicación de pruebas de transición de estados cuando el comportamiento depende del estado actual y de eventos que cambian ese estado.
Identificación de estados, eventos, transiciones válidas, transiciones inválidas, acciones y condiciones de bloqueo.
Modelado de ciclos de vida como pedido, ticket, contrato, incidencia, usuario, suscripción, pago, reserva o flujo de aprobación.
Diseño de casos que cubran transiciones principales, rutas alternativas, intentos no permitidos y estados finales.
Detección de defectos típicos: saltos de estado no autorizados, imposibilidad de volver, estados huérfanos o acciones permitidas tarde.
Uso de diagramas o tablas de transición para discutir flujos con negocio y desarrollo de forma visual.
Priorización de pruebas de estados según frecuencia de uso, impacto de negocio y riesgo de corrupción de datos.
Combinación de transición de estados con pruebas de permisos para validar quién puede ejecutar cada evento.
Diseño de pruebas de regresión cuando un cambio añade un nuevo estado o modifica una transición existente.
Creación de una práctica sobre un flujo de ticketing donde se prueban estados, roles, acciones y restricciones.
Tema 13: Caja blanca: cobertura de sentencias, ramas y estructura interna
Comprensión de pruebas de caja blanca como técnicas basadas en estructura interna del código, diseño o lógica de procesamiento.
Diferenciación entre cobertura de sentencias y cobertura de ramas, entendiendo qué información aporta cada una y qué no garantiza.
Diseño de casos para ejecutar líneas de código relevantes sin asumir que alta cobertura equivale a ausencia de defectos.
Identificación de ramas condicionales, decisiones, bucles y caminos que requieren atención en lógica crítica.
Revisión de cómo la cobertura ayuda a detectar código no probado, ramas muertas, condiciones no ejercitadas y huecos en tests unitarios.
Relación entre pruebas unitarias de desarrollo y técnicas de caja blanca, especialmente en lógica de negocio compleja.
Análisis de límites de la cobertura: puede ejecutar código sin comprobar resultados correctos o sin validar reglas de negocio.
Uso de métricas de cobertura como indicador de apoyo, no como objetivo aislado que incentive tests de baja calidad.
Coordinación entre QA y desarrollo para revisar cobertura de módulos críticos sin invadir responsabilidades del equipo técnico.
Creación de un ejemplo sencillo donde se diseñan pruebas para cubrir sentencias y ramas de una función con condiciones múltiples.
Tema 14: Técnicas basadas en experiencia: exploración, error guessing y checklist
Uso de error guessing para anticipar defectos probables a partir de experiencia, historial, conocimiento técnico y patrones de fallo recurrentes.
Diseño de pruebas exploratorias con misión clara, límites de tiempo, notas, evidencias y aprendizaje incremental sobre el producto.
Aplicación de checklist-based testing para cubrir riesgos conocidos sin escribir casos de prueba excesivamente detallados.
Diferenciación entre prueba exploratoria profesional e improvisación sin objetivo, sin registro y sin trazabilidad mínima.
Preparación de charters de exploración para investigar áreas de riesgo, flujos nuevos, integraciones, usabilidad o regresión sensible.
Uso de heurísticas para descubrir defectos de navegación, datos, permisos, errores, rendimiento percibido, accesibilidad o consistencia visual.
Captura de evidencias durante exploración: entorno, datos, pasos, vídeos, capturas, logs, condiciones y observaciones relevantes.
Priorización de exploración cuando hay requisitos incompletos, cambios recientes, funcionalidades complejas o poco tiempo para diseño formal.
Combinación de experiencia con técnicas formales para aumentar detección de defectos sin abandonar cobertura justificada.
Creación de una sesión de exploración guiada sobre una aplicación con defectos sembrados y documentación de hallazgos.
Tema 15: Enfoques colaborativos: historias, criterios, ATDD y BDD
Redacción de historias de usuario comprobables, con actor, necesidad, valor y alcance suficientemente claro para diseñar pruebas.
Mejora de criterios de aceptación mediante ejemplos concretos, reglas de negocio, casos límite, restricciones y resultados observables.
Uso de conversaciones Three Amigos para alinear negocio, desarrollo y testing antes de implementar.
Aplicación de ATDD para definir ejemplos de aceptación que guían el desarrollo y validan el comportamiento esperado.
Uso de BDD y lenguaje Gherkin cuando aporta claridad compartida entre perfiles técnicos y de negocio.
Diferenciación entre escribir escenarios útiles y convertir Gherkin en una capa burocrática que repite pasos de interfaz sin aportar valor.
Diseño de ejemplos que cubren reglas normales, excepciones, límites, permisos, datos inválidos y flujos alternativos.
Revisión de cómo los enfoques colaborativos reducen ambigüedad y defectos derivados de interpretaciones distintas.
Integración de escenarios colaborativos con automatización cuando el comportamiento es estable y aporta feedback recurrente.
Taller práctico para convertir una historia ambigua en criterios de aceptación, ejemplos y escenarios verificables.
Tema 16: Casos de prueba, datos de prueba y trazabilidad
Diseño de casos de prueba con precondiciones, pasos, datos, resultado esperado, prioridad, trazabilidad y criterios de evaluación.
Diferenciación entre condición de prueba, caso de prueba, procedimiento de prueba, dato de prueba y suite de prueba.
Creación de datos representativos para clientes, usuarios, permisos, importes, fechas, estados, errores y combinaciones relevantes.
Gestión de datos sensibles evitando usar información real no autorizada en entornos de prueba o documentos de evidencia.
Uso de trazabilidad para conectar requisitos, riesgos, casos, ejecuciones, defectos y criterios de salida.
Revisión de casos demasiado detallados que bloquean mantenimiento frente a casos demasiado vagos que no permiten reproducibilidad.
Preparación de suites por funcionalidad, riesgo, nivel, tipo de prueba, sprint, release o regresión.
Mantenimiento de casos cuando cambian requisitos, interfaz, reglas, datos o prioridades de negocio.
Identificación de pruebas candidatas a automatización por estabilidad, repetición, valor de regresión y coste de ejecución manual.
Creación de una matriz de trazabilidad para una funcionalidad con requisitos, riesgos, casos, ejecuciones y defectos.
Tema 17: Automatización de pruebas: alcance, criterios y límites
Comprensión de la automatización como apoyo al testing, no como sustituto completo del análisis, diseño, exploración y juicio humano.
Identificación de pruebas candidatas a automatizar: repetitivas, estables, críticas, de regresión frecuente y con resultado verificable.
Revisión de pruebas que suelen ser malas candidatas: funcionalidades volátiles, exploración, usabilidad subjetiva o flujos con datos inestables.
Relación entre automatización y pirámide de pruebas, equilibrando unitarias, integración, API, end-to-end y pruebas manuales.
Análisis de costes de automatización: creación, mantenimiento, falsos positivos, datos, entornos, flakiness y revisión de fallos.
Definición de criterios de diseño para pruebas automatizadas: independencia, claridad, velocidad, mantenibilidad y diagnóstico rápido.
Integración de pruebas automatizadas en pipelines CI/CD para aportar feedback temprano antes de promover cambios.
Revisión de herramientas habituales por nivel: frameworks unitarios, API testing, UI automation, contract testing y performance básico.
Gestión de resultados automatizados para que los fallos se investiguen y no se ignoren por ruido acumulado.
Preparación de una estrategia de automatización realista que combine valor, riesgo, frecuencia y capacidad técnica del equipo.
Tema 18: Gestión de actividades de prueba: planificación, estimación y control
Definición de objetivos, alcance, enfoque, recursos, entornos, datos, calendario, riesgos y entregables de prueba.
Selección de una estrategia de prueba alineada con criticidad, modelo de desarrollo, arquitectura, normativa, equipo y objetivos de negocio.
Estimación de esfuerzo de pruebas usando experiencia histórica, complejidad, riesgos, tamaño funcional, regresión y disponibilidad de entornos.
Diseño de criterios de entrada y salida para evitar comenzar pruebas sin condiciones mínimas o cerrar validaciones sin evidencia suficiente.
Planificación de ciclos de prueba, regresión, aceptación, smoke testing, pruebas exploratorias y validación de correcciones.
Monitorización del progreso con métricas útiles: casos preparados, casos ejecutados, bloqueos, defectos abiertos, cobertura y riesgos pendientes.
Control de desviaciones cuando se reduce alcance, falta entorno, se acumulan defectos o cambian requisitos en mitad de la validación.
Coordinación de pruebas con desarrollo, producto, soporte, operaciones, negocio y usuarios clave.
Creación de informes de avance que aporten información para decidir, no solo porcentajes vacíos de ejecución.
Elaboración de un plan de prueba ligero pero completo para una release corporativa con riesgos y dependencias reales.
Tema 19: Riesgos de producto y testing basado en riesgo
Comprensión del riesgo como combinación de probabilidad e impacto, aplicado a defectos que pueden afectar al producto o al proyecto.
Diferenciación entre riesgos de producto, riesgos de proyecto, riesgos técnicos, riesgos de negocio y riesgos operativos.
Identificación de áreas críticas mediante impacto en usuario, ingresos, cumplimiento, reputación, seguridad, datos y continuidad.
Priorización de pruebas según riesgo, evitando distribuir esfuerzo por igual en funcionalidades de valor y criticidad muy diferentes.
Uso de matrices de riesgo para decidir profundidad, técnica, tipo de prueba, entorno, datos y frecuencia de regresión.
Revisión de cómo los riesgos cambian durante el proyecto y deben actualizarse con defectos, cambios, feedback y nueva información.
Comunicación de riesgos residuales cuando no se puede probar todo con la profundidad deseada antes de una entrega.
Gestión de trade-offs entre fecha, cobertura, automatización, defectos abiertos y nivel de confianza.
Integración del testing basado en riesgo en contextos ágiles mediante refinamiento, sprint planning y revisión de prioridades.
Creación de un análisis de riesgos para una funcionalidad crítica y derivación de pruebas proporcionales.
Tema 20: Gestión de defectos: ciclo de vida, severidad, prioridad y análisis
Definición de defecto con información suficiente: título, entorno, versión, datos, pasos, resultado actual, resultado esperado y evidencias.
Diferenciación entre severidad técnica o funcional y prioridad de negocio, evitando discusiones por usar ambos conceptos como sinónimos.
Diseño de estados de defecto: nuevo, analizado, asignado, corregido, listo para retest, reabierto, cerrado, diferido o rechazado.
Revisión de causas de rechazo de defectos: no reproducible, comportamiento esperado, duplicado, fuera de alcance o información insuficiente.
Gestión de defectos duplicados, intermitentes, bloqueantes, regresivos y dependientes de configuración o datos.
Análisis de causa raíz para defectos relevantes, diferenciando síntoma visible y origen real en proceso, requisito, diseño, código o entorno.
Medición de defectos escapados a producción para mejorar revisiones, cobertura, datos, automatización y criterios de salida.
Creación de informes de defectos útiles para desarrollo, producto, soporte, dirección y mejora de proceso.
Definición de reuniones de triage donde se priorizan defectos con criterios de riesgo, impacto, coste y fecha de entrega.
Taller de redacción y clasificación de defectos para transformar hallazgos ambiguos en tickets accionables y reproducibles.
Tema 21: Métricas, reporting y seguimiento de la calidad
Selección de métricas que aportan información accionable sobre avance, riesgo, defectos, cobertura, estabilidad y preparación de entrega.
Revisión crítica de métricas engañosas como número bruto de casos ejecutados, porcentaje sin contexto o defectos contados sin severidad.
Uso de métricas de ejecución: casos planificados, ejecutados, bloqueados, fallidos, no aplicables y pendientes.
Uso de métricas de defectos: abiertos, cerrados, reabiertos, severidad, prioridad, edad, tendencia y defectos escapados.
Incorporación de métricas de calidad de proceso: retrabajo, defectos por fase, revisiones, automatización útil y tiempo de ciclo.
Preparación de dashboards que permitan tomar decisiones de release, no solo mostrar actividad del equipo.
Comunicación de estado de calidad con semáforos razonados, riesgos pendientes, bloqueos, recomendaciones y próximos pasos.
Definición de criterios de salida basados en evidencia, riesgos aceptados, defectos críticos, cobertura mínima y preparación operativa.
Revisión de cómo las métricas pueden distorsionar comportamientos si se usan para culpar o premiar cantidades sin valorar calidad.
Creación de un informe ejecutivo de calidad para una release con datos, interpretación, riesgos y recomendación de decisión.
Tema 22: Herramientas de soporte al testing y gestión de calidad
Revisión de categorías de herramientas: gestión de pruebas, defectos, requisitos, automatización, CI/CD, análisis estático, performance y observabilidad.
Identificación de cuándo una herramienta aporta valor y cuándo solo digitaliza un proceso mal definido.
Comparación funcional de herramientas habituales como Jira, Azure DevOps, TestRail, Xray, Zephyr, GitLab, SonarQube, Postman o Playwright.
Gestión de trazabilidad entre requisitos, historias, casos, ejecuciones, defectos, commits, builds y releases.
Evaluación de riesgos de herramienta: curva de aprendizaje, mantenimiento, bloqueo de proveedor, mala configuración y baja adopción.
Definición de criterios de selección: integración, permisos, reporting, escalabilidad, coste, usabilidad, auditoría y soporte corporativo.
Configuración de flujos mínimos para que la herramienta facilite trabajo real, no genere burocracia paralela.
Uso de plantillas, campos obligatorios y workflows para mejorar consistencia sin impedir agilidad.
Medición de adopción de herramientas mediante uso real, calidad de datos, reducción de retrabajo y mejora de visibilidad.
Creación de una matriz de herramientas recomendadas por necesidad, equipo, madurez, tipo de prueba y entorno técnico.
Tema 23: Testing de APIs, servicios e integraciones
Comprensión de las APIs como contratos entre sistemas que requieren pruebas de datos, errores, autenticación, rendimiento y compatibilidad.
Diseño de pruebas de endpoints con métodos, headers, payloads, códigos de estado, esquemas, validaciones y respuestas de error.
Aplicación de partición de equivalencia, límites y tablas de decisión a servicios REST o integraciones entre sistemas.
Validación de contratos mediante OpenAPI, ejemplos, mocks, contract testing o comparaciones entre consumidor y proveedor.
Pruebas de autenticación, autorización y permisos para evitar accesos indebidos a operaciones o datos.
Revisión de errores frecuentes: estados HTTP incorrectos, mensajes ambiguos, validaciones inconsistentes, datos parciales y cambios incompatibles.
Gestión de datos de prueba para APIs, evitando dependencias frágiles entre ejecuciones o uso de entornos productivos.
Integración de pruebas API en pipelines como capa rápida de regresión antes de pruebas UI más costosas.
Documentación de defectos de API con request, response, entorno, usuario, payload, correlación y resultado esperado.
Creación de una colección de pruebas API para un flujo corporativo con casos positivos, negativos, límites y permisos.
Tema 24: Testing no funcional: rendimiento, seguridad, usabilidad y accesibilidad
Comprensión de que la calidad no se limita a que una funcionalidad “funcione”, sino también a cómo se comporta bajo condiciones reales.
Identificación de características no funcionales relevantes según producto: rendimiento, seguridad, usabilidad, accesibilidad, fiabilidad y compatibilidad.
Diseño de pruebas iniciales de rendimiento con escenarios, carga esperada, tiempos de respuesta, capacidad y umbrales de aceptación.
Revisión de pruebas de seguridad desde una perspectiva de QA: autenticación, autorización, validación de entrada, exposición de datos y errores.
Evaluación de usabilidad mediante tareas reales, claridad de mensajes, navegación, prevención de errores y facilidad de aprendizaje.
Incorporación de accesibilidad básica: contraste, teclado, textos alternativos, foco visible, estructura y compatibilidad con lectores.
Priorización de pruebas no funcionales según riesgo, normativa, usuario final, exposición pública y criticidad del sistema.
Integración de controles no funcionales en Definition of Done, pipelines o revisiones tempranas cuando sea posible.
Identificación de límites del equipo QA y necesidad de especialistas en seguridad, rendimiento o accesibilidad para validaciones profundas.
Creación de una matriz de pruebas no funcionales para una aplicación web corporativa con criterios, herramientas y responsables.
Tema 25: Testing en mantenimiento, regresión y evolución continua
Gestión de pruebas cuando el producto ya está en producción y recibe cambios, correcciones, mejoras y refactorizaciones constantes.
Diseño de suites de regresión equilibradas para cubrir funciones críticas sin convertir cada release en una validación interminable.
Priorización de regresión según impacto del cambio, módulos tocados, defectos históricos, dependencias y riesgo de negocio.
Uso de análisis de impacto para decidir qué probar cuando cambia una API, una regla de negocio, una pantalla o una integración.
Mantenimiento de casos de prueba obsoletos, duplicados o frágiles para evitar que la suite pierda credibilidad.
Gestión de defectos reabiertos o regresivos como señal de problemas en cobertura, comunicación, automatización o revisión.
Integración de feedback de soporte y producción para reforzar casos de prueba que antes no existían.
Coordinación de pruebas con ventanas de despliegue, hotfixes, rollback y validaciones postdeploy.
Revisión de métricas de defectos escapados para ajustar estrategia de regresión y riesgos.
Diseño de un plan de regresión para una release incremental con cambios funcionales, técnicos y correcciones.
Tema 26: Calidad en equipos distribuidos, proveedores y proyectos externalizados
Definición de responsabilidades de calidad cuando intervienen proveedor, cliente, equipo interno, QA externo y usuarios de negocio.
Establecimiento de criterios de aceptación contractuales, evidencias de prueba, defectos, SLAs y entregables mínimos.
Revisión de riesgos cuando un proveedor entrega software sin trazabilidad, sin pruebas suficientes o con defectos mal documentados.
Creación de plantillas de reporte que permitan comparar avance, defectos, cobertura y riesgos entre equipos distintos.
Gestión de entornos, datos y accesos compartidos entre organizaciones sin comprometer seguridad ni confidencialidad.
Coordinación de pruebas de aceptación con usuarios clave, evitando que la validación final sea improvisada o puramente subjetiva.
Revisión de entregables de calidad en contratos: plan de pruebas, casos, evidencias, resultados, defectos y criterios de salida.
Integración de testing en modelos nearshore, offshore o equipos híbridos donde la comunicación asíncrona es crítica.
Definición de mecanismos de escalado para defectos bloqueantes, discrepancias de prioridad o incumplimiento de calidad.
Creación de un marco de colaboración donde la calidad es verificable, no una promesa informal del proveedor.
Tema 27: Ética, responsabilidad profesional y límites del tester
Comprensión de la responsabilidad del tester al comunicar riesgos, defectos y evidencias sin ocultar información relevante para la decisión.
Manejo de conflictos cuando negocio quiere liberar con defectos conocidos, fechas presionan o se minimizan riesgos críticos.
Diferenciación entre recomendar, informar y decidir, entendiendo que el tester aporta evidencia, pero la decisión de release puede ser de negocio.
Protección de datos durante pruebas, evitando usar información real de clientes, empleados o producción sin autorización.
Gestión responsable de accesos, credenciales, datos sensibles, capturas y evidencias almacenadas en herramientas de testing.
Revisión de implicaciones éticas en pruebas de IA, sesgos, accesibilidad, privacidad, seguridad y sistemas que afectan a personas.
Comunicación honesta de limitaciones: qué se probó, qué no se probó, qué riesgos quedan y qué confianza se puede tener.
Evitación de métricas manipuladas para aparentar avance, ocultar bloqueos o cerrar defectos sin validación real.
Fomento de una cultura donde reportar problemas temprano se valora como prevención, no como obstáculo a la entrega.
Creación de un código de conducta interno para pruebas, datos, evidencias, comunicación de riesgos y colaboración profesional.
Tema 28: Taller de síntesis: mapa de estudio y uso profesional de fundamentos ISTQB
Organización de los contenidos del curso según bloques de fundamentos, ciclo de vida, estático, diseño de pruebas, gestión y herramientas.
Relación de cada bloque con prácticas reales del puesto, evitando estudiar términos sin saber cómo aplicarlos en proyectos corporativos.
Revisión de conceptos clave que suelen generar confusión: error, defecto, fallo, verificación, validación, nivel, tipo, técnica y cobertura.
Creación de tarjetas de repaso para principios, niveles, técnicas, roles de revisión, defectos, métricas y herramientas.
Simulación de preguntas conceptuales para entrenar razonamiento, comprensión de vocabulario y selección de la respuesta más adecuada.
Aclaración de que esta formación ayuda a construir base, pero no sustituye un curso oficial acreditado ni materiales oficiales de preparación.
Identificación de temas que requieren práctica adicional si el objetivo personal del alumno es presentarse a un examen oficial.
Preparación de un plan de continuidad hacia automatización, testing ágil, QA avanzado, test management, rendimiento, seguridad o calidad DevOps.
Evaluación de madurez individual mediante checklist de competencias: diseñar pruebas, revisar requisitos, reportar defectos y comunicar calidad.
Creación de un compromiso de aplicación en el puesto para trasladar lo aprendido a procesos reales del equipo.
Tema 29: Proyecto final integrador: estrategia de pruebas y gestión de calidad para una release
Análisis de una funcionalidad completa con requisitos, historias, criterios de aceptación, riesgos, dependencias y restricciones de negocio.
Revisión estática de la documentación para detectar ambigüedades, contradicciones, omisiones y defectos antes de diseñar casos.
Definición de niveles y tipos de prueba necesarios, justificando qué se probará en componente, integración, sistema y aceptación.
Diseño de casos con partición de equivalencia, valores límite, tablas de decisión, transición de estados y pruebas basadas en experiencia.
Preparación de datos de prueba, precondiciones, resultados esperados y trazabilidad hacia requisitos, riesgos y criterios de aceptación.
Definición de un mini plan de prueba con alcance, enfoque, recursos, entorno, criterios de entrada, criterios de salida y calendario.
Creación de un modelo de gestión de defectos con severidad, prioridad, estados, evidencias y procedimiento de triage.
Selección de métricas e informe de seguimiento para comunicar avance, bloqueos, defectos, riesgos y recomendación de release.
Propuesta de herramientas de soporte y automatización candidatas según valor, frecuencia, estabilidad y coste de mantenimiento.
Presentación final ante un comité simulado de producto, desarrollo y negocio, defendiendo cobertura, riesgos residuales y decisión recomendada.
Aulas Virtuales Personalizadas
¿Te imaginas tener un Temario 100% Personalizado para tu Empresa?
¿A quién va dirigida esta formación en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad?
Pensado para quienes deben dominar ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad en su día a día
Testers, QA Engineers y perfiles de calidad
Este curso encaja con profesionales que participan directamente en la validación de software y necesitan consolidar un enfoque riguroso de testing. Aprenderán a distinguir objetivos, niveles, tipos, técnicas, criterios de cobertura, gestión de defectos, trazabilidad, riesgos y métricas para pasar de probar “a ojo” a diseñar pruebas con intención, evidencia y valor.
Desarrolladores backend, frontend y full stack
Los equipos de desarrollo podrán comprender mejor cómo se diseñan pruebas útiles, por qué aparecen defectos, cómo mejorar la testabilidad del código y cómo colaborar con QA desde fases tempranas. La formación les ayuda a escribir software más verificable, participar en revisiones y reducir retrabajo antes de llegar a validación final.
Product Owners, analistas funcionales y perfiles de negocio
Los perfiles de producto y análisis aprenderán a formular requisitos, criterios de aceptación, ejemplos y escenarios de forma más comprobable. El curso les ayuda a colaborar en enfoques como ATDD, BDD, revisiones tempranas y análisis de riesgos, reduciendo ambigüedad antes de que el equipo desarrolle o pruebe.
Scrum Masters, Project Managers y responsables de entrega
Los perfiles de gestión podrán entender cómo planificar, monitorizar y controlar actividades de prueba en proyectos tradicionales, ágiles o DevOps. La formación aporta criterios para interpretar métricas, priorizar riesgos, gestionar defectos, revisar criterios de salida y evitar que la calidad se mida solo al final.
Equipos DevOps, SRE y plataformas de entrega
Los equipos orientados a delivery continuo podrán conectar testing con pipelines, automatización, despliegues frecuentes, feedback rápido, observabilidad y calidad en producción. El curso no se limita a pruebas manuales, sino que integra testing dentro de un flujo moderno de entrega y operación.
Responsables de calidad, auditoría y mejora de procesos
Los perfiles que supervisan calidad de software, cumplimiento, auditoría interna o mejora continua encontrarán una base estructurada para definir procesos de prueba, evidencias, trazabilidad, defectos, métricas y criterios de aceptación. El curso permite elevar la madurez del testing sin imponer burocracia innecesaria.
Proveedor con 16 años de experiencia en formación empresarial
Sobre
En Imagina Formación llevamos más de 16 años ayudando a profesionales y empresas a mejorar sus habilidades con formación práctica y totalmente adaptada a sus necesidades. Durante este tiempo, hemos formado a más de 480.000 personas y colaborado con más de 3.500 empresas, convirtiéndonos en un referente en el sector.
16
Años de liderazgo
+480.000
Alumnos formados en Imagina
¿Tienes dudas?
Resolvemos todas tus dudas sobre nuestra formación en ISTQB - Testing, Técnicas de Prueba y Gestión de Calidad
Explora las respuestas a las preguntas que guian a nuestra comunidad. Aqui encontraras claridad sobre como funciona todo, desde el acceso hasta los detalles de los cursos. Si buscas respuestas, este es el lugar para comenzar.
No. El curso está inspirado en los fundamentos públicos del nivel Foundation de ISTQB y ayuda a adquirir una base útil, pero no sustituye una formación oficial acreditada ni garantiza la superación de ningún examen ofrecido por partners oficiales.
Sí, se toma como referencia conceptual para no dejar fuera los bloques habituales de fundamentos de testing, ciclo de vida, testing estático, diseño de pruebas, gestión de actividades de prueba y herramientas. El enfoque, sin embargo, es corporativo y aplicado al puesto.
Es útil para ambos. Los testers profundizan en diseño, gestión y técnicas de prueba; los desarrolladores entienden mejor cobertura, defectos, pruebas unitarias, revisiones, testabilidad y colaboración con QA desde fases tempranas.
No es imprescindible. El curso empieza por fundamentos, vocabulario y principios, pero avanza hacia técnicas y gestión profesional. Ayuda haber participado en proyectos de software, incidencias, validaciones, soporte o entregas.
Sí. Se trabajan partición de equivalencia, análisis de valores límite, tablas de decisión, transición de estados, cobertura de sentencias, cobertura de ramas, testing exploratorio, error guessing, checklist-based testing y enfoques colaborativos.
Sí. El curso incluye Scrum, Kanban, Definition of Done, criterios de aceptación, ATDD, BDD, pipelines, automatización, feedback rápido, shift-left, shift-right, observabilidad y relación entre testing y delivery continuo.
Sí. Se trabaja el ciclo de vida del defecto, severidad, prioridad, triage, causa raíz, defectos escapados, métricas de ejecución, métricas de defectos, reporting, criterios de salida y comunicación ejecutiva de calidad.
Es práctico. Cada bloque incorpora aplicación a casos reales: revisión de requisitos, diseño de casos, matrices de riesgo, defectos, métricas, criterios de aceptación, estrategia de pruebas y un proyecto final integrador.
El curso puede adaptarse a Jira, Azure DevOps, TestRail, Xray, Zephyr, Confluence, GitLab, SonarQube, Postman u otras herramientas corporativas. Lo importante es aprender el criterio antes de depender de una herramienta concreta.
Sí. Al tratarse de una formación corporativa en testing, calidad de software, gestión de defectos, herramientas y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.
No. El curso está inspirado en los fundamentos públicos del nivel Foundation de ISTQB y ayuda a adquirir una base útil, pero no sustituye una formación oficial acreditada ni garantiza la superación de ningún examen ofrecido por partners oficiales.
Sí, se toma como referencia conceptual para no dejar fuera los bloques habituales de fundamentos de testing, ciclo de vida, testing estático, diseño de pruebas, gestión de actividades de prueba y herramientas. El enfoque, sin embargo, es corporativo y aplicado al puesto.
Es útil para ambos. Los testers profundizan en diseño, gestión y técnicas de prueba; los desarrolladores entienden mejor cobertura, defectos, pruebas unitarias, revisiones, testabilidad y colaboración con QA desde fases tempranas.
No es imprescindible. El curso empieza por fundamentos, vocabulario y principios, pero avanza hacia técnicas y gestión profesional. Ayuda haber participado en proyectos de software, incidencias, validaciones, soporte o entregas.
Sí. Se trabajan partición de equivalencia, análisis de valores límite, tablas de decisión, transición de estados, cobertura de sentencias, cobertura de ramas, testing exploratorio, error guessing, checklist-based testing y enfoques colaborativos.
Sí. El curso incluye Scrum, Kanban, Definition of Done, criterios de aceptación, ATDD, BDD, pipelines, automatización, feedback rápido, shift-left, shift-right, observabilidad y relación entre testing y delivery continuo.
Sí. Se trabaja el ciclo de vida del defecto, severidad, prioridad, triage, causa raíz, defectos escapados, métricas de ejecución, métricas de defectos, reporting, criterios de salida y comunicación ejecutiva de calidad.
Es práctico. Cada bloque incorpora aplicación a casos reales: revisión de requisitos, diseño de casos, matrices de riesgo, defectos, métricas, criterios de aceptación, estrategia de pruebas y un proyecto final integrador.
El curso puede adaptarse a Jira, Azure DevOps, TestRail, Xray, Zephyr, Confluence, GitLab, SonarQube, Postman u otras herramientas corporativas. Lo importante es aprender el criterio antes de depender de una herramienta concreta.
Sí. Al tratarse de una formación corporativa en testing, calidad de software, gestión de defectos, herramientas y competencias digitales, puede plantearse como formación bonificable hasta el 100% a través de FUNDAE, según el crédito disponible y cumpliendo los requisitos administrativos aplicables.