Semana 11 – Pruebas de Software

Definición
La prueba de software es el proceso de evaluar y verificar que un producto o aplicación de
software hace lo que se supone que debe hacer.

Los beneficios de las pruebas incluyen la prevención de errores, la reducción de los costos de
desarrollo y la mejora del rendimiento.

Las pruebas de software son una parte integral del ciclo de vida del desarrollo de software
(SDLC). Las pruebas son la forma en que, se puede estar seguro acerca de la funcionalidad, el
rendimiento y la experiencia del usuario. Ya sea que realice sus pruebas manualmente o a
través de la automatización, cuanto antes y más a menudo pueda llevar a cabo pruebas, más
probable es que identifique errores, asegurándose de que su aplicación de software haya sido
revisada y auditada a fondo antes de que esté frente a sus usuarios.

Historia de las pruebas de software

Las pruebas de software llegaron junto con el desarrollo de software, que tuvo sus inicios justo
después de la segunda guerra mundial. Al informático Tom Kilburn se le atribuye la escritura
de la primera pieza de software, que debutó el 21 de junio de 1948 en la Universidad de
Manchester en Inglaterra. Realizó cálculos matemáticos utilizando instrucciones de código de
máquina.

La depuración era el principal método de prueba en ese momento y lo siguió siendo durante
las siguientes dos décadas. En la década de 1980, los equipos de desarrollo miraban más allá
de aislar y corregir errores de software para probar aplicaciones en entornos del mundo real.
Estableció el escenario para una visión más amplia de las pruebas, que abarcaba un proceso de
control de calidad que formaba parte del ciclo de vida del desarrollo de software.

"En la década de 1990, hubo una transición de las pruebas a un proceso más completo llamado
garantía de calidad, que cubre todo el ciclo de desarrollo de software y afecta los procesos de
planificación, diseño, creación y ejecución de casos de prueba, soporte para casos de prueba
existentes y entornos de pruebas", dice Alexander Yaroshko en su publicación en el sitio para
desarrolladores de uTest.
"Las pruebas habían alcanzado un nivel cualitativamente nuevo, lo que condujo a un mayor
desarrollo de metodologías, la aparición de herramientas poderosas para gestionar el proceso
de pruebas y herramientas de automatización de pruebas"

El proceso de desarrollo de proyectos de software y la metodología de desarrollo

El desarrollo de proyectos SW y el ciclo de desarrollo de pruebas
Un proceso de desarrollo de software es el conjunto estructurado de las actividades requeridas
para elaborar un sistema de software, estas actividades son: análisis y definición de
requerimientos, diseño, implementación (codificación), pruebas y mantenimiento. A
continuación se describe brevemente en qué consiste cada una de estas actividades.

Análisis y definición de requerimientos

Se trabaja con los clientes y los usuarios finales del sistema para determinar el dominio
de aplicación y los servicios que debe proporcionar el sistema así como sus
restricciones. Con esta información se produce el documento de “especificación de
requerimientos del Sistema”.

Diseño del sistema y del software

Durante el proceso de diseño del sistema se distinguen cuáles son los requerimientos
de software y cuales los de hardware. Después se establece una arquitectura completa
del sistema. Durante el diseño del software se identifican los subsistemas en los cuales
estará compuesto el sistema y se describe cómo funciona cada uno y las relaciones
entre éstos.

Implementación y pruebas
Consiste en codificar y probar los diferentes subsistemas por separado. La prueba de
unidades implica verificar que cada una cumpla su especificación (proveniente del
diseño).

Integración y validación del sistema

Una vez que se probó que funciona individualmente cada una de las unidades, éstas se
integran para formar un sistema completo que debe cumplir con todos los
requerimientos del software. Cuando las pruebas del sistema completo son exitosas,
éste se entrega al cliente.

Mantenimiento
El sistema se instala y se pone en funcionamiento práctico. El mantenimiento implica
corregir errores no descubiertos en las etapas anteriores del ciclo de vida y mejorar la
implantación de las unidades del sistema para darle mayor robustez (y no nuevas
funcionalidades).

El proceso de pruebas
El proceso de pruebas puede verse como parte del proceso de desarrollo de software, o como
un proceso aparte. En la Figura se ilustra el proceso de pruebas visto de manera
independiente.
 Planificación
Durante esta fase se define el plan global de las pruebas: el plan de pruebas (agenda
de las actividades de prueba, objetivos y requerimientos de las pruebas, personal que
va a hacer las pruebas, recursos SW y HW ), riesgos y definición de las herramientas a
utilizar.

Diseño
Durante esta fase se identifican los elementos que deben ser probados. Se especifican
las condiciones y datos de prueba en base a los elementos a probar. Se diseña la
estructura de las pruebas y el ambiente que requieren. Las pruebas se estructuran, se
organizan por grupos y categorías, y se les asignan prioridades en base a un análisis de
riesgos.

Ejecución
Es el proceso de llevar a cabo las pruebas especificadas, observando y reportando los
resultados. Algunos autores incluyen la instalación y configuración del ambiente para
ejecutar las pruebas en la fase de diseño y otros en la de ejecución.

Control
Durante el diseño y ejecución de las pruebas se lleva a cabo un control que tiene como
objetivos: monitorear el progreso, medir y analizar los resultados, realizar acciones
correctivas y tomar decisiones estratégicas.

En la Figura se muestra el proceso de ejecución de las pruebas. Se pueden ejecutar varias

pruebas al mismo tiempo, cuando éstas son independientes entre sí.
Normalmente, un proyecto de Software utiliza un 40% del esfuerzo total de desarrollo en la
fase de pruebas. Sin embargo, en ciertos proyectos se llega a invertir hasta un 80%. ¿Cómo se
determina la cantidad de esfuerzo que será razonable invertir en la fase de pruebas?

Si se trata de un Software que no es muy complicado y que fue diseñado en poco tiempo, ¿se
debe invertir mucho tiempo en probarlo? Si se trata de un Software que implementa un juego
para teléfonos celulares ¿cuánto tiempo hay que dedicar a probarlo? La respuesta a estas
preguntas es un compromiso entre lo complejo del Software y la gravedad de las
consecuencias.

El primer caso puede ser el de un Software simple pero que será usado en un marcapasos en
donde una falla puede ocasionarle la muerte al usuario. El segundo caso puede ser el de un
Software que si falla no ocasiona graves daños pero puede tratarse de un Software muy
complejo y difícil de crear. En conclusión, si el Software es más complicado que otro o si las
consecuencias de una falla son más graves que la de otro entonces deberá usarse más tiempo
de prueba. Comúnmente es la complejidad del Software lo que más se toma en cuenta al
planear el esfuerzo dedicado a una fase de pruebas, y no se toma en cuenta la gravedad de las
consecuencias de las fallas las cuales deberían tener un mayor peso.

En el estándar IEEE 1012 Software Verification and Validation se establece (entre muchas otras
cosas) un sistema de 4 niveles llamados niveles de integridad del Software que determinan la
cantidad y el detalle de las actividades de Verificación y Validación del Software durante los
diferentes procesos del ciclo de vida del SW. Los niveles de integridad son:

 Nivel 4: El Software o componente del Software debe funcionar bien o de lo contrario

habrá consecuencias graves (muerte, destrucción del sistema, pérdidas económicas o
sociales) que no pueden ser mitigadas.
 Nivel 3: El Software o componente del Software debe funcionar bien o de lo contrario
el propósito para el que fue creado no se logrará causando serias consecuencias
 (lesiones permanentes, degradación del sistema, impacto económico o social) que
pueden ser mitigadas por lo menos parcialmente.
 Nivel 2: El Software o componente del Software debe funcionar bien o de lo contrario
alguna de las funciones no será realizada causando consecuencias menores que
pueden ser mitigadas totalmente.
 Nivel 1: El Software o componente del Software debe funcionar bien o de lo contrario
alguna de las funciones no será realizada causando consecuencias insignificantes que
no requieren mitigación alguna.

Ventajas de las pruebas de software

Pocos pueden argumentar en contra de la necesidad de un control de calidad al desarrollar
software. Los retrasos en las entregas o los defectos del software pueden dañar la reputación
de una marca, lo que provoca la frustración y la pérdida de clientes. En casos extremos, un
error o defecto puede degradar los sistemas interconectados o causar fallas graves.

Considere la posibilidad de que Nissan tenga que retirar más de 1 millón de automóviles
debido a un defecto de software en los detectores del sensor de la bolsa de aire. O un error de
software que provocó el fracaso del lanzamiento de un satélite militar de 1,200 millones de
USD.  Los números hablan por sí mismos. Las fallas de software en los EE. UU. costaron a la
economía USD 1.1 billones en activos en 2016. Además, impactaron a 4.400 millones de
clientes. 

Aunque las pruebas cuestan dinero, las empresas pueden ahorrar millones por año en
desarrollo y soporte si cuentan con una buena técnica de prueba y procesos de control de
calidad. Las primeras pruebas de software descubren problemas antes de que un producto
salga al mercado. Cuanto antes reciban los equipos de desarrollo los comentarios de las
pruebas, antes podrán abordar problemas como:

 Defectos arquitectónicos
 Malas decisiones de diseño
 Funcionalidad no válida o incorrecta
 Vulnerabilidades de seguridad
 Problemas de escalabilidad

Cuando el desarrollo deja un amplio espacio para las pruebas, mejora la confiabilidad del
software y las aplicaciones de alta calidad se entregan con pocos errores. Un sistema que
cumple o incluso supera las expectativas del cliente genera potencialmente más ventas y una
mayor cuota de mercado.

Las pruebas de software permiten ahorrar tiempo y dinero a la organización, ya que reducen
los costes de desarrollo y mantenimiento del software.

Además, aportan una garantía de estabilidad al desarrollo de funciones nuevas. Con estas
pruebas se garantiza que una función se comporte según lo previsto y que los usuarios no
detecten errores.

El tiempo de desarrollo de funciones nuevas disminuye, ya que se especifica un conjunto de

casos de prueba que la función nueva debe cumplir para que se considere terminada y lista
para entregar. De este modo, los desarrolladores pueden trabajar con un único objetivo para
obtener estimaciones más precisas del cronograma y minimizar la aparición de nuevos errores.
Una vez implementados esos casos de prueba, se reducen los costes generales de
mantenimiento. Las pruebas se pueden ejecutar con una función ya entregada para garantizar
que se siga comportando según lo previsto.

Roles en el proceso de las pruebas de software

El equipo de pruebas
Existen diferentes roles de las personas que participan en un equipo de pruebas. Éstos son el
de líder, diseñador, probador (tester) o consultor.

El líder de prueba: es quien dirige el proyecto de prueba, es decir, escribe el plan de prueba,
maneja los recursos (personal, SW, y HW), administra el presupuesto, coordina al equipo,
supervisa el avance, detecta y resuelve problemas y toma decisiones estratégicas.

Los diseñadores de pruebas: hacen el diseño de los casos de prueba a partir de las
especificaciones del producto. Es decir, analizan, revisan y evalúan los requerimientos del
usuario, las especificaciones y los modelos para las pruebas, crean las especificaciones para las
pruebas, instalan el ambiente de prueba, adquieren y/o elaboran los datos para las pruebas,
revisan las pruebas desarrolladas por otros.

Los probadores (Testers): ejecutan los casos de prueba y reportan los resultados. Un
consultor: ayuda a dirigir al equipo y orienta sobre las mejores prácticas para llevar a cabo las
pruebas.

Tipos de pruebas de SW

En las fases previas a la de pruebas, el ingeniero de Software es un creador y debe hacer su

tarea con la confianza de que puede lograr el objetivo. Por el contrario, la fase de pruebas, se
trata de hacer evidente lo que el Software no cumple, es decir, en cierta forma es una fase
destructiva, es decir, durante las pruebas se busca detectar lo malo que hay en el SW. Cuando
se diseñan las pruebas que deberán realizarse, se debe descartar la idea de que el Software
está bien hecho. Por esto, si la misma persona que diseña el Software es la que diseña sus
pruebas, puede haber un conflicto de intereses, pues por ejemplo, el diseñador podría diseñar
casos de prueba a la medida, ya sea porque no puede ver más allá o porque intencionalmente
prefiere que el Software pase las pruebas. De cualquier manera, en este caso las pruebas no
tendrían una alta probabilidad de detectar todos los defectos y por lo tanto no serían unos
buenos casos de prueba.

El proceso de pruebas debe ser visto como el proceso destructivo para encontrar errores (cuya
presencia se asume) en un programa. Si el objetivo de la prueba es encontrar defectos, un caso
de prueba exitoso es uno que hace fallar al programa.

Si se quisiera probar por completo un sistema, tendríamos que probar todas las posibilidades,
es decir, hacer una prueba exhaustiva. La prueba exhaustiva requiere probar el
comportamiento de un programa para todas las combinaciones validas e invalidas de entradas.
Además se debe probar en cada punto donde se ingresan datos, y bajo cada estado posible del
programa en ese punto. Un programa sencillo podría tener centenares o millones de
combinaciones posibles, y el tiempo requerido para probarlas todas resulta prohibitivo.
Entonces, un objetivo razonable es encontrar un conjunto de pruebas tales que se maximice el
número de defectos encontrados pero con un número de pruebas finito y costeable.

Un buen caso de prueba es aquel en el que hay una buena probabilidad de hacer evidente, y
con el menor esfuerzo posible, un defecto que no ha sido encontrado previamente.

Es importante aclarar aquí que el hecho de que el Software pase todas las pruebas no significa
que no tenga defectos, sino que éstos no fueron detectados por las pruebas. Lo único que
puede asegurarse es que cuando el Software no pasa las pruebas es que hay algún defecto ya
sea en el Software o en el diseño de la prueba. Así que surgen las siguientes dos preguntas:

1. ¿Qué puede concluirse cuando el Software pasa un caso de prueba?

Respuesta: Que posiblemente el diseño del Software está bien hecho (pues podría no
pasar en otros casos), o que posiblemente el caso de prueba está mal hecho, ya que
quizás no se le exigió mucho al software.
2. ¿Qué puede concluirse cuando el Software no pasa un caso de prueba?
Respuesta: Hay dos posibilidades: 1) que el Software tiene un defecto y que el caso
prueba tuvo éxito o 2) que el Software está bien pero el caso de prueba está mal
diseñado. En cualquiera de estas dos posibilidades es necesario ejercer una acción
correctiva ya sea en el Software o en el diseño del caso de prueba.

Técnicas de caja negra y de caja blanca

Existen varias técnicas para elaborar las pruebas. Una de las técnicas de pruebas son las de
caja negra y de caja blanca. Como se observa en la figura, las pruebas de caja negra son
aquellas en las que el producto es visto como una caja sin luz en donde no es posible ver la
forma en la que llevan a cabo sus funciones, lo único visible son sus interacciones con lo
exterior, es decir, sus interfaces externas. Las pruebas de caja blanca son, por el contrario,
aquellas en donde todos los detalles y la forma en la que funciona el producto están
disponibles para el diseñador de pruebas, así que puede diseñar casos de prueba para cada
uno de estos detalles.

El cliente no requiere ver la ejecución de pruebas de caja blanca ya que no le interesan los
detalles sino el funcionamiento general de lo que se especificó durante el análisis de
requerimientos. El cliente requiere sólo pruebas de caja negra a nivel general. Sin embargo
para el proceso de desarrollo es necesario llevar a cabo pruebas con mucho más detalle ya sea
de caja negra o de caja blanca.

Las pruebas de caja blanca tienen la ventaja de que pueden cubrir por completo toda la
funcionalidad del Software exhaustivamente. Con ellas se puede probar toda la lógica interna
de cada subrutina del código y todas las posibles rutas de flujo del programa. La desventaja es
que para diseñarlas y ejecutarlas se requiere de mucho tiempo. Y podría ser imposible diseñar
y ejecutarlas todas.

Las pruebas de caja negra son entonces una alternativa viable. En éstas, se diseñan casos de
prueba en función de las interfaces diseñando las posibles entradas al sistema y las respuestas
esperadas ante ellas. Estas pruebas se diseñan como “escenarios” en los que se señala la
secuencia de las activaciones de las interfaces de un módulo a otro. Los accesos a archivos son
también interfaces que deben probarse buscando casos donde se viole la integridad de los
datos.

Tipos de Pruebas por su alcance

Las pruebas tanto de caja negra como de caja blanca se pueden diseñar a diferentes niveles.
Dependiendo del nivel, las pruebas serán diseñadas en diferentes fases del desarrollo del SW.
Se identifican 4 niveles: pruebas de módulo, de integración, de sistema y de aceptación.

Pruebas de módulo
También llamadas “de componente” o “de unidad” son pruebas que pueden ser de caja
negra o de caja blanca y se diseñan para probar la funcionalidad de un sólo módulo.
Para poder realizarlas a veces es necesario crear un módulo cuya única función es
interactuar con el módulo a probar de manera que se cubran los casos de prueba
diseñados para éste.

Estas pruebas deben diseñarse a partir del documento de diseño detallado si son de
caja negra y a partir del código si son de caja blanca.

Pruebas de integración
Estas pruebas se realizan uniendo varios módulos para probar sus interfaces y las
interacciones entre ellos. Se parte del supuesto de que es posible que haya
inconsistencias en las interfaces, y/o que la interacción entre ellos puede generar
comportamiento distinto al mostrado cuando se les prueba individualmente.

Estas pruebas son diseñadas normalmente como de caja negra a partir del documento
de diseño de alto nivel y del documento de requerimientos.

Pruebas de sistema
El diseño de estas pruebas se basa principalmente en la especificación de
requerimientos. Se ejecuta el sistema completo con el fin de verificar que la presencia
de todos los componentes o módulos no afecta a la funcionalidad probada
anteriormente en las pruebas de integración y en las de módulo. Estas pruebas se
hacen para finalizar la fase de desarrollo del Software.

Pruebas de aceptación
Son similares a las pruebas de sistema pero orientadas a obtener la aceptación por
parte del cliente. En estas pruebas se instala el sistema en un ambiente de operación
real aunque posiblemente controlado y/o limitado. Y se diseñan exclusivamente a
 partir del documento de requerimientos. Normalmente son un subconjunto selecto de
las pruebas de sistema.

Pruebas de Regresión
Las pruebas de regresión se llevan a cabo para verificar que no ocurrió una regresión
en la calidad del producto luego de un cambio. Con estas pruebas se asegura que los
cambios no introducen un comportamiento no deseado en otras áreas ya probadas.
Implican la re- ejecución de alguna o todas las pruebas realizadas anteriormente.

Productos y herramientas de pruebas de software

El estándar IEEE Standard for Software Test Documentation 829-1998 describe el contenido de
la documentación para la fase de pruebas. El conjunto de documentos de prueba que deberán
ser creados dependerá de cada proyecto en función de la experiencia. Se recomienda usar
estos documentos inicialmente sólo en pruebas de sistema y de aceptación para luego irlos
introduciendo en pruebas de integración y de módulo progresivamente.

A continuación se describen brevemente los documentos de un proceso de pruebas.

Plan de pruebas
El Plan de pruebas es el documento en el que se describe el alcance, la estrategia, los recursos
necesarios y la agenda o calendarización de todas las pruebas que se llevarán a cabo en un
proyecto.

En éste se identifica qué partes y qué funciones serán probadas y cuáles no. Se describen las
tareas que se deben realizar y quiénes son los responsables, por ejemplo: la administración del
proyecto, el departamento de diseño de SW, el departamento de pruebas. También se define
la participación que tendrá el cliente. Se identifican los riesgos existentes y se prevén las
acciones necesarias en caso de una contingencia para poder cumplir con los tiempos de
entrega.

El plan de pruebas contiene las siguientes secciones:

Información de control: Identificador, autor, estado, lista de distribución, proyecto al

que pertenece, etc.

Introducción: Describe la relación de este plan con el plan del proyecto, con el plan de
aseguramiento de la calidad, y con cualquier otro documento. Se indica qué es lo que
se va a probar en términos generales.

Partes que se prueban y las que no se prueban: Debe incluir la lista de los módulos
que serán probados y los que no.

Funcionalidad que se prueba y la que no: Se enlistan los documentos de diseño de

prueba incluidos en el plan y una breve descripción. La funcionalidad que no se prueba
debe también indicarse.

Estrategia general de las pruebas: Indicar qué tipo de pruebas se harán y quienes o
qué grupos las harán. Estimar el tiempo que deberá llevarse toda la fase de pruebas.
Describir cómo se medirá el alcance de las pruebas (porcentaje del código que será
ejecutado) y el grado de avance en ellas.

Criterios generales de aprobación: describir los criterios para determinar si un módulo

pasó o no la fase de pruebas.
 Criterios de suspensión y de reanudación: Determinar en qué casos debe suspenderse
el proceso y bajo qué circunstancias puede reanudarse. Puede usarse por ejemplo un
criterio en el que si el Software no pasa un cierto número de pruebas, se debe
suspender las pruebas hasta que se tenga una nueva versión del SW. Otra posibilidad
para detener las pruebas es que el Software no pase una prueba crítica o que se
exceda un cierto tiempo prefijado.

Documentación de pruebas que debe entregarse: lista de documentos generados

antes y durante las pruebas. Debe incluir al menos toda la documentación descrita en
el estándar IEEE 829.

Tareas: preparación, ejecución, monitoreo, decisiones.

Requisitos para iniciar: HW, SW, qué herramientas, qué documentos.

Responsabilidades: cada tarea debe asociarse con un responsable.

Capacitación: El nivel de capacitación mínimo que los responsables de las tareas deben
tener para llevarlas a cabo.

Calendarización: En lo posible determinar fechas para cada actividad y tarea.

Riesgos y planes de contingencia: prevenir cualquier contratiempo y cómo resolverlo.

Pueden considerarse inasistencias del personal, fallas externas (de energía, huelgas),
etcétera. Hay que considerar trabajar horas extras u otras soluciones adecuadas.

Diseño de pruebas
El Diseño de pruebas es un documento en el que se describe un grupo de casos de pruebas
relacionadas entre sí. Cada documento de este tipo debe estar referenciado en el plan de
pruebas y contiene las siguientes secciones:

Información de control: Identificador, autor, estado, lista de distribución, plan de

pruebas al que pertenece, etc.

Descripción: una descripción general de la funcionalidad que se prueba y su relación

con los documentos de requerimientos y/o de diseño.

Procedimiento de prueba: describir cómo se deben llevar a cabo en general las

pruebas abarcadas por este diseño. Incluir si deben usarse herramientas adicionales
como comparadores de texto u otras.

Lista de casos de prueba: Listar en breve los identificadores y los nombres de cada
caso de prueba incluido en el diseño de prueba. Los casos de prueba pueden ser de
caja negra o blanca.

Criterios de aprobación: Describir cómo determinar si el conjunto de pruebas puede

considerarse como aprobado.

Casos de prueba
Un Caso de prueba es un conjunto de valores de entrada, precondiciones de ejecución,
resultados esperados y postcondiciones de ejecución, desarrollados con un objetivo particular
o condición de prueba.

En cada documento de este tipo se describe un sólo caso de prueba el cual debe ser parte de
un diseño de prueba. Este tipo de documento contiene las siguientes secciones:
 Información de control: Identificador, autor, estado, lista de distribución, diseño de
prueba al que pertenece, etc.

Descripción: Parte y caso que se prueba. Establece la relación con otros documentos
como el diseño de prueba, el plan de prueba, el de diseño y el de requerimientos.

Datos de entrada: los parámetros exactos que se requieren para iniciarla o los datos
de entrada que se reciben por ejemplo de un archivo o las respuestas recibidas desde
otros subsistemas. Las condiciones iniciales, es decir, el estado de cada variable que
afecta a la prueba. Puede incluirse el estado de la pantalla como una condición inicial.

Datos de salida esperados: resultados entregados (valores) y/o los llamados a otros
subsistemas y sus parámetros y/o el estado final de las variables o de los archivos.
Puede incluirse el estado de la pantalla como estado final.

Requisitos de configuración: describir qué módulos deben estar y qué hardware.

Procedimientos o herramientas: Describir lo que debe hacerse y con qué

herramientas. De ser necesario puede hacerse referencia a otros documentos en
donde se describe el procedimiento.

Dependencia o relación con otros casos de prueba: decir si hay algún otro caso que
deba ejecutarse antes de este o después. Decir si algún otro caso depende del
resultado de éste.

Procedimiento de prueba
Un Procedimiento de prueba describe los pasos a seguir para evaluar cierta funcionalidad de
un sistema o subsistema. Contiene las instrucciones detalladas para la configuración, ejecución
y evaluación de los resultados de uno o varios casos de prueba. Un procedimiento de prueba
contiene las siguientes secciones.

Información de control: Identificador, autor, estado, lista de distribución, diseño de

prueba al que pertenece, etc.

Propósito: descripción breve y referencia a los casos de prueba y diseño de prueba

relacionados.

Requisitos especiales: ambiente necesario, habilidades o capacitación necesaria,

procedimientos previos a la ejecución de este procedimiento.

Pasos: describir los siguientes pasos si aplican:

Registro: modo en el que deben registrarse los eventos de la prueba como: resultados,
incidentes, etc.

Instalación: la secuencia de acciones para preparar la ejecución de la prueba.

Inicio: secuencia para dar inicio a la prueba.

Prosecución: acciones necesarias durante la ejecución.

Medición: descripción de la manera en que se harán mediciones.

Suspensión: acciones necesarias para suspender la prueba.

Reinicio: identificar puntos en donde se puede reiniciar y las acciones necesarias.

 Detención: acciones para detener en orden la prueba.

Restauración: acciones para restaurar el ambiente para la prueba.

Contingencias: acciones en caso de haber contingencias.

Bitácora de pruebas
En este documento se registran brevemente todos los eventos en orden cronológico que
suceden durante las pruebas. Contiene las siguientes secciones:

Información de control: Identificador, autor.

Descripción: cualquier información que aplique a todos los eventos registrados. Lista
de módulos que se están probando. Características del ambiente que se está usando
como: lugar, equipo, SW, etc.

Eventos: registrar fecha y hora del evento y una descripción breve. El tipo de eventos
que pueden registrarse incluyen:

 Inicio de procedimiento. Incluir identificador del procedimiento y caso de prueba,

personal que está ejecutándolo y la función de cada uno.
 Resultado de la prueba. Incluir todo lo observado como mensajes o
comportamientos del SW.
 Cambios en el ambiente de prueba. Substitución de HW, etc.
 Eventos anormales. Describir el evento y las condiciones previas y posteriores.
 Generación de reportes de incidente. Registrar el identificador del reporte de
incidente cada vez que se genere uno.

La Figura muestra la relación entre los documentos de un proceso de pruebas. Los Diseños de
Prueba, los Procedimientos de Prueba y los Test Log están asociados a un Plan de Pruebas.
Cada Diseño de Prueba contiene un grupo de Casos de Prueba. Cada Caso de Prueba se asocia
a un Diseño de Prueba, pero también puede asociarse a uno o a varios Procedimientos de
Prueba.

Reporte de transmisión o entrega de módulo

Este documento identifica los módulos Software que han sido entregados al departamento de
prueba y que, por lo tanto, se pueden iniciar o continuar las pruebas sobre ellos. Sirve como un
indicador de que el departamento de diseño ya terminó su labor y para hacerle saber al
departamento de pruebas que hay módulos que requieren ser probados.

Sus secciones son las siguientes:

Información de control: Identificador, autor.

Módulos: lista de módulos transmitidos y de los responsables de cada uno.

Ubicación: lugar en donde el personal de pruebas puede ubicar y tomar los módulos
entregados.

Estado: Indicar para cada módulo si se entregó completo o no de acuerdo con la

documentación. Indicar, en caso de ya haber sido probado, la lista de reportes de
incidente o T-records que fueron atendidos en esta entrega. Indicar si los cambios
afectan a la documentación del módulo (por ejemplo dentro del documento de diseño)
y si los cambios en esa documentación ya fueron realizados.

Aprobación: nombres y firmas de las personas que deben aprobar esta entrega.

Bitácora de pruebas (Test Log)

Registra los eventos durante la prueba. Cada vez que se ejecuta una prueba se registra en este
documento. Contiene la siguiente información:

 Identificador, autor
 Descripción
 ¿A qué plan de pruebas pertenece?
 Lista de eventos (en breve) indicando hora
 Inicio/fin de tareas, observaciones, condiciones existentes, eventos anormales.
 Identidad del reporte de incidente correspondiente (si existe)

Reporte de incidente de prueba o T-record (Trouble-record)

En un reporte de incidente se registra un evento, ocurrido durante la ejecución de alguna
prueba, que requiera investigarse. Normalmente se trata de reportes de fallas en el resultado
de una prueba lo que indica la posibilidad de que existan defectos en el SW. Otro tipo de
eventos puede también necesitar investigación aunque no sea por parte del departamento de
diseño. Es posible que una falla tenga su solución en el mismo departamento de pruebas pero
que el personal que lo reporta no sabe o no puede en ese momento resolverlo.

Un reporte de error debe contener: información de control, resumen, descripción e impacto. A

continuación se explica en qué consisten cada uno de estos aspectos.

Información de control: Identificador, autor.

Resumen: descripción del incidente, lista de módulos involucrados, identificador del

procedimiento de prueba, del caso de prueba y de la bitácora de pruebas.

Descripción: detalles del incidente. Debe incluir:

 Entradas
 Salidas esperadas
 Salidas obtenidas
 Anomalías
 Fecha y hora
  Paso del procedimiento en el que se dio
 Ambiente
 Repeticiones
 Probadores
 Observadores

Impacto: hasta donde el probador sepa debe indicar si este incidente afecta al plan de pruebas
o al documento de diseño de prueba o al de especificación de diseño del SW, etc.

En la Figura (Ciclo de reporte de Error), donde se ilustra el primer paso del proceso de los
Reportes de Error, se puede apreciar que éstos son el resultado de la detección de un defecto
en un producto de software. Se debe elaborar un Reporte de Error por cada defecto
encontrado.

Paso 1 : Elaboración de los Reportes de Error (RE) de un producto

Detección de un
defecto Elaboración de un RE1

Detección de un
defecto Elaboración de un RE2
Proy Actual
Productox
Versionn
... ...
Detección de un
defecto Elaboracion de un REm

Cada Reporte de Error (RE) debe pasar por el proceso de revisión. Al finalizar este proceso, el
RE tiene un estatus final de “Aceptado” o “Rechazado”, como se ilustra en el paso 2 de la
Figura.

Paso 2: Revisión de cada uno de los Reportes de Error (RE)

Paso 3: Generación de una versión del producto

Finalmente, se debe generar una nueva versión del producto, la cual debe incluir la atención
de cada uno de los reportes de error. Como se aprecia en el paso 3 de la Figura del paso 3, la
nueva versión que se genera tiene el número consecutivo a la versión anterior, por ejemplo, si
el producto es el documento de diseño, versión 2, entonces la nueva versión será la 3.

Resumen de pruebas (Test Data Summary)

El resumen de pruebas sirve para resumir los resultados de todas las pruebas y poder
evaluarlos. Éste debe contener:

Información de control: Identificador, autor.

Resumen: indicar qué módulos y qué pruebas se hicieron y en qué ambiente así como
una lista de documentos previos a las pruebas y documentos de pruebas relacionados
con cada módulo.

Variaciones: explicar cuáles fueron las variaciones que se produjeron a raiz del proceso
de pruebas en los módulos y en cualquier documento relacionado incluyendo a los
documentos de pruebas.

Cumplimiento de criterios de aprobación: establecer en qué grado se cumplieron los

criterios de aprobación descritos en el plan de pruebas.

Resumen de resultados: la cantidad total de pruebas que pasaron y la cantidad de

reportes de incidente generados y cuántos de éstos derivaron en la corrección de
algún defecto del Software y cuantos fueron resueltos de otra manera. Listar todos los
incidentes que no fueron resueltos.

Evaluación: se hace la evaluación de cada módulo explicando qué funcionalidad se

probó y se basa en los resultados de las pruebas relacionadas con cada uno. Se hace
una estimación del riesgo de falla para cada módulo.

Resumen de actividades: describir a grandes rasgos las actividades realizadas y los

eventos que surgieron. Indicar cuantos recursos fueron utilizados tanto humanos como
logísticos y el tiempo total que duró la fase de pruebas.

Aprobación: Fecha, firmas y nombres de cada una de las personas que deben dar su
aprobación de este reporte.

Productos comerciales y de código abierto

Existen herramientas comerciales y de código abierto que apoyan diversos aspectos de
proceso de pruebas. Estas herramientas se pueden clasificar como sigue.
  Herramientas para la administración de las pruebas y su proceso: Ayudan en el
seguimiento de incidentes, la gestión de la configuración y la administración de
requerimientos.
 Herramientas para apoyar el proceso de revisión y de modelado.
 Herramientas para el diseño de las pruebas y para la preparación de datos de prueba.
 Herramientas de ejecución de casos de prueba, de pruebas unitarias, comparadores.
 Herramientas de desempeño, de carga y de estrés, y de monitorización.

Utilizar herramientas de pruebas tiene ventajas y desventajas. Entre las ventajas se

encuentran: reducir el trabajo repetitivo (por ejemplo en las pruebas de regresión), mayor
consistencia y capacidad de repetición, evaluación objetiva, facilidad para el acceso a la
información de las pruebas.

Entre las desventajas de las herramientas de pruebas hay que mencionar que se requiere
esfuerzo adicional para aprender a utilizarlas. Además, se podría subestimar el tiempo, costo y
esfuerzo de inducción inicial en la herramienta, subestimar el tiempo y el esfuerzo necesarios
para alcanzar ventajas significativas y continuas con la herramienta, subestimar el esfuerzo
requerido para mantener los elementos de prueba generados por la herramienta, o podría
generarse demasiada confianza en una herramienta y sustituirla todas las pruebas manuales,
lo que podría disminuir el hallazgo de los defectos.

Bibliografía
https://www.atlassian.com/es/continuous-delivery/software-testing/types-of-software-testing

https://www.loadview-testing.com/es/blog/tipos-de-pruebas-de-software-diferencias-y-
ejemplos/

https://www.ibm.com/es-es/topics/software-testing

Calidad y pruebas en el desarrollo de software