Curso Certificación ISTQB Versión 2018

¿Qué es probar?:

 Un software que no funcione correctamente puede generar perdidas de dinero, tiempo y

reputación en el ámbito del negocio.
 Probar un software es evaluar la calidad y reducir el riesgo de fallos en la operación.
 El proceso de pruebas incluyen la planificación, análisis, diseño e implementación pruebas.
Informar el avance y resultados de la prueba; y evaluar la calidad del objeto de prueba.
 Pruebas Estáticas: NO implican la ejecución del componente o sistema.
 Pruebas Dinámicas: implican la ejecución del componente o sistema.
 Las pruebas incluyen la revisión de casos de uso, requisitos, historias de usuario y código
fuente.

Objetivos de las pruebas:

 Evaluar productos tales como requerimientos, historias de usuario, diseño y código.

 Verificar el cumplimiento de los requerimientos.
 Validar si el objeto de prueba está completo y funciona de acuerdo con las expectativas
del cliente.
 Generar confianza a nivel de calidad en el software
 Prevenir defectos.
 Encontrar fallas y defectos.
 Proporcionar información para la toma de decisiones.
 Reducir el nivel de riesgo de calidad inadecuada en el software.
 Cumplir con normas o requisitos contractuales y verificar el cumplimiento de dichos
requerimientos o normas contractuales.

Prueba: la ejecución de pruebas puede mostrar tantos fallos causados por defectos del software.
Depuración: es la actividad de desarrollo que encuentra, analiza y corrige dichos defectos.
Prueba confirmación: comprueba si las correcciones han resuelto los defectos.

¿Por qué es necesario Probar?:

 Es necesario para reducir los riesgos que produzcan defectos en la puesta a producción.
 Reduce el riesgo de que se desarrollen funcionalidades incorrectas o que no puedan ser
probadas.
 Reduce el riesgo de defectos fundamentales de diseño y permitir la identificación de
pruebas en una fase temprana.
 Reduce el riesgo de defectos dentro del código y de la prueba.
 Aumenta la probabilidad de que el software cumpla con las necesidades y expectativas de
las partes involucradas.

Gestión de la Calidad:

Error: una acción humana que produce un incorrecto resultado.

Defecto: falta o bug

Fallo:

Iterativo: Que se repite varias veces.

Principios de las pruebas:

 La prueba muestra la presencia de defectos, no su ausencia: la prueba puede mostrar

la presencia de defectos, pero no puede probar que no hay defectos.
 La prueba exhaustiva es imposible: no es posible probar todas las condiciones de
entrada y precondiciones. Utilizar las técnicas de pruebas para optimizar los
escenarios a probar teniendo en cuenta el riesgo de la prueba.
 La prueba temprana ahorra tiempo y dinero: las actividades de pruebas tanto
estáticas como dinámicas deben iniciarse lo mas pronto posible en el ciclo de vida de
desarrollo del software. La prueba temprana se denomina “desplazamiento hacia la
izquierda”. Esto permite reducir o eliminar cambios costosos.
 Los defectos se agrupan: esto se refiere a que un pequeño modulo desarrollado
contiene la mayoría de los defectos descubiertos durante la prueba previa al
lanzamiento. Esto permite realizar un análisis de riesgos para centrar el esfuerzo de la
prueba.
 La paradoja del pesticida: no realizar las mismas pruebas una y otra vez, ya que esto
no identificara los nuevos defectos. Para ello se deberá cambiar los datos, escenarios
para que sean más efectivos)
 La prueba depende del contexto: se debe identificar los contextos de prueba, ya que
no es lo mismo probar un software de medicina y realizar las mismas pruebas a uno de
créditos comerciales.
 La ausencia de errores es una falacia: no se reduce el riesgo de que existan nuevos
errores y se asegure el éxito de un sistema cuando se realizan mil pruebas y todas
sean corregidas.
Proceso de prueba: no existe un único proceso de pruebas y universal. El conjunto de actividades
corresponden a un proceso de prueba. Dichas actividades se ven influidas por los siguientes
factores de contexto dentro de una organización:

 Modelo de ciclo de vida de desarrollo del software y metodologías de proyecto en uso.

 Niveles y tipos de prueba considerados.
 Riesgos de producto y de proyecto.
 Dominio del negocio.
 Restricciones operativas, incluyendo pero no limitadas a: presupuestos o recursos, plazos,
complejidad, Requisitos contractuales y normativos.
 Políticas y prácticas de la organización.
 Estándares internos y externos necesarios.

Las secciones que describen los aspectos generales de los procesos de prueba en una organización
son:

 Actividades y tareas de prueba.

 Productos de trabajo de prueba.
 Trazabilidad entre la base de prueba y los productos de trabajo de la prueba.

*El desarrollo ágil implica pequeñas interacciones de diseño, construcción y prueba de software
que se realizan de forma continua, con el apoyo de una planificación continua.

* La secuencia lógica escalonada de actividades implicara superposición, combinación,

concurrencia u omisión, por lo que es necesario adaptar las actividades principales dentro del
contexto del proyecto.

Es útil si se tiene definidos los criterios de cobertura medibles que a su vez pueden actual
eficazmente como indicadores clave de desempeño (KPI´s). Un proceso de pruebas consiste en los
siguientes grupos de actividades principales:

1. Planificación de la prueba:
Actividades: define objetivos y el enfoque para cumplir con los objetivos de la prueba
dentro de las restricciones impuestas por el contexto (especificaciones técnicas, tareas de
prueba adecuadas, cronograma de pruebas).
Productos: uno o más planes de prueba, donde incluye información sobre la base de
prueba.
2. Monitorización y control de la prueba:
Actividades: la monitorización implica el seguimiento continuo del cumplimiento respecto
al plan de prueba. El control implica tomar las medidas necesarias para cumplir los
objetivos del plan de prueba. Estas dos actividades se apoyan en la evaluación de los
criterios de salida. La evaluación de dichos criterios pueden incluir: comprobar resultados
y registros de prueba en relación con los criterios de cobertura especificados. Evaluar el
nivel de calidad de los componentes y determinar si se necesitan más pruebas.
Productos: informes de avance de prueba, resumen de prueba y resultados de ejecución.

3. Análisis de la prueba (Es el Que Probar?):

Actividades: corresponde al análisis base de la prueba (especificaciones de requisitos de
negocio, funcionales, de sistema, historias de usuario, casos de uso donde se especifique
el comportamiento funcional o no funcional deseado del componente o sistema.), evaluar
la base prueba y los elementos de prueba para identificar defectos de distintos tipos
(ambigüedades, omisiones, inconsistencias, inexactitudes, contradicciones, enunciados
superfluos), identificar los conjuntos y prestaciones que se van a probar, definir y priorizar
las condiciones de prueba, realizar la trazabilidad de pruebas.
Productos: condiciones de prueba definidas y priorizadas. Para pruebas exploratorias
implica la creación de contratos de prueba. Puede dar lugar al descubrimiento y
notificación de los defectos de la base de prueba.

4. Diseño de la prueba (Es el Como Probar?):

Actividades: diseñar y priorizar casos de prueba y conjuntos de casos de prueba,
identificar los datos de prueba necesarios para apoyar las condiciones de prueba y los
casos, diseñar el entorno de prueba e identificar la infraestructura y las herramientas
necesarias, realizar la trazabilidad de las condiciones de prueba, casos de prueba y
procedimientos.
Productos: casos de prueba y conjuntos de caso.

5. Implementación de la prueba (¿Está todo preparado para realizar la prueba?):

Actividades: desarrollar y priorizar procedimiento de prueba (crear guiones de prueba
automatizados), crear juegos de prueba a partir de los procedimientos de prueba,
organizar los casos dentro del cronograma de ejecución, construir el entorno de prueba,
preparar los datos y realizar la trazabilidad de estos.
Productos: procedimientos de prueba y secuenciación de dichos procedimientos de
prueba, juegos de prueba y calendario de ejecución de pruebas.
 6. Ejecución de la prueba:
Actividades: registrar los identificadores, versiones de elementos, herramientas de prueba
y productos de prueba. Ejecutar pruebas de forma manual o utilizando herramientas de
ejecución de pruebas. Comparar los resultados obtenidos con los esperados. Analizar las
anomalías para establecer sus causas probables. Informar sobre los defectos. Registrar el
resultado de las pruebas. Ejecutar pruebas de regresión, confirmación o corregida si es
necesario. Hacer trazabilidad de estos.
Productos: Documentación sobre el estado de casos de prueba individuales o
procedimientos de prueba (pendiente, finalizados, bloqueado, etc.), informes de defectos,
documentación sobre elementos, objetos, herramientas y productos de prueba.

7. Compleción (completar) de la prueba:

Actividades: comprobar que todos los informes de defectos estén cerrados creando un
informe de prueba que se comunique a los implicados. Finalizar, archivar, documentar el
diseño y ejecución de pruebas. Traspaso a producción sobre la funcionalidad desarrollada,
probada y certificada. Analizar las lecciones aprendidas para determinar los cambios
necesarios por interacciones, lanzamientos y proyectos futuros. Utilizar la información
recopilada para mejorar la madurez del proceso de prueba.
Productos: informes de resumen de prueba, elementos de acción, solicitudes de cambio
y/o productos de prueba finalizados.

Trazabilidad entre la Base de prueba y productos de trabajo de la prueba: es importante

establecer una trazabilidad a lo largo del proceso de prueba, lo que permite

 Analizar el impacto de cambios.

 Hacer que la prueba pueda ser auditada.
 Cumplimiento de los criterios de gobernanza de TI.
 Mejora la compresión de informes de avance de la prueba.
 Relaciona los aspectos técnicos de la prueba.
 Aportar información para evaluar la calidad.

Psicológica humana y proceso de pruebas: las formas de comunicarse de manera adecuada

incluyen los siguientes ejemplos:

 Comenzar con colaboración en lugar de batallas.

 Enfatizar los beneficios de las pruebas.
 Comunicar los resultados y hallazgos de forma neutral sin criticar a la persona.
 Tratar de entender cómo se siente la otra persona
 Hay que confirmar que la persona haya entendido el mensaje correctamente.
Formas de pensar del probador y del desarrollador: la mentalidad de un probador debe incluir
curiosidad, pesimismo profesional, sentido crítico, atención al detalle y motivación para una
comunicación. La mentalidad de un desarrollador puede incluir algunas del probador, pero se
caracterizan por estar mas interesados en el diseño y construcción de soluciones.

Modelo de Ciclo de Vida del Desarrollo de Software: describe los tipos de actividad que se
realizan en cada etapa de un proyecto de desarrollo de software, y como las actividades se
relacionan entre si de forma lógica y cronológica. Hay diferentes modelos de ciclo de vida de
desarrollo de software, cada uno de los cuales requiere diferentes enfoques de prueba.

Desarrollo de software y prueba de software: en cualquier modelo de ciclo de vida de desarrollo

de software hay una serie de características que hacen que las pruebas sean adecuadas:

 Para cada actividad de desarrollo, debe incluir una de pruebas.

 Cada nivel de pruebas tiene objetivos específicos para ese nivel.
 El análisis y diseño de la prueba para un nivel de prueba comienza durante la actividad de
desarrollo correspondiente.
 Los probadores participan en discusiones para definir y refinar los requisitos, diseños y
están involucrados en la revisión de productos de trabajo tan pronto como las versiones
borrador estén disponibles.

* Independientemente del modelo que se elija las actividades de prueba deben comenzar en las
etapas iniciales del ciclo de vida, adhiriéndose al principio de prueba temprana. Existen los
siguientes modelos de ciclo de vida:

 Modelos de desarrollo secuencial: contiene el conjunto completo de prestaciones, pero

normalmente requieren meses o años para su entrega a los implicados y usuarios.
 Modelos de desarrollo iterativos e incrementales.

Un modelo de desarrollo secuencial describe el proceso de desarrollo de software como un flujo

lineal y secuencial de actividades. Esto significa que cualquier fase del proceso de desarrollo debe
comenzar cuando se haya completado la fase anterior. En teoría no hay solapamiento de fases
pero en la practica es beneficioso tener una retroalimentación temprana de la fase siguiente.

El modelo en cascada, las actividades de desarrollo (análisis de requerimientos, diseño,

codificación, prueba) se completan una tras otra. En este modelo, las actividades de prueba solo
ocurren después de que todas las demás actividades de desarrollo hayan sido completadas.

El modelo en V integra los procesos de prueba a lo largo del proceso de desarrollo,

implementando el principio de prueba temprana. En este modelo, la ejecución de las pruebas
asociadas a cada nivel de prueba tiene lugar de forma secuencial, pero en algunos casos se
producen solapamientos.
El desarrollo incremental implica establecer requisitos, diseñar, construir y probar un sistema en
fragmentos, lo que significa que las prestaciones del software crecen de forma incremental.

El desarrollo iterativo implica especificar, diseñar, construir y probar conjuntamente grupos de

prestaciones en una serie de ciclos a menudo de duración fija. Ejemplo: Scrum, cada iteración
tiende a ser relativamente corta (días, semanas, meses)

Diferencia de los modelos secuenciales, los modelos iterativos e incrementales pueden ofrecer
software utilizable en semanas o inclusos días, pero solo pueden ofrecer el conjunto completo de
requisitos durante un periodo de meses o incluso años.

Modelo de Ciclo de Vida del Desarrollo de Software en Contexto: el modelo debe seleccionarse y
adaptarse al contexto de las características del proyecto y del producto en función del objetivo del
proyecto, el tipo de producto que se esta desarrollando, las prioridades de negocio y riesgos del
producto.

Niveles de prueba: son grupo de actividades de prueba que se organizan y gestionan

conjuntamente, los niveles de prueba utilizados en este programa de estudio son: prueba de
componente, integración, sistema y aceptación. Se caracterizan por los siguientes atributos:
objetivos específicos, bases de prueba (para generar casos de prueba), objetos de prueba (lo que
se esta probando, defectos y fallos característicos, enfoques y responsabilidades específicos.

Prueba de Componente (o prueba unitaria o de modulo): se centra en los componentes que se

tienen que probar por separado. Objetivos: reducir el riesgo, verificar comportamientos
funcionales y no funcionales, generar confianza en la calidad, encontrar defectos, prevenir la
propagación de defectos a niveles superiores. Se realiza de forma aislada, lo que puede requerir
objetos simulados, stubs y controladores. Base de prueba: diseño detallado, código, modelo de
datos, especificaciones de los componentes. En general es el desarrollador quien prueba el código.

Prueba de Integración: se centra en las interacciones entre componentes o sistemas. Objetivos:

reducir el riesgo, verificar comportamientos funcionales y no funcionales sean diseñados y
especificado, generar confianza en la calidad, encontrar defectos. Hay dos niveles de prueba de
integración:

 Integración de Componentes: en general se realiza después de la prueba de componente y

es automatizada formando parte del proceso de integración continua. Responsabilidad del
desarrollador
 Integración de Sistemas: la compañía de desarrollo no controla las interfaces externas y
puede realizarse después de la prueba de sistema o en paralelo. (para cualquier modelo).
Responsabilidad del Probador.
Prueba de Sistema: se centra en el comportamiento y las capacidades de todo un sistema o
producto. Objetivos: verificar comportamientos funcionales y no funcionales son los diseñados y
especificados. La prueba de sistema genera información clave para el lanzamiento del proyecto.
También puede satisfacer requisitos o estándares legales o regulatorios. El entorno de prueba
suele ser en condiciones al mismo de producción. Los probadores independientes suelen llevar a
cabo este tipo de pruebas.

Prueba de Aceptación: se centra en el comportamiento de un sistema o producto. Objetivos:

establecer confianza en el producto, validar que el sistema este completo y funcionara como se
espera, verificar especificaciones funcionales y no funcionales. Las formas comunes de prueba de
aceptación son las siguientes: aceptación por usuarios UAT, operativa, contractual y de regulación
y prueba alfa (se realiza en las instalaciones del desarrollador) y beta (se realiza en las
instalaciones del cliente).