ASEGURAMIENTO DE LA CALIDAD

DE SOFTWARE
ING. MSC. RENATO CASTILLO GALDO
¿DE DÓNDE VIENEN LOS DEFECTOS Y QUÉ ES LO
QUE OCASIONAN?
• La gente comete errores los cuales crean defectos en el sistema.
• Requisitos y especificaciones de diseño.
• Código /lógica de negocios e interfaz de usuario)
• Documentación (electrónica e impresa)
• Cuando un código defectuoso es ejecutado ocurren fallas.
• Si estas fallas son visibles a los clientes, usuarios u otros interesados, podrían
resultar en insatisfacción con la calidad del sistema.
¿DE DÓNDE VIENEN LOS DEFECTOS Y LAS FALLAS?

• Los defectos ocurren debido a:

• Falibilidad de programadores, analistas y otros colaboradores individuales (incluyendo a
los probadores)
• Presión de tiempo.
• Complejidad del código, infraestructura o problemas a ser resueltos.
• Las tecnologías cambian continuamente y deben engranar.
• Muchas interacciones del sistema.
¿DE DÓNDE VIENEN LOS DEFECTOS Y LAS FALLAS?

• Las fallas ocurren debido a defectos y:

• Condiciones del entorno.
• Uso incorrecto (deliberado o accidental).
LAS PRUEBAS HACEN GESTIÓN DE RIESGOS DE
CALIDAD
• Debido a los defectos y fallas un sistema está sujeto a varios riesgos.
• Riesgo: es un factor que podría resultar en futuras consecuencias negativas,
usualmente expresado como el impacto y la probabilidad.
• Existen otros riesgos y restricciones para un proyecto de software (Riesgo de
Proyecto), que las pruebas no pueden gestionar.
LAS PRUEBAS HACEN GESTIÓN DE RIESGOS DE
CALIDAD
• Las pruebas gestionan los riesgos de calidad de varias maneras:
• Las pruebas proporcionan la información para guiar al proyecto, reducir y gestionar los
riesgos y reparar los problemas importantes.
• Las pruebas pueden también abordar las necesidades de cumplimiento, contractuales y
reguladoras.
¿QUÉ SIGNIFICA CALIDAD ?
• Dos definiciones: “aptitud para el uso “ vs “conformidad con los requisitos”
• ¿Cómo se relacionan las Pruebas con la Calidad?
• Las Pruebas dan confianza donde ellas encuentran pocos defectos.
• Las pruebas pasadas correctamente reducen el nivel de riesgo de calidad.
• Las pruebas fallidas proporcionan una oportunidad para mejorar la calidad.
• El conjunto de pruebas con cobertura adecuada proporcionan una evaluación de la
calidad.
ALGUNOS TÉRMINOS IMPORTANTES
• BUG
• Defecto
• Error
• Falla
• Falta
• Equivocación
• Calidad
• Riesgo
OBJETIVOS DE LAS PRUEBAS
• Encontrar defectos y proporcionar a los programadores con la información
que ellos necesitan para corregir defectos importantes.
• Ganar confianza acerca del nivel de calidad del sistema.
• Prevenir defectos (a través de la participación temprana en las revisiones y el
diseño anticipado de las pruebas).
• Proporcionar la información acerca de los aspectos más importantes de la
calidad del sistema sometido a prueba.
• Ayudar a la gerencia a comprender la calidad del sistema.
OBJETIVOS DE LAS PRUEBAS

• Los objetivos de las pruebas escogidos no son tan importantes como el

alineamiento de sus planes y acciones con los objetivos de las pruebas
establecidos por la gerencia.
NIVELES Y OBJETIVOS DE LAS PRUEBAS
• Pruebas de Unidad/ de Componente: Encuentran defectos en partes
individuales del sistema sometido a pruebas antes de que las partes sean
integradas en el sistema.
• Pruebas de Integración / Cadena: Encuentran defectos en las relaciones e
interfaces entre pares y grupos de componentes en el sistema sometido a
pruebas a medida que las partes van juntándose.
• Pruebas de Sistema: Encuentran defectos en los comportamientos, funciones y
respuestas totales y parciales del sistema sometido a pruebas como un todo.
NIVELES Y OBJETIVOS DE LAS PRUEBAS
• Pruebas de aceptación / Piloto: Demuestran que el producto está listo para
su despliegue / versión o para evaluar la calidad y dar información acerca
del riesgo de despliegue / versión.
• Pruebas de mantenimiento: Comprueban los defectos introducidos durante el
desarrollo de los cambios.
• Pruebas Operacionales: Evalúan las características del sistema no funcionales
tales como la fiabilidad o disponibilidad usualmente en el entorno operativo.
EFECTIVIDAD Y EFICIENCIA
• Efectivo: Producir un resultado
decidido, decisivo, o deseado;
impresionante.
• Para ser probadores efectivos
debemos seleccionar el objetivo
apropiado y los resultados
deseados.
• Eficiente: Productivo del efecto
deseado: especialmente
productivo sin desperdicio.
• Para ser probadores eficientes,
debemos distribuir los recursos
(tiempo y dinero)
apropiadamente.
PRUEBAS VS DEPURACIÓN

• Las pruebas encuentran fallas que son causadas por los defectos.
• La depuración:
• Identifica la causa raíz de un defecto.
• Repara el código.
• Comprueba que el defecto haya sido corregido correctamente.
• Las pruebas de confirmación (repetición de pruebas) aseguran que la
corrección resuelve las fallas observadas.
LAS PRUEBAS SON MÁS QUE LA EJECUCIÓN DE
PRUEBAS
• Un problema común para los grupos de pruebas es cuando ellos piensan en
las pruebas meramente como la ejecución de pruebas contra el sistema.
• El proceso de pruebas no es solo la ejecución de pruebas contra un sistema
ejecutándose.
LAS PRUEBAS SON MÁS QUE LA EJECUCIÓN DE
PRUEBAS
• Otras actividades de pruebas, antes y después de la ejecución incluyen:
• Planificar y controlar.
• Escoger condiciones de pruebas.
• Diseñar casos de pruebas.
• Comprobar resultados de pruebas.
• Evaluar criterios de salida.
• Informar resultados de pruebas.
• Tareas de cierre / fin de la prueba.
RELACIÓN ENTRE PRUEBAS, ASEGURAMIENTO DE LA
CALIDAD Y EL MEJORAMIENTO DE LA CALIDAD
• Los grupos de pruebas son con frecuencia referidos erróneamente como
grupos de “aseguramiento de la calidad” o grupos de ”QA”.
• Idealmente, las pruebas son parte de una estrategia más grande del
aseguramiento de la calidad para un proyecto y en toda la organización.
• Para proyectos futuros, analice las causas raíz de los defectos encontrados en
los proyectos actuales y siga los pasos para reducir su incidencia y mejorar la
calidad.
PRINCIPIOS GENERALES DE LAS PRUEBAS
• Las pruebas revelan la presencia de defectos.
• La imposibilidad de pruebas exhaustivas.
• Los beneficios de las pruebas tempranas.
• La aglomeración de defectos: la agrupación de defectos.
• La paradoja del pesticida.
• Las pruebas deberían adaptarse a necesidades específicas.
• La falacia de la ausencia de errores.
PROCESOS DE PRUEBAS

• No existe un único proceso universal de prueba de software.

• El conjunto de actividades de prueba que permitan lograr el objetivo son un
proceso de prueba
PROCESOS DE PRUEBAS

El proceso de
pruebas de
software depende
de muchos
factores:
PROCESOS DE PRUEBAS
PROCESOS DE PRUEBAS
NIVELES DE PRUEBAS
ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Defectos típicos
Pruebas
Componente • Diseño • Componentes, • Funcionamiento
detallado unidades o incorrecto.
• Código módulos • Problemas de
• Modelo de • Estructuras de flujo de datos.
Datos código y datos. • Código y lógica
• Especificaciones • Clases. incorrectos.
de los • Módulos de
componentes base de datos.
ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Defectos típicos
Pruebas
Integración • Diseño de software • Subsistemas • Datos incorrectos,
y sistemas. • Bases de datos datos faltantes o
• Diagrama de • Infraestructura codificación de datos
secuencia. • Interfaces incorrecta.
• Especificaciones de • API • Secuencia o
interfaz y protocolo • Microservicios temporización
de comunicación. incorrecta de las
• Casos de uso llamadas a la
interfaz.
• Incompatibilidad de
la interfaz.
 ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Defectos típicos
Pruebas
Integración • Arquitectura a • Subsistemas • Fallas en la comunicación entre
nivel de • Bases de componentes.
componente o datos • Fallas en la comunicación entre
sistema. • Infraestruct componentes no manejadas o mal
• Flujos de ura manejadas.
trabajo. • Interfaces • Suposiciones incorrectas sobre el
• Definiciones de • API significado, las unidades o los límites
interfaz • Microservici de datos que se transmiten entre
externa. os sistemas.
• Fallas en el cumplimiento de
regulaciones de seguridad
obligatorias.
 ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Pruebas Defectos típicos
Sistema • Especificaciones • Aplicaciones • Cálculos incorrectos.
funcionales y no • Sistemas de • Comportamiento
funcionales de hardware/software funcional o no funcional
requisitos del sistema y • Sistemas operativos. del sistema incorrecto o
del software. • Sistemas bajo prueba inesperado.
• Casos de uso. (SUT) • Control y/o flujos de
• Épicas e historias de • Configuración del datos incorrectos
usuarios. sistema y datos de dentro del sistema.
configuración. • Falta de realización
adecuada y completa
de tareas funcionales
de extremo a extremo.
 ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Pruebas Defectos típicos
Sistema • Modelos de • Aplicaciones • Mal funcionamiento del
comportamiento del • Sistemas de sistema en el entorno
sistema. hardware/software de producción.
• Diagramas de estado. • Sistemas operativos. • Falla del sistema para
• Manuales del sistema y • Sistemas bajo prueba trabajar como se
del usuario. (SUT) describe en los
• Configuración del manuales del sistema y
sistema y datos de del usuario.
configuración.
 ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Pruebas Defectos típicos
Aceptación • Procesos de negocio • Sistema bajo prueba. • Los flujos de trabajo
• Requisitos del • Configuración del del sistema no cumplen
usuario del negocio sistema y datos de con los requisitos del
• Regulaciones, configuración negocio o del usuario.
contratos legales y • Procesos de negocio • Las reglas de negocio
estándares. para un sistema no se implementan
• Casos de uso. totalmente integrado correctamente.
• Requisitos del • Procesos operativos y • El sistema no satisface
sistema. de mantenimiento. los requisitos
• Documentación del contractuales o
sistema o del reglamentarios.
usuario.
 ATRIBUTOS DE LOS NIVELES DE PRUEBAS
Base de Pruebas Objeto de Pruebas Defectos típicos
Aceptación • Procedimientos de • Sistemas de • Fallos no funcionales
instalación. recuperación y sitios tales como
• Informes de críticos(para pruebas vulnerabilidades de
análisis de riesgos de continuidad del seguridad, eficiencia
negocio y recuperación de rendimiento
de desastres) inadecuada bajo
• Formularios cargas elevadas o
• Informes funcionamiento
• Datos de producción incorrecto en una
existentes y convertidos plataforma soportada
FORMAS DE PRUEBAS DE ACEPTACIÓN
• Pruebas de aceptación de usuarios (UAT)
• Validan la idoneidad para el uso del sistema por parte de los usuarios previstos en un
entorno operativo real o simulado.
• Los usuarios pueden utilizar el sistema para satisfacer sus necesidades, cumplir con los
requisitos y llevar a cabo los procesos de negocio con la mínima dificultad, coste y
riesgo.
FORMAS DE PRUEBAS DE ACEPTACIÓN
• Pruebas de aceptación operacional (OAT)
• Pruebas de copia de seguridad y restauración.
• Instalación, desinstalación y actualización.
• Recuperación de desastres.
• Gestión de usuarios.
• Tareas de mantenimiento.
• Carga de datos y tareas de migración.
• Comprobación de vulnerabilidades de seguridad.
• Pruebas de rendimiento.
FORMAS DE PRUEBAS DE ACEPTACIÓN
• Pruebas de aceptación contractual y regulatoria
• Suelen ser realizadas por usuarios o por probadores independientes.
• Las pruebas de aceptación contractuales se realizan en función de los criterios de
aceptación del contrato.
• Las pruebas de aceptación regulatorias se realizan sobre de cualquier regulación que
deba cumplirse, como las regulaciones gubernamentales, legales o de seguridad.
IDENTIFICAR NIVELES DE PRUEBAS

• ¿A qué nivel de pruebas corresponden los siguientes escenarios?

• Las pruebas se diseñan en base a cómo el sistema utiliza un microservicio externo para
verificar la puntuación crediticia del titular de la cuenta.
• Las pruebas se diseñan basándose en cómo la información de la orden de compra
capturada en el interfaz de usuario se transfiere a la lógica de negocio.
• Las pruebas están diseñadas en base a la forma en que el jefe de logística maneja la
aprobación o rechazo de una solicitud de orden de compra.
TIPOS DE PRUEBA

• Pruebas Funcionales
• Pruebas No Funcionales
• Pruebas de Caja Blanca
• Pruebas relacionadas con el cambio
TIPOS DE PRUEBA
• Pruebas funcionales
• Implica pruebas que evalúan las funciones que el sistema debería realizar.
• Las funciones son “lo que” debe hacer el sistema.
• Debe realizarse en todos los niveles de prueba, aunque el enfoque es diferente en cada
nivel.
• Uso de técnicas de caja negra para obtener casos de prueba.
• Conocimiento del dominio de negocio.
• Métrica: cobertura funcional
TIPOS DE PRUEBA
• Pruebas No funcionales
• Evalúa los atributos de calidad del software (referencia: ISO/IEC 25010)
• Es la prueba de “qué tan bien” se comporta el sistema.
• Pueden realizarse en todos los niveles de prueba, y deben realizarse lo antes posible.
• Uso de técnicas de caja negra para obtener casos de prueba.
• Conocimiento de las debilidades de un diseño o tecnología.
• Métrica: cobertura no funcional.
TIPOS DE PRUEBA
• Pruebas de Caja Blanca
• Pruebas basadas en la estructura interna del sistema o en su implementación.
• La estructura interna puede incluir código, arquitectura, flujos de trabajo y/o flujos de
datos dentro del sistema.
• Conocimientos sobre la forma en que se construye el código y cómo se almacenan los
datos.
• Métrica: cobertura estructural tal como cobertura de código o cobertura de interfaces.
TIPOS DE PRUEBA
• Pruebas relacionadas con el Cambio
• Pruebas de confirmación
• Pruebas para confirmar si un defecto corregido ha sido arreglado con éxito.
• Pruebas de regresión
• Implican la realización de pruebas para detectar efectos secundarios no deseados debido a
cambios en el código.
• Candidato a ser automatizado.
• Se realizan en todos los niveles de pruebas.
• Muy usados en el desarrollo iterativo/incremental.
PARA CADA ESCENARIO INDICAR QUE TIPO DE PRUEBA ES
Y A QUÉ NIVEL DE PRUEBA CORRESPONDE
1. Las pruebas están diseñadas para evaluar la accesibilidad de la interfaz
de procesamiento de orden de compra del jefe de logística para personas
con discapacidades.
2. Las pruebas están diseñadas para cubrir secuencias de páginas web que
pueden ocurrir durante una solicitud de aprobación de línea de crédito.
3. Las pruebas se diseñan en base a cómo un componente debe calcular el
interés compuesto.
PRUEBAS DE CAJA NEGRA
• Tipos:
• Prueba basada en fallas
• Prueba basada en escenarios
• Prueba de arquitectura cliente/servidor
• Pruebas de servidor
• Pruebas de bases de datos
• Pruebas de transacción
• Pruebas de comunicación de red
• Prueba de documentación
PRUEBA BASADA EN FALLAS
• Diseñar pruebas que tengan altas probabilidades de descubrir posibles
fallas.
• La prueba de integración busca fallas en llamadas a operación o en
conexiones entre mensajes.
• Tres tipos de fallas se pueden encontrar: resultado inesperado, operación
incorrecta / mensaje empleado, invocación incorrecta.
• La prueba de integración busca encontrar errores en el objeto cliente, no en
el servidor
PRUEBA BASADA EN ESCENARIOS
• Esta complementa la anterior, ya que la de fallas soslaya dos tipos de
errores:
• a) Especificaciones incorrectas: el producto no hace lo que el cliente
quiere.
• b) Interacciones entre subsistemas: ocurren cuando el comportamiento de
un subsistema causa fallas del otro subsistema.
• Este tipo de prueba se enfoca en lo que hace el usuario no el producto.
• Ejemplo: mandar imprimir documento ( con última corrección ? )
PRUEBA DE ARQUITECTURA CLIENTE/SERVIDOR
• Prueba de servidor: probar las funciones de coordinación y manejo de datos
del servidor. Desempeño del servidor ( tiempo de respuesta y procesamiento
total de los datos )
• Prueba de base de datos: probar la exactitud e integridad de los datos,
examinar transacciones, asegurar que se almacena, actualiza y recuperan los
datos.
• Pruebas de comunicación de red: verificar comunicación entre los nodos, el
paso de mensajes, transacciones y trafico de la red se realice sin errores
PRUEBA DE DOCUMENTACIÓN
• Es importante para la aceptación del programa.
• Revisar la guía de usuario o funciones de ayuda en línea.
• Prueba de documentación es en dos fases:
• 1. Revisar e inspeccionar: examinar la claridad editorial del
documento.
• 2. Prueba en vivo: usar la documentación junto con el programa
real.
PRUEBAS DE CAJA BLANCA

• Prueba de la Ruta Básica.

• Pruebas de la estructura de control
• Prueba de condición
• Prueba del flujo de datos
• Prueba de bucles
PRUEBA DE LA RUTA BÁSICA
• Técnica de prueba de caja blanca que propuso Tom McCabe.
Permite conocer una medida de la complejidad lógica de un
diseño procedural y usar esta medida como guía para definir un
conjunto básico de rutas de ejecución.
• Estas garantizan que se ejecute cada instrucción del programa por
lo menos una vez durante la prueba
PRUEBA DE LA RUTA BÁSICA
• Debemos recordar: diagrama de flujo y gráfica de flujo
• Componentes de la gráfica de flujo:
• Aristas: enlaces
• Nodos: instrucción procedural
• Nodo predicado: nodo del que emanan dos aristas (if)
• Región: área que se limita por aristas y nodos
PRUEBA DE LA RUTA BÁSICA
PRUEBA DE LA RUTA BÁSICA
• La complejidad ciclomática se basa en la teoría gráfica y se calcula de tres
maneras:
• 1. Número de regiones
• 2. Complejidad ciclomática es igual a número de aristas, menos el número de nodos más
V(G) = E – N + 2
• 3. Complejidad ciclomática es igual al número de nodos predicado más uno
V(G) = P + 1
PRUEBA DE LA RUTA BÁSICA

• La complejidad citomática marca el límite mínimo de casos de prueba para

un programa.
• Cuando el valor es mayor a 10, la probabilidad de defectos en el módulo o
programa crece demasiado, conviene dividir el módulo.
PRUEBA DE CONDICIÓN
• Método que ejercita las condiciones lógicas contenidas en un módulo del
programa.
• Una condición simple es una variable booleana o una expresión relacional.
• Esta prueba se concentra en la prueba de cada condición del programa para
asegurar que no contiene errores.
Expresión1 <operador relacional> Expresión2
Objetivo: probar todos los casos de la relación.
PRUEBA DEL FLUJO DE DATOS
• Método que selecciona rutas de prueba de acuerdo con las ubicaciones de
las definiciones y usos de las variables del programa.
• Asume que cada instrucción se le asigna un numero de instrucción y ninguna
función modifica sus parámetros o variables globales.
• Probar las DEF( I ) y las USO( I )
Donde:DEF( I ) = x | instrucción I contiene una definicion de x
USO( I ) = x | instrucción I contiene un uso de x
Objetivo: probar todas las DEF y USO de I
PRUEBA DE BUCLES
• Técnica de prueba de caja blanca que se concentra exclusivamente en la
validez de la construcción de bucles.
• EJM:
Bucles simples:omitir por completo el bucle
solo un paso por el bucle
dos pasos por el bucle
m pasos por el bucle ( m < n )
n=1 , n , n+1 pasos por el bucle
( n es num máximo pasos permitidos )
PRUEBA DE BUCLES
• Bucles anidados:
iniciar el bucle mas interno
asignar a todo bucle los valores mínimos
validar el mas interno con valores mínimos en externos
agregar pruebas con valores fuera de rango
analizar de la misma manera hacia afuera
PRUEBA DE BUCLES

• Bucles concatenados:
igual que los simples
• Bucles no estructurados:
se recomienda rediseñar los bucles
CAJA BLANCA: PRUEBA DEL CAMINO BÁSICO
CAJA BLANCA: PRUEBA DEL CAMINO BÁSICO
•RENGAL3@GMAIL.COM