ISTQB® Certified Tester Foundation Level 4.0 (CTFL)

Menú de estudio de ISTQB® Certified Tester Foundation Level 4.0 (CTFL): teoría, objetivos, práctica, flashcards, simulacro y examen final.

📘 6 capítulos 🧠 Preguntas: 400 ⏱️ Simulacro 60 min / aprueba 26/40
CTFL 4.0 · Capítulo 5

Gestión de las Actividades de Prueba

Incluye planificación, estimación, priorización, criterios de entrada/salida, pirámide de pruebas, cuadrantes, gestión de riesgos, monitoreo, control, informes, configuración y defectos.

16 objetivos LO335 min15 términos clave

Planificación y control

La gestión de pruebas permite convertir objetivos de calidad en trabajo organizado. Incluye planificar, estimar, priorizar, monitorear, controlar, reportar y cerrar.

  • Plan de prueba: objetivos, alcance, enfoque, recursos, cronograma, riesgos, criterios y comunicación.
  • Entrada: condiciones para iniciar; salida: condiciones para terminar.
  • Estimación puede apoyarse en expertos, consenso, métricas o fórmula de tres puntos.
  • Priorización considera riesgo, valor, dependencias, cobertura y restricciones.

Riesgos

El riesgo combina probabilidad e impacto. La gestión de riesgos ayuda a concentrar el esfuerzo de prueba donde más valor produce.

  • Riesgo de producto: afecta la calidad del producto, por ejemplo cálculo incorrecto o vulnerabilidad.
  • Riesgo de proyecto: afecta la ejecución, por ejemplo ambiente no disponible o falta de personal.
  • El análisis de riesgo influye en profundidad, técnicas, prioridad y cobertura.
  • Mitigar con pruebas puede implicar expertos, independencia, revisiones, análisis estático y pruebas dinámicas.

Informes, configuración y defectos

El estado de pruebas debe comunicarse con datos, riesgo e impacto. La gestión de configuración asegura que versiones, ambientes y testware estén controlados. La gestión de defectos convierte fallas observadas en información accionable.

  • Métricas: avance, calidad del producto, defectos, cobertura, riesgos y costos.
  • Informe de prueba: debe adaptarse a su audiencia.
  • Gestión de configuración: identifica versiones y mantiene trazabilidad.
  • Informe de defecto: pasos, datos, esperado/actual, ambiente, evidencia, severidad y prioridad.

Términos clave

plan de pruebaenfoque de pruebacriterio de entradacriterio de salidaestimaciónpriorizaciónpirámide de pruebascuadrantes de pruebariesgo de productoriesgo de proyectomonitoreocontrolinforme de pruebagestión de configuracióninforme de defecto

Objetivos de aprendizaje

  1. FL-5.1.1 · K2Ejemplificar propósito y contenido de plan de prueba

    El plan de prueba describe objetivos, recursos, procesos, alcance, enfoque, cronograma, riesgos, criterios, responsabilidades y comunicación.

  2. FL-5.1.2 · K1Reconocer cómo el probador aporta en planificación

    El tester aporta en planificación identificando riesgos, comprobabilidad, datos, ambientes, criterios, dependencias, estimaciones y alcance de regresión.

  3. FL-5.1.3 · K2Comparar criterios de entrada y salida

    Criterios de entrada indican si se puede iniciar; criterios de salida/compleción indican si se puede finalizar una actividad o nivel.

  4. FL-5.1.4 · K3Usar técnicas de estimación

    Estimación puede usar expertos, analogía, métricas, extrapolación, planning poker o tres puntos. Tres puntos pondera el caso más probable.

  5. FL-5.1.5 · K3Aplicar priorización de casos de prueba

    Priorizar casos decide qué ejecutar primero considerando riesgo, valor, dependencias, cobertura, historial de defectos y restricciones.

  6. FL-5.1.6 · K1Recordar pirámide de prueba

    La pirámide de prueba sugiere muchas pruebas de bajo nivel rápidas y automatizables, y menos pruebas end-to-end costosas en la cima.

  7. FL-5.1.7 · K2Resumir cuadrantes de prueba

    Los cuadrantes ágiles organizan pruebas según si apoyan al equipo o critican el producto, y si son de negocio o tecnológicas.

  8. FL-5.2.1 · K1Identificar nivel de riesgo con probabilidad e impacto

    Riesgo es efecto de incertidumbre sobre objetivos. Su nivel se evalúa combinando probabilidad e impacto.

  9. FL-5.2.2 · K2Distinguir riesgo de proyecto y producto

    Riesgo de producto afecta la calidad del producto; riesgo de proyecto afecta la ejecución del proyecto o de las pruebas.

  10. FL-5.2.3 · K2Explicar cómo análisis de riesgo influye en pruebas

    El análisis de riesgo guía qué probar más, qué técnicas usar, qué nivel de cobertura pedir y cómo priorizar esfuerzo.

  11. FL-5.2.4 · K2Explicar respuestas a riesgos de producto

    Control de riesgos de producto incluye mitigación mediante pruebas, aceptación, transferencia o contingencia. Mitigar con pruebas ajusta personas, independencia, técnicas, niveles y cobertura.

  12. FL-5.3.1 · K1Recordar métricas usadas en pruebas

    Métricas de prueba pueden medir progreso, calidad del producto, defectos, riesgos, cobertura y costos.

  13. FL-5.3.2 · K2Resumir informes de prueba

    Los informes de prueba comunican estado durante y después de pruebas. Deben adaptarse a la audiencia y apoyar decisiones.

  14. FL-5.3.3 · K2Comunicar estado de pruebas

    Comunicar estado implica presentar progreso, calidad, riesgos, bloqueos y recomendación usando el medio adecuado al contexto.

  15. FL-5.4.1 · K2Resumir cómo configuración apoya pruebas

    Gestión de configuración identifica, versiona y relaciona objetos de prueba, testware, ambientes y documentación para mantener control y trazabilidad.

  16. FL-5.5.1 · K3Preparar informe de defecto

    Un informe de defecto debe permitir reproducir, entender impacto y decidir prioridad. Incluye resumen, pasos, datos, esperado/actual, ambiente, evidencia, severidad, prioridad y referencias.

Errores frecuentes

  • Riesgo de producto afecta la calidad del producto; riesgo de proyecto afecta la ejecución del proyecto.
  • Entrada indica si podemos empezar; salida indica si podemos terminar.
  • Monitoreo observa avance contra plan; control toma acciones correctivas.
  • Un defecto bien reportado debe permitir reproducir, priorizar y resolver.

Ejemplos aplicados

  • Si el host de autorización no está disponible, es riesgo de proyecto; si el cálculo de IVA puede fallar, es riesgo de producto.
  • Un bug de transacción debe incluir ambiente, versión, pasos, datos usados, resultado esperado/actual, evidencia y severidad.