Metodologías del Testing Funcional

LTI – Plan 2024 1

 Metodologías del Testing Funcional

Contenido
CASOS DE PRUEBA ............................................................................................................ 3
Estructura de un caso de prueba............................................................................................ 4
Casos de Prueba Abstractos o Concretos ................................................................................ 5
TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA ............................................................... 6
Clases de Equivalencia .......................................................................................................... 6
Condiciones de Borde ........................................................................................................... 8
Tablas de Decisión ............................................................................................................... 9
All pairs / Combinación por pares ........................................................................................ 13
Resumen: .................................................................................................................... 21
Técnica de Transición de Estado (State Transition Testing) ............................................ 22
EJECUCIÓN DE CASOS DE PRUEBA............................................................................... 23
Validación y Verificación .................................................................................................. 23
Error / Defecto / Falla ...................................................................................................... 23
¿Para qué me sirve medir la cobertura de pruebas? ....................................................... 24

LTI – Plan 2024 2

 Metodologías del Testing Funcional

CASOS DE PRUEBA

Comencemos por el principio ¿qué es un caso de prueba?

Veamos a continuación algunas definiciones formales para comenzar a introducirnos en el tema.

Según la IEEE Standard 610 (1990) un caso de prueba es:

“Un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados
diseñados con un objetivo específico, como ejercitar un camino particular de un programa o verificar
el cumplimiento de un requerimiento específico.”

De acuerdo a Ron Patton (2001):

“Los casos de prueba son las entradas específicas que pruebas y los procedimientos que sigues cuando
pruebas el software.”

Bob Binder (1999) define un caso de prueba como:

“Un caso de prueba especifica las precondiciones de la implementación bajo prueba y el ambiente
para ésta, las entradas o condiciones, y los resultados esperados. Los resultados esperados especifican
lo que la implementación bajo prueba debe producir a partir de las entradas. Esta especificación
incluye los mensajes generados por la implementación bajo prueba, excepciones, las salidas, y el
estado resultante de la implementación bajo prueba y su ambiente. Los casos de prueba también
especifican las precondiciones y las postcondiciones para otros objetos que constituyen la
implementación bajo prueba y su ambiente.“

Un caso de prueba es una manera de detallar qué es lo que se quiere probar de un aplicativo; se puede
especificar a nivel conceptual y de datos, incluyendo detalles del comportamiento del sistema a
probar.

Un caso de prueba es exactamente lo que parece: un escenario de prueba que mide la funcionalidad
en un conjunto de acciones o condiciones para verificar el resultado esperado. Se aplican a cualquier
aplicación de software, pueden utilizar pruebas manuales o pruebas automatizadas y puede hacer uso
de herramientas de gestión de casos de prueba.

Una cosa clave para recordar cuando se trata de escribir casos de prueba es que están destinados a
probar una variable o tarea básica, como si un código de descuento se aplica o no al producto correcto
en una página web de comercio electrónico. Esto permite que un probador de software tenga más
flexibilidad en cómo probar el código y las funciones.

LTI – Plan 2024 3

 Metodologías del Testing Funcional

Estructura de un caso de prueba

Los casos de prueba tienen algunas partes integrales que siempre deben estar presentes en los
campos. Sin embargo, cada caso de prueba se puede dividir en 8 pasos básicos.

Paso 1: ID de caso de prueba

Todos los casos de prueba deben llevar ID únicos para representarlos. En la mayoría de los casos,
seguir una convención para este ID de nomenclatura ayuda con la organización, la claridad y la
comprensión.

Paso 2: Descripción de la prueba

Esta descripción debe detallar qué unidad, característica o función se está probando o qué se está
verificando.

Paso 3: Supuestos y condiciones previas

Esto implica que se cumplan las condiciones antes de la ejecución del caso de prueba. Un ejemplo
sería requerir una cuenta de Outlook válida para iniciar sesión.

Paso 4: Pasos a ejecutar

Estos deben ser pasos fácilmente repetibles ejecutados desde la perspectiva del usuario final. Por
ejemplo, un caso de prueba para iniciar sesión en un servidor de correo electrónico podría incluir estos
pasos:

1. Abra la página web del servidor de correo electrónico.

2. Introduzca su nombre de usuario.
3. Introducir la contraseña.
4. Haga clic en el botón "Entrar" o "Iniciar sesión".

Paso 5: Resultado Esperado

Esto indica el resultado esperado después de la ejecución del paso del caso de prueba. Al ingresar la
información de inicio de sesión correcta, el resultado esperado sería un inicio de sesión exitoso.

Paso 6: Resultado Obtenido

Es el resultado que se obtiene al ejecutar el Caso de Prueba sobre la aplicación que se está probando.

Puede ser igual o no al resultado esperado. Es de esta comparación que se determina si el Caso de
Prueba PASA (cuando el resultado esperado es igual al resultado obtenido) o FALLA (cuando el
resultado esperado es diferente al resultado obtenido)

Un solo caso de prueba, no tiene por qué ser suficiente para evaluar un aspecto del aplicativo que se
quiere probar; en la mayoría de las situaciones, es necesario un conjunto de casos de prueba para
verificar un aspecto o una funcionalidad de un aplicativo.

LTI – Plan 2024 4

 Metodologías del Testing Funcional

Casos de Prueba Abstractos o Concretos

Al escribir los casos de prueba, tenemos que considerar como los vamos a diseñar.

Casos de Prueba Abstracto - No define los datos concretos que se va a usar para ejecutar el caso de
prueba, sino restricciones o consideraciones sobre los mismos.
Por ejemplo - Crear un Producto con Stock Positivo

Casos de Prueba Concreto - es un caso de prueba especifico, o sea con datos, porque define los datos
concretos que se va a usar para cada variable.
Pero esto puede significar que ese dato o ese valor se puede llegar a usar una sola vez.
Por ejemplo registro de usuario con la CI, la CI para una persona es única, entonces no voy a poder
ejecutar el caso de prueba en 2 veces, sino que al usar el valor de la CI ya quemo el dato y entonces
para una nueva vez tendré que usar otro dato y entonces tendré que diseñar otro caso de prueba con
otro valor, esto es práctico?

Conclusión - Los casos de prueba se diseñan como abstractos y cuando tengo que ejecutar defino los
valores que voy a usar en las pruebas.

Objetivos de los casos de prueba:

● Llevar un proceso para detectar bugs que el equipo de desarrollo considere relevante y,
● Que se resuelvan estos bugs.
● Crear documentación precisa de las pruebas que se hacen.
● Nos ayudan a aprender del error, a predecir su impacto.

Pero como empezamos a diseñar casos de prueba?

Es imposible probar todo y por eso buscaremos la manera de diseñar y ejecutar la menor cantidad
de pruebas que me garanticen la mayor calidad del sistema.

LTI – Plan 2024 5

 Metodologías del Testing Funcional

TÉCNICAS DE DISEÑO DE CASOS DE PRUEBA

Dentro de la técnica de testeo de caja negra vista antes, existen algunas técnicas de diseño que nos
ayudan a la hora de generar los casos de prueba.

Estas técnicas son la forma en que se construyen y seleccionan los casos de prueba. Buscamos elegir
los casos de prueba que tengan mayor probabilidad de encontrar errores.

Algunas de las técnicas de diseño de casos de prueba, son las siguientes:

Clases de Equivalencia
La partición en clases de equivalencia, es una técnica que se puede utilizar cuando el dominio de
entrada es demasiado grande para las pruebas exhaustivas. La mayoría de las veces, los testers utilizan
de forma intuitiva esta técnica.

En esta técnica se dividen los datos de entrada en particiones o clases de equivalencia, los datos que
producen el mismo resultado son agrupados en una misma clase, es decir, se espera que todos los
miembros de una partición sean procesados de la misma manera. Algunas consideraciones a tener en
cuenta con esta técnica:

● Cada dato de entrada de debe pertenecer a una sola partición o clase de equivalencia.
● Los valores válidos son los que se supone que el sistema debe aceptar. Las particiones que
contienen los valores válidos son llamadas "partición de equivalencia válida".
● Similar al punto anterior, los valores que son rechazados por un sistema son llamados valores
no válidos y las particiones que los contienen se conocen como "partición de equivalencia no
válida".
● Cada una de las particiones de equivalencia no válidas son un caso de prueba diferente y
deben probarse de manera independiente, no deben combinarse como un solo caso de
prueba solo por el simple hecho de que son inválidas.

Es imposible probar con todos los datos de un conjunto de datos, y es por eso que se seleccionan
datos posibles representativos.

LTI – Plan 2024 6

 Metodologías del Testing Funcional

Ejemplo:

Imaginemos que tenemos un sistema que solo permite el acceso a personas de 18 a 60 años de edad
(para fines de este ejemplo vamos a obviar la existencia de números negativos).

El sistema le pide al usuario que introduzca su edad, si el usuario tiene menos de 18 años o más de 60
no permite el acceso y lanza un mensaje dependiendo de la edad, a los menores de 18 les dice: "No
puede acceder, su edad es menor a la requerida" y a los mayores de 60: "No puede acceder, su edad
es mayor a la requerida". Veamos las particiones de equivalencia:

Partición no válida Partición válida Partición no válida

<=17 18-60 >=61

Ya que el sistema debe comportarse de la misma manera para todos los menores de 18 años, todas
esas edades se agrupan en una misma partición y así igual con los otros dos grupos. Para lograr un
100% de cobertura los casos de prueba deben cubrir cada una de las particiones identificadas,
utilizando como mínimo un valor de cada partición para las pruebas. Esto quiere decir que utilizando
solo tres valores (uno de cada partición) ya probamos todos los casos. Aquí vemos dos de los
beneficios mencionados arriba:

1. Nos ahorrarnos la ejecución de pruebas redundantes, por ejemplo, sería lo mismo probar con
18 que probar con 25, o probar con 1 que probar con 17.

2. Podemos medir el porcentaje de cobertura fácilmente, por ejemplo, si probamos con 15, 20 y
62 ya tenemos el 100% de cobertura.

LTI – Plan 2024 7

 Metodologías del Testing Funcional

Condiciones de Borde

Esta técnica es una extensión de la partición de equivalencia, solo se utiliza para valores numéricos y
cuando los valores se encuentran ordenados. Una partición contiene un valor inicial y un valor final
(un número mínimo y uno máximo) y son denominados como valores límite.

A diferencia de la partición de equivalencia, que toma como mínimo un número dentro del rango de
la partición como dato de entrada, en esta técnica obligatoriamente deben tomarse como mínimo los
dos valores límite y opcionalmente, un valor entre los límites.

Ejemplo:

Para este sistema de calificaciones cada letra representa un rango (F=0-64, D=65-69, C=70-79, B=80-
89, A=90-100), los valores válidos van de 0 a 100, los valores menores que 0 representan una partición
inválida, al igual que los valores mayores a 100.

Para obtener una cobertura de 100% el usuario debe introducir al menos todos los valores que se
encuentran en azul en la imagen siguiente:

Esta técnica surge como respuesta a un caso muy común: es muy probable encontrar defectos en los
valores límites, siguiendo el ejemplo dado, puede que se haya cometido un error al programar uno de
los rangos de calificaciones y que 65 se registe como F en el sistema.

Aquí nuevamente vemos algunos de los beneficios que se mencionan más arriba:

1. Ayudan a determinar los escenarios negativos de una manera más eficaz: vemos claramente
cuáles son las particiones inválidas.
2. Hacen más visible los casos de prueba con la mayor probabilidad de tener defectos: en los
límites se tiende a encontrar más defectos que en el medio de un rango.

LTI – Plan 2024 8

 Metodologías del Testing Funcional

Tablas de Decisión

Un problema con las clases de equivalencia y condiciones de borde, es que sólo sirven para manejar
una entrada a la vez, y no combinaciones de entradas. Las tablas de decisión empiezan a buscar las
combinaciones de valores de entrada.

Esta técnica es adecuada para describir situaciones en las cuales las posibles combinaciones de
resultados (acciones, salidas) dependen de combinaciones de varias condiciones de entrada. Esta
técnica no es útil para aplicativos grandes; sin embargo, es muy buena para determinar el conjunto
de casos de prueba más adecuado para las funcionalidades críticas del aplicativo.

Un problema de las tablas de decisión, es que el número de combinaciones posibles se puede salirse
de control muy rápidamente, y con él, la cantidad de casos diseñados. La técnica matriz ortogonal,
aborda este problema.

Este es un enfoque donde las diferentes combinaciones de entrada y los resultados se muestran en
forma tabular.

● En las filas se colocan las condiciones y los resultados, donde las condiciones se ponen en la
parte superior y los resultados en la parte inferior.
● Cada columna corresponde a una regla la cual es definida por las combinaciones de entrada.
● Los valores a colocarse son generalmente booleanos como V (verdadero) y F (Falso). Si hay un
valor que no importa para obtener cierto resultado se puede marcar con un guion "-".

LTI – Plan 2024 9

 Metodologías del Testing Funcional

Ejemplo:

Vamos a crear una tabla de decisión para una página de inicio de sesión.

Las condiciones son simples, si se proporciona un usuario y una contraseña válida, el usuario puede
iniciar sesión exitosamente, de lo contrario aparecerán mensajes de error. Para la siguiente tabla
E=Error, S=Inicio de sesión exitoso.

Ya con esta tabla fuimos capaces de generar 4 casos de pruebas para probar una página de inicio de
sesión.

LTI – Plan 2024 10

 Metodologías del Testing Funcional

Ejemplo 2:

Las decisiones de entrada se representan en formato de tabla, compuestas por las condiciones dadas,
donde encontramos cabeceras de columna y fila, y acciones, representadas como puntos de
intersección de los casos condicionales de la tabla. Las tablas de decisiones son usadas especialmente
cuando las reglas de negocio tienen varias condiciones.

Como un conjunto de reglas if/else la tabla de decisiones es manejada por la interacción de

condiciones y acciones. Las reglas de decisiones encontradas en una tabla de decisión establecen el
procedimiento a seguir cuando existen ciertas condiciones.

Veamos un ejemplo:

Para la realidad que vamos a plantear tenemos tres variables que se pueden combinar dando lugar a
diferentes acciones que representaran casos de prueba.

Entonces veamos la realidad:

En un local de compras se ofrecen beneficios si pagamos con determinada tarjera:

 Si pagan con tarjeta XXX GOLD tendrán un 15% de descuento.

 Si pagan con tarjeta XXX CLUB tendrán un 5% de descuento.
 Si la tarjeta (GOLD o CLUB) es modalidad joven, tendrán un 5% de descuento.

Identificadas las variables, vemos que los valores que pueden tomar ellas son dos, SI y NO.
 SI (pago con esa tarjera)
 NO (no pago con esa tarjeta)
 2*2*2 = 8

Primero debemos armar la tabla y poblarla con la combinación de valores posibles:

1 2 3 4 5 6 7 8

pago con tarjeta XXX SI SI SI NO NO SI NO NO

GOLD
pago con tarjeta XXX SI SI NO SI NO NO SI NO
CLUB
modalidad joven de SI NO SI SI SI NO NO NO
tarjeta

LTI – Plan 2024 11

 Metodologías del Testing Funcional

Lo siguiente es armar las condiciones posibles que se pueden dar según nuestra realidad:

1 2 3 4 5 6 7 8

SE PUEDE DAR? NO NO NO
· Si pagan con tarjeta X X
XXX GOLD tendrán un
15% de descuento.

· Si pagan con tarjeta X X

XXX CLUB tendrán un

5% de descuento.

· Si la tarjeta (GOLD o X X

CLUB) es modalidad
joven, tendrán un 5%
de descuento.

CALCULAR IMPORTE X X X X X
pago en

efectivo

Como resultado final vemos que el CASO 1, el CASO 2 y el CASO 5, van a estar fuera de los casos
posibles.

LTI – Plan 2024 12

 Metodologías del Testing Funcional

All pairs / Combinación por pares

Esta técnica se basa en la premisa de que la mayoría de los defectos del aplicativo, no son el resultado
de interacciones muy complejas en las que intervienen todas las posibles variables a la vez, sino que
son el resultado de las interacciones de dos únicas variables. El secreto aquí, es determinar cuáles son
los pares de variables críticas para el negocio que el aplicativo maneja.

Como se pronuncia en el párrafo anterior el secreto es determinar los pares de variables críticos,
rompiendo de esta manera el cubrimiento en profundidad de una funcionalidad, que significa, que
todos los valores posibles de cada variable sean utilizados en algún caso de prueba.

La idea es que cada valor posible de cada variable sólo estaría combinado una única vez con algunos
de los valores posibles de las otras variables.

Ejemplo:

Supongamos que tenemos un producto configurable (como actualmente lo son la enorme

mayoría) mediante la asignación de valores a 10 variables (muy pocos si los comparamos con la
realidad).

Cada variable tiene 10 valores posibles. Calculemos todas las combinaciones posibles:

10*10*10*…*10 = 10.000.000.000

Obtendríamos una cantidad de casos de prueba imposible de ejecutar manualmente.

Debemos tomar como foco que para lograr cobertura en nuestros casos de prueba no alcanza con la
combinación de valores sino que tenemos que pensar además, en los resultados esperados para cada
combinación.

Por otra parte, probablemente muchos de estos resultados sean iguales, o sea que los casos de prueba
serían redundantes y no aportarían valor a las pruebas. O dicho de otra manera serían casos de prueba
equivalentes, cuyos valores de entrada pertenecen a las mismas clases de equivalencia.

Recordemos que el diseño de casos de prueba es un desafío para lograr simultáneamente:

• Un número lo más reducido posible de casos

• Un cubrimiento lo más amplio posible

LTI – Plan 2024 13

 Metodologías del Testing Funcional

Qué podemos hacer con esta técnica:

Esta técnica se basa en la conjetura de que muchos incidentes se producen cuando interactúan ciertos
pares de valores posibles de dos variables independientes entre sí.

La técnica Combinación por pares (all pairs) permite generar un conjunto de casos de prueba en el
cual estén representados, al menos una vez, todos los pares de valores posibles de las variables
identificadas.

Los incidentes que podemos detectar con esta técnica son de tipo singular (single) o doble (double):

 Singular – Pueden detectarse incidentes porque una variable toma un cierto valor
 Doble – Pueden detectarse incidentes por la combinación de ciertos valores de 2 variables

A continuación veremos cómo obtener manualmente combinaciones que contengan todos los pares
de valores posibles de las variables identificadas.

Supongamos que un producto de software maneja las siguientes variables:

 Género: Femenino, Masculino

 Nacionalidad: Uruguaya, Argentina, Otra
 Estado civil: Soltero, Casado, Otro

Es muy importante destacar la independencia entre las variables. El género de una persona es
totalmente independiente de su nacionalidad y de su estado civil.

Calculemos todas las combinaciones aplicando el producto cartesiano de los valores posibles:

2*3*3 = 18

A continuación veremos todas las posibles combinaciones de estas variables.

LTI – Plan 2024 14

 Metodologías del Testing Funcional

Ahora tratemos de generar todas las combinaciones por pares. Tomemos por ejemplo la variable
Género. Si aplicamos la técnica de combinación por pares sus valores posibles se tienen que combinar
con todas las Nacionalidades y Estados civiles, al menos una vez.

Construyamos las tablas correspondientes y luego apliquemos un posible algoritmo, manualmente,

para obtener el conjunto deseado.

LTI – Plan 2024 15

 Metodologías del Testing Funcional

Tomamos un par inicial y a partir de él escribimos los valores de entrada para un posible caso de
prueba y lo coloreamos con naranja en nuestras tablas:

Femenino, Uruguaya, Soltero

Luego tomamos otros pares que aún no hayamos visitado, y los coloreamos de azul, por
ejemplo:

Femenino, Argentina, Otro

LTI – Plan 2024 16

 Metodologías del Testing Funcional

Y así seguimos tomando pares no visitados y combinándolos hasta que todos los pares estén
considerados por lo menos una vez en el conjunto obtenido. Tomamos entonces y los coloreamos de
gris: Femenino, Otra, Soltero

Observemos que el par Femenino, Soltero ya fue visitado y coloreado de naranja, coloreamos en gris
entonces Femenino, Otra, Casado.

LTI – Plan 2024 17

 Metodologías del Testing Funcional

Representamos en una tabla las combinaciones que vamos obteniendo:

Femenino ya lo combiné con todas las nacionalidades y todos los estados civiles.

Prosigo con Masculino entonces y coloreo de marrón: Masculino, Uruguaya, Soltero.

Observemos que el par Uruguayo, Soltero ya fue visitado y coloreado de naranja.

Probamos entonces: Masculino, Uruguaya, Casado y verifico que ninguno de los pares fue
visitado aún.

Proseguimos con: Masculino, Argentina, Soltero

LTI – Plan 2024 18

 Metodologías del Testing Funcional

Proseguimos con: Masculino, Otra, Otro

Hasta el momento tenemos las siguientes combinaciones:

LTI – Plan 2024 19

 Metodologías del Testing Funcional

Ahora tengo que ver qué pares quedaron sin combinar.

Todos los demás pares ya fueron visitados, o sea, que podemos tomar cualquier valor de la variable
Género para las combinaciones faltantes y la representamos con el símbolo “~”. Elegimos la que
consideremos que por alguna razón tiene más probabilidades de detectar un incidente.

¿Por qué quedaron al final pares sin visitar para algunas de las variables? Porque las variables no
tienen el mismo número de valores posibles y las tablas correspondientes tienen largos diferentes.

LTI – Plan 2024 20

 Metodologías del Testing Funcional

Resumen:

Luego de ver los ejemplos de la presentación podemos evaluar la técnica y resumir sus ventajas y
limitaciones.

Ventajas:

 Si modelamos la realidad identificando un número importante de variables con varios valores

posibles e independientes entre sí es recomendable comenzar el diseño generando las
combinaciones por pares

 Existen muchas herramientas que asisten al diseñador para generar las combinaciones por
pares

 Se garantiza así el cubrimiento de todos los pares de valores posibles

 No implica “trabajo extra” y es un buen punto de partida, porque siempre tenemos que
identificar las variables involucradas y sus posibles valores.

Limitaciones y riesgos:

 Solamente se garantiza el cubrimiento de pares y podrían no detectarse incidentes que se

producen por la interacción de un número mayor de valores posibles

 Podría no generarse alguna combinación importante o frecuentemente ejecutada

 Algunas variables aparentemente independientes en un primer momento, podrían sin

embargo presentar valores posibles dependientes (como en el caso de los sistemas operativos
y los navegadores del ejemplo) y pueden, por lo tanto, generarse combinaciones inválidas

Pasos a seguir

 Identificar variables, dominios y valores posibles. Pueden nuevamente surgir dominios en los
que sea necesario aplicar primero clases de equivalencia

 Generar las combinaciones por pares

 Analizar combinaciones inválidas

 Considerar combinaciones particulares

LTI – Plan 2024 21

 Metodologías del Testing Funcional

Finalmente, veamos cómo podemos enmarcar la técnica de combinación por pares en la concepción
general de las técnicas de diseño de casos de prueba que adoptamos:

 Modelo de la realidad: Variables independientes con varios valores posibles

 Estrategia de selección: Algoritmos para utilizar cada par de valores al menos una vez en una
combinación de valores posibles

 Criterio de cubrimiento: Todos los pares de valores

 Teoría de errores: Los errores más típicos son de tipo singular (single) o doble (double)

Técnica de Transición de Estado (State Transition Testing)

En esta técnica las condiciones de entrada provocan cambios de estado. Es ideal para cuando el
sistema bajo prueba dependiendo de eventos o valores pasados y para cuando se debe probar un
sistema que consta de una secuencia de eventos. Ejemplo:

Utilizando el mismo de inicio de sesión de la técnica anterior, supongamos que si una persona
introduce una contraseña incorrecta tres veces seguidas el usuario se bloquea. Veamos cómo se
representa esto en un diagrama de transición de estado.

LTI – Plan 2024 22

 Metodologías del Testing Funcional

La cobertura para esta técnica se mide, habitualmente, como el número de estados o transiciones
identificados probados, dividido por el número total de estados o transiciones identificados en el
sistema, y es normalmente expresado como un porcentaje.

EJECUCIÓN DE CASOS DE PRUEBA

Ejecutar los casos de prueba diseñados, es “salir del papel” (o de la herramienta usada para el diseño
de los casos) y poner “manos a la obra” en el aplicativo en sí. Para poder realizar esta tarea, es
imprescindible que el equipo de desarrollo haya liberado el aplicativo al ambiente de pruebas.

Al igual que el diseño y generación de los casos de prueba, la ejecución de los mismos es una de las
actividades que se realizan dentro del ciclo de vida de testing, en cualquier proyecto informático.

Validación y Verificación

La Verificación busca comprobar que el sistema cumple con los requerimientos especificados
(funcionales y no funcionales); responde a las preguntas: ¿El software está de acuerdo con su
especificación? ¿Estamos construyendo el producto correctamente?

Mientras que la Validación, busca comprobar que el software hace lo que el usuario espera; responde
a las preguntas: ¿El software cumple las expectativas del cliente? ¿Estamos construyendo el producto
correcto?

Error / Defecto / Falla

Son términos parecidos, pero no significan lo mismo. Veamos qué es cada cosa y cuáles son las
principales diferencias.

Un error, es un tema de programación, se trata de una equivocación humana. El desarrollador puede

dejar un error en el código fuente del aplicativo que está creando o modificando. Por ejemplo, al
asignar valores distintos a una misma variable dentro de un mismo flujo. En el momento en que se
compila el código, este error no es detectado; tampoco será detectado durante las pruebas unitarias,
si al correr el aplicativo, no se pasa exactamente por esa parte del código. Este error será detectado
al ejecutar las pruebas diseñadas por testing, en el momento en que el sistema falla; aquí es que
detectamos un defecto.

En resumen: un error lleva a uno o más defectos que están presentes en un producto de software; un
defecto lleva a cero, una o más fallas (son la manifestación del defecto) al momento de ejecutar dicho
producto.

LTI – Plan 2024 23

 Metodologías del Testing Funcional

Dentro de la disciplina de testing, el término más popular es defecto (reportamos y administramos

defectos).

¿Para qué me sirve medir la cobertura de pruebas?

Algunos ejemplos podrían ser:

● Medir la calidad de cómo barro (en base al criterio establecido).

● Determinar cuándo parar de barrer (en base al criterio establecido).
● Viendo lo que ya barrí, pensar en qué más barrer (en base al criterio establecido).

Imaginarás lo importante que es establecer un buen criterio.

Tal como dice Michael Bolton en este artículo, lo útil de la cobertura es poder decir qué tan profundo
examinamos un sistema X en base a un modelo del sistema X.

Unos criterios pueden ser más fuertes que otros, entonces el conocerlos me puede dar un indicador
de qué tan profundas son las pruebas, cuándo aplicar uno y cuándo otro. Por ejemplo, se dice que un
criterio A subsume a otro criterio B si cualquier conjunto de casos de prueba que cubre el criterio A
también cubre el criterio B.

Siguiendo la analogía:

● Criterio 1: barrer cada habitación.

● Criterio 2: barrer cada pieza (habitaciones, comedor, cocina, baño, etc.).
● Criterio 3: barrer cada pieza, incluso en las esquinas, porque ahí hay más posibilidades de
que se acumule mugre.

El criterio 3 subsume al criterio 2, el cual subsume al criterio 1 (y la relación es transitiva, con lo cual
el criterio 3 subsume al criterio 1).

La analogía es evidente

LTI – Plan 2024 24

 Metodologías del Testing Funcional

Ejemplos más aplicados a las pruebas de software podrían ser:

● Risk coverage: qué tanto examinamos el sistema en base a un modelo de riesgos.

● Requirements coverage: qué tanto examinamos el sistema en base a un modelo de
requerimientos.
● Code coverage: qué tanto examinamos el sistema en base a un modelo del código.

Las técnicas de diseño de casos de prueba están siempre asociadas a un criterio de cobertura, y
justamente lo que plantean es realizar un modelo del sistema bajo pruebas.

LTI – Plan 2024 25