PRUEBAS DE SISTEMAS DE INFORMACIÓN

INTRODUCCIÓN

LA CALIDAD, EL TESTING Y SUS OBJETIVOS

Aportar a la calidad del
producto que se está verificando

CALIDAD

Es una característica que nos permite comparar distintas cosas del
mismo tipo.

Se define, o se calcula, o se le asigna un valor, en base a un conjunto de
propiedades (seguridad, performance, usabilidad, etc.),

Falacia del Nirvana

Esta refiere al error lógico de querer comparar cosas reales con otras irreales o
idealizadas5

TESTING

Es una investigación técnica realizada para proveer información a los
stakeholders sobre la calidad del producto o servicio bajo pruebas.

Es un proceso diseñado para asegurar que el código hace lo que se supone
que debe hacer y no hace lo que se supone que no debe.

Un
proceso en el que se ejecuta un programa con el objetivo de encontrar errores.

OBJETIVOS

La forma en la que estaremos aportando calidad es principalmente buscando fallos

Si no encontramos fallos entonces tenemos más confianza
en que los usuarios encontrarán menos problemas.

La
estrategia más efectiva sería centrarse en un módulo que esté más verde, que tenga errores
más fáciles de encontrar, me centro en diseñar y ejecutar más pruebas para ese módulo,



pues ahí encontraré más fallos.

El objetivo no tiene por qué ser el mismo a lo largo del tiempo, pero sí es importante
que se tenga claro en cada momento cuál es.

EL TESTING AL FINAL DEL PROYECTO

No debería ser una etapa sino que debería ir de la mano con el desarrollo en sí

El testing es algo que queda para el final

En cada etapa
del proceso de desarrollo tendremos actividades de testing para realizar

Si dejamos para el final nos costará
mucho más, más tiempo, más horas, y más costo de reparación, pues si encontramos un
problema en la arquitectura del sistema cuando este ya se implementó, entonces los
cambios serán más costosos de implementar.

TESTING INDEPENDIENTE

Quienes construyeron el software son los que mejor lo
conocen

Se pide a la gente que construyó el software que lo pruebe.

INTRODUCCIÓN A LAS PRUEBAS FUNCIONALES

CASO DE PRUEBA

“Un conjunto de entradas de prueba, condiciones de ejecución, y
resultados esperados desarrollados con un objetivo particular, tal como el
de ejercitar un camino en particular de un programa o el verificar que
cumple con un requerimiento específico.”

“Una idea de prueba es una breve declaración de algo que debería ser
probado. Por ejemplo, si se está probando la función de la raíz cuadrada,
una idea de prueba sería el ‘probar un número que sea menor que cero’. La
idea es chequear si el código maneja un caso de error.”

ELEMENTOS DE DESCRIPCIÓN

􀁸 Flujo: secuencia de pasos a ejecutar
􀁸 Datos entrada
􀁸 Estado inicial
􀁸 Valor de respuesta esperado
􀁸 Estado final esperado

Lo más importante el flujo, o sea la serie de pasos a
ejecutar sobre el sistema, los datos de entrada, ya sean entradas proporcionadas por el
usuario al momento de ejecutar, o el propio estado de la aplicación, y por último las salidas

esperadas, el oráculo, lo que define si el resultado fue positivo o negativo.

ORÁCULO

Es el mecanismo, ya sea manual o automático, de verificar si el comportamiento del
sistema es el deseado o no.

Deberá comparar el valor esperado contra
valor obtenido, el estado final esperado con el estado final alcanzado, el tiempo de
respuesta aceptable con el tiempo de respuesta obtenido, etc.

COBERTURA DE PRUEBAS

Es una medida de calidad de las pruebas.

Subtema

TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

Permiten seleccionar la menor
cantidad de casos con mayor probabilidad de encontrar fallas en el sistema.

Se basa en técnicas bien conocidas y utilizadas, tales como particiones de
equivalencia, valores límites, combinaciones por pares, tablas de decisión o máquinas de
estado.

CAJA BLANCA Y CAJA NEGRA

CAJA BLANCA

Si utilizamos información interna del
sistema que estamos probando, tal como el código, esquema de base de datos, etc.,

CAJA NEGRA

Observación de entradas y salidas del sistema

CAJA GRIS

Combinación de caja blanca y caja negra

Basada en la información utilizada como entrada.

CASO DE PRUEBA ABSTRACTO Y ESPECÍFICO

Se caracteriza por no tener determinados los valores para las
entradas y salidas esperadas.

ESPECIFICO

Se determinan valores específicos para cada variable de entrada.

Se utilizan variables y se describen con operadores lógicos

PRUEBAS DIRIGIDAS POR DATOS

Es una técnica para construir casos de prueba basándose en los datos entrada, y
separando el flujo que se toma en la aplicación.

FLUJO

Serie de pasos para ejecutar el caso de prueba

Permite agregar nuevos casos de prueba fácilmente,
ingresando simplemente nuevos datos de entrada y de salida esperados, que sirvan para
ejecutar el mismo flujo.

Se almacenan los datos de
entrada y salida esperados.

Definiendo con casos de prueba abstractos

Al
momento de ser ejecutados con un juego específico de datos,

Casos de prueba específicos

Data-driven testing

Casos de prueba abstracto y específico

DISEÑO BÁSICO DE CASOS DE PRUEBA

Determinar el flujo del caso de
prueba, que básicamente será seguir el flujo de la funcionalidad

IDENTIFICAR VARIABLES

Se identifican las variables que están en juego en la funcionalidad

conformar las variables de una funcionalidad

-Entradas del usuario por pantalla.
- Parámetros del sistema (en archivos de configuración, parámetros de invocación del
programa, tablas de parámetros, etc.).
- Estado de la base de datos (existencia –o no– de registros con determinados valores
o propiedades).

Las variables, de cualquier entrada que al cambiar
su valor hace que cambie el comportamiento o resultado del sistema bajo pruebas.

Para cada variable se diseñan valores interesantes

SELECCIONAR VALORES INTERESANTES

Ya identificadas las variables, para cada una hay que seleccionar los valores que se le asignarán en las pruebas.

Para cada variable utilizar distintos datos

Un grupo de valores pertenece a una
misma clase de equivalencias si deben producir un comportamiento similar en el sistema.

Distinguir opciones significativamente diferentes cuando:

-Disparan distinto flujo sobre el sistema (al ingresar un valor inválido me lleva a otra
pantalla distinta).
- Dispara un mensaje de error diferente (no es lo mismo ingresar un password corto
que uno vacío).
-Cambia la apariencia de la interfaz del usuario, o el contenido del form (al
seleccionar pago con tarjeta de crédito aparecen los campos para ingresar el
número de tarjeta, titular y fecha de expiración, pero si se selecciona pago por
transferencia entonces aparecen los campos para ingresar información de la cuenta
bancaria).
-Cambian las opciones disponibles para otras variables (al seleccionar un país distinto
se pueden seleccionar sus estados o provincias).
34 Introducción a las Pruebas Funcionales
- Si dispara distintas condiciones para una regla de negocio (si se ingresa una edad
será distinto el comportamiento si es menor o mayor de edad).
- Valores por defecto o cambiados (en ocasiones el sistema sugiere datos que se
habían ingresado previamente para un cliente, como por ejemplo su dirección, pero
si se cambian en el formulario de entrada entonces el sistema actualizará ese dato).
-Cambios de comportamiento por distintas configuraciones o distintos países
(formato de números, formatos de fecha, moneda, etc.).
- ¿Qué más se les ocurre? Seguro que hay más, estos fueron ejemplos para mostrar
cómo analizar los casos significativamente diferentes.

COMBINACIÓN DE VALORES

Permiten seleccionar una cantidad acotada de datos
de prueba, siguiendo teorías de errores que indican cómo combinar los datos para
aumentar esa probabilidad de encontrar errores

COMBINACIÓN POR PARES

Una de las técnicas de combinación de datos más usada es all-pairs, o sea todos los pares, y
justamente lo que se hace es intentar utilizar todos los pares posibles.

PROW (pairwise with restrictions, order and weight).

Utilizando este algoritmo
podemos excluir pares que nos resulten inválidos, e incluso darle distintas prioridades a los
distintos pares, pues siempre será necesario repetir algunos pares para lograr todas las
combinaciones,

NO ENMASCARAMIENTO DE ERRORES

En los conjuntos de datos de prueba se utilizará solo un valor de una clase inválida a la vez, pues si se utilizan dos se corre el peligro de no identificar qué valor inválido
produce el error.

Busca obtener el conjunto de
datos más eficiente posible (eficiente = encontrar la mayor cantidad de errores con la
menor cantidad de ejecuciones).

CALCULAR VALORES ESPERADOS

Esta es la única forma de determinar si la aplicación funciona como es esperado o no.

Estamos incluyendo a lo que el sistema muestra en pantalla, archivos
que se tengan que modificar, estados de la base de datos, o cualquier otro tipo de acción
que deba realizar el software que estamos probando.

Testing Negativo

Incluir escenarios con aquellas
cosas que el sistema debe estar preparado para no hacer, o no fallar por tratarse de una
situación incorrecta.

Estrategias para determinar distintos flujos a probar.

Pruebas de Performance

son las mismas pruebas no funcionales

se hacen con equipos interelacionados

se analiza el servidor

tener el sistema bien alineado

cobijar todos los escenarios extremos

PRUEBAS AUTOMATIZADAS

sean “automáticas” y “ejecutadas por una máquina”, vamos a necesitar gente capacitada.

el beneficio se da desde el momento de modelar, y especificar con un lenguaje formal las pruebas a realizar

¿POR QUÉ Y PARA QUÉ AUTOMATIZAR?

x Mejora la calidad, pues hay menos errores humanos. x Mejora la performance de producción, pues con las mismas personas se puede lograr mucho más trabajo, a mayor velocidad y escala, y en ese sentido mejoran el rendimiento de las personas. tema

al automatizar pruebas logramos

(a mediano y largo plazo

reducir el tiempo insumido en las pruebas de una determinada funcionalidad, con lo cual podremos disminuir el tiempo de salida al mercado.

Al ejecutar las pruebas automatizadas más rápido

permite detectar antes los errores introducidos sobre funcionalidades ya existentes del sistema

obtener un rápido feedback

sobre el estado de calidad del sistema

TEST DE REGRESIÓN

pruebas planificadas que se seleccionan para ejecutar periódicament

verificar que lo que estoy probando no tenga regresiones

Subtema

TESTING AUTOMATIZADO

una máquina logre ejecutar los casos de prueba en forma automática

scripts en un lenguaje genérico o propio de una herramienta

PRINCIPIOS BÁSICOS DE LA AUTOMATIZACIÓN DE PRUEBAS

PARADIGMAS DE AUTOMATIZACIÓN

SCRIPTING

Lenguajes pueden ser específicos, conocer el lenguaje o API de la herramienta, los distintos elementos con los que interactuamos del sistema bajo pruebas, los botones en una página web, los métodos de la lógica que queremos ejecutar, o los parámetros a enviar en un pedido GET de un sistema web

RECORD AND PLAYBACK

La herramienta sea capaz de capturar las acciones del usuario (record) sobre el sistema que estamos probando.

Luego a un script que sea reproducible (playback).

DISEÑO DE PRUEBAS SEGÚN OBJETIVOS

1. Testing consistente y repetible, asegurando que se ejecutan siempre exactamente las mismas acciones, con los mismos datos, y verificando cada una de las cosas que siempre hay que verificar, tanto a nivel de interfaz como a nivel de base de datos. 2. Correr casos de prueba desatendidos. 3. Encontrar errores de regresión, a menor costo y en forma más temprana. 4. Correr casos de prueba más seguidos (después de cada commit al repositorio de código por ejemplo). 5. Mejorar la calidad del software (más testing, más oportunidades de mejora), y así incrementar la confianza de los usuarios. 6. Medir performance. 7. Testear en diferentes sistemas operativos, navegadores, configuraciones, gestores de bases de datos, etc., sin duplicar el costo de ejecución. 8. Disminuir el tiempo de salida al mercado/correr las pruebas más rápido. 9. Mejorar la moral en los testers, haciendo que las tareas rutinarias sean ejecutadas en forma automática.

PRIORIZACIÓN: DECIDIR QUÉ Y CUÁNDO AUTOMATIZAR

Nos basamos en algo llamado “testing basado en riesgos”

- Importancia o criticidad para la operativa del negocio. -Costo del impacto de errores. - Probabilidad de que hayan fallos (esto hay que preguntárselo a los desarrolladores, que seguramente sabrán que determinado módulo lo tuvieron que entregar en menor tiempo del que necesitaban, entonces ellos mismos dudan de la estabilidad o calidad del mismo). -Acuerdos de nivel de servicio (SLA). - Dinero o vidas en juego (suena dramático, pero sabemos que hay muchos sistemas que manejan muchas cosas muy sensibles).

¿CÓMO AUTOMATIZAR?

Se comienza por el inventario de funcionalidades asignaríamos prioridades a cada caso de prueba que tenemos preparado para cada una de las distintas funcionalidades.

Definido en dos niveles de abstracción

Casos de prueba abstractos o conceptuales,

Son guiones de prueba, que al indicar que se utilizarán datos no hacen referencia a valores concretos, sino a clases de equivalencia, o a grupos de valores válidos

Casos de prueba con datos

Se instancian los casos de prueba abstractos con valores concretos

DISEÑO DE SUITES DE PRUEBA

Módulo o Funcionalidad: agrupando todos los casos de prueba que actúan sobre una misma funcionalidad.

Criticidad: podríamos definir un grupo de pruebas que se debe ejecutar siempre (en cada build), ya que son las más críticas, otro de nivel medio, que lo ejecutamos con menos frecuencia (o tal vez que se seleccionan solo si hay cambios en determinadas funcionalidades), y uno de poca criticidad, que ejecutaríamos opcionalmente si

BUENAS PRÁCTICAS DE AUTOMATIZACIÓN DE PRUEBAS

LAS COSAS CLARAS AL COMENZAR

Definir y dejar clara la organización y nomenclatura a utilizar, que a futuro nos permita manejar lo más simple posible el enorme set de pruebas que vamos a tener

NOMENCLATURA

Utilizar nombres para los casos de prueba de forma tal que sea fácil distinguir

Definir una estructura de carpetas que permita separar los casos de prueba generales

Crear casos de prueba temporales, los cuales se los puede nombrar con un prefijo común como pru o tmp

QUÉ ES EL TESTING EXPLORATORIO

“El Testing Exploratorio consiste en el aprendizaje, diseño y ejecución de
pruebas de forma simultánea.”

presenta una estructura externa que es sencilla de describir, en la que durante
un lapso de tiempo un tester –o equipo de testers

interactúa con un producto para cumplir
con el objetivo de una misión, para posteriormente presentar y reportar los resultados que
el resto de los actores del proyecto utilizarán para tomar decisiones a conciencia

MISIÓN

tiempo, objetivos y reportes.

1. Proporcionar información y resultados de forma rápida;
2. Para obtener nueva información y conocimiento a lo largo de nuestro trabajo de
testing;
3. Revelar nuevos tipos de defectos y problemas;
4. Mejorar las habilidades del tester y equipo de testing en general, además del
conocimiento sobre la lógica del negocio;
5. Por último, notamos que el modo de registrar y guardar información en las sesiones,
es una tarea muy importante, tanto para el tester, equipo de testing, como para el
resto de los actores que forman parte del equipo.

CONSTRUYAMOS NUESTRO MAPA

Tomar notas de lo que se va descubriendo ya sea en forma esquemática o en forma tabulada

Herramientas que los ayudaban en su actividad

- Brújula, para indicar en qué dirección iban;
- Catalejo, para enfocar a lo lejos y “acercar” los lugares;
- Compás, que permitía medir y ubicar más precisamente los sitios explorados.

PROPIEDADES DEL TESTING EXPLORATORIO

1. Las pruebas no son definidas con anticipación, en este contexto se espera que el tester aprenda con rapidez y velocidad acerca de un producto o nueva funcionalidad, mientras que se provee retroalimentación al resto del equipo.

2. Los resultados obtenidos durante pruebas anteriores guiarán las acciones, los pasos y los siguientes escenarios de prueba a ejecutar, construyendo así un conjunto de pruebas más eficaz

2. Los resultados obtenidos durante pruebas anteriores guiarán las acciones, los pasos y los siguientes escenarios de prueba a ejecutar, construyendo así un conjunto de pruebas más eficaz

3. Su foco está en encontrar problemas y defectos por medio de la exploración del sistema bajo prueba.

4. Es un acercamiento a las actividades de testing que consisten en una serie de actividades que se realizan en simultáneo, tales como el aprendizaje del sistema, diseño y ejecución de las pruebas.

5. La efectividad del testing se apoya en el conocimiento, habilidades y experiencia del tester

ESTILOS DE TESTING EXPLORATORIO

Subtema

AD-HOC TESTING

QUIERO PROBAR UNA FUNCIONALIDAD ESPECIFICA

Probar una funcionalidad especifica

sin seguir un orden determinado

TESTING EXPLORATORIO BASADO EN ESTRATEGIAS

diseñar programas o metodologias para cumplir un requerimiento

TESTING EXPLORATORIO BASADO EN SESIONES

tengo equipos diferentes para hacer tester, ejecutar roles

Saber el antes y el después

TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

DERIVACIÓN DE CASOS DE PRUEBA DESDE CASOS DE USO

No hay una única forma de aplicar esta técnica

Vamos a ver que vamos a tener
que tomar muchas decisiones, plantear algunas alternativas, o algunas cosas que
podríamos tener que considerar.

REPRESENTACIÓN DE CASOS DE USO

REPRESENTACIÓN TABULAR

Se comienza describiendo el flujo principal, y luego se enriquece describiendo cada uno de
los posibles flujos alternativos y excepciones.

pre-condiciones y post-condiciones

Deben
cumplirse antes y luego de la ejecución del mismo respectivamente.

Se representan en lenguaje natural, pero generalmente se intenta seguir
cierta estructura, indicando el flujo de interacción como pasos numerados.

REPRESENTACIÓN GRÁFICA

Representación, en forma de grafo, para poder desde ahí visualizar más
fácilmente los distintos flujos que se pueden seguir y seleccionarlos como casos de prueba.

Abstraerse de la letra,
representarlo como un grafo dirigido que muestre fácilmente cuáles son los flujos del
sistema.

Elemento de análisis muy conocido para documentar una
iteracción típica entre el usuario y el sistema.

diagramas UML

Muestran qué tipo de actor o usuario puede ejecutar cada caso de uso o funcionalidad

Se captura conocimiento del negocio y de cómo se desea que trabaje el sistema

Cada caso de uso cuenta con una serie de pre-condiciones y post-condiciones que deben
cumplirse antes y luego de la ejecución del mismo respectivamente.

DERIVANDO LOS CASOS DE PRUEBA

Se recorre desde el nodo inicial a cada
uno de los nodos finales, pasando por cada una de las transiciones del modelo.

FLUJOS DE PRUEBA

Para seleccionar los flujos debemos tener en cuenta

FLUJOS ALTERNATIVOS

Debería ser recorrido al menos una
vez. Con esto nos garantizamos de visitar cada posible interacción del usuario con el
sistema, y cada grupo de datos que hace que se vaya por un flujo u otro. Para

BUCLES

Deberíamos al menos seleccionar un caso en el que no se ejecute el
bucle, uno en el que se ejecute una vez, y en algunos casos, si se considera que es oportuno,
repetir el bucle varias veces. Se podrían distinguir dos tipos de bucles, los que tienen una
cantidad de repeticiones definida.

DATOS DE PRUEBA

Ciertos flujos se asocian con ciertas clases de
equivalencia de algunas variables.

Solo podremos seleccionar algunas clases de
equivalencia para algunos flujos.

FLUJO DEL TC5

(donde se quiere recordar el
password y para ello se debe ingresar la cuenta de e-mail registrada) solo se puede ejecutar
si se selecciona una cuenta de e-mail válida, con lo cual para ese caso de prueba no
consideraremos todos los valores posibles para esa variable, sino que solo los que aplican
para el flujo correspondiente.

ACTORES

Los que van a ejecutar cada casos de prueba

Este tipo de información generalmente está disponible en las descripciones de los
diagramas de uso

SELECCIÓN DE CASOS DE PRUEBA

Es la técnica que nos da la cobertura de casos de uso

Está en
nosotros seleccionar lo que ejecutamos/automatizamos de acuerdo a los recursos y la
importancia que le damos a cada valor de cada variable y a cada caso de uso.

¿Cómo seleccionar?

- Primero seleccionando los casos de uso más importantes
- Para cada caso de uso, cuáles son los flujos más importantes
- Para cada flujo, ver qué datos son los más importantes a utilizar

TÉCNICA DE TABLAS DE DECISIÓN

Es muy aplicable cuando la lógica a probar está
basada en decisiones

Se puede expresar la lógica en forma de reglas

- Si A es mayor que X entonces…
- Si el cliente C tiene deuda entonces…
- etc.

if-thenelse

Aplica a programas donde la lógica predominante es del tipo

la representación en Tablas de Decisión

Completar con las combinaciones de datos que
formarán los casos de prueba. Básicamente se listan las condiciones y acciones identificadas
en una matriz.

Identifica los posibles valores para esas
condiciones y cómo están relacionadas.

Cada columna indicará una posible combinación entre condición y acción

Aplica a programas donde la lógica predominante es del tipo

Grafo
Causa-Efecto

Representan la relación lógica entre distintas causas y los posibles
efectos.

Se listan las causas (entradas o acciones del usuario) y los efectos (salidas
o acciones del sistema esperadas), y luego se unen indicando relaciones entre ellos.

Muestra las reglas de la lógica del sistema

MÁQUINAS DE ESTADO

Conocida como FSM del inglés finite state machine

Es un grafo dirigido cuyos nodos representan estados y cuyas aristas representan transiciones
entre dichos estados.

Este tipo de técnicas es de las más usadas en el mundo del Model-based Testing (MBT),

Estructura

-Cobertura de estados: Este criterio se satisface cuando los casos de prueba recorren
todos los estados.
- Cobertura de transiciones: En este caso cuando se recorren todas las transiciones.
- Cobertura de pares de transiciones: Para cada estado se cubren las combinaciones
de transiciones de entrada y salida.

APLICACIÓN DE LA TÉCNICA EN UN EJEMPLO

Gestión de Artículos

Modelar el comportamiento de los
artículos con una máquina de estados y a partir de ella derivar los casos de prueba

Los
artículos pueden tener distintos estados, y el comportamiento esperado para cada acción o
funcionalidad del sistema, dependerá del estado asociado al artículo.

CTWEB PARA DERIVAR PRUEBAS CON MÁQUINAS DE ESTADO

Permite diseñar los casos de prueba que cubren una
máquina de estados dada,

MATRIZ CRUD

(Crear, Leer, Actualizar, Eliminar, del inglés: create, read, update,
delete).

CRUD Matrix

tener una vista general sobre el ciclo de vida de las entidades, y cómo es afectado en
las distintas funcionalidades que estamos probando

Tener una vista general sobre el ciclo de vida de las entidades, y cómo es afectado en
las distintas funcionalidades que estamos probando