Bloque 1Bloque 2Bloque 3Bloque 4Bloque 5Referencias

Aspectos técnicos del testing de software

1. La prueba de sistema dentro del ciclo de vida del

desarrollo
Hace más de 50 años, cualquier persona involucrada en software tenía el título de programador y
todo el foco estaba puesto en el código. No es que las etapas de análisis y diseño no se hicieran,
sino que no eran formalmente llevadas a cabo, ni tampoco estas fases tempranas eran
reconocidas; el punto de partida del trabajo concreto era el comienzo de la codificación, es decir,
cuando se comenzaba a programar.

Gradualmente, el análisis y el diseño fueron teniendo mayor énfasis hasta emerger como una fase
distinta en el ciclo de vida del software. Hoy, ya se considera fundamental en el proceso de
desarrollo que el análisis se encuentre completo y revisado antes de iniciar con la actividad de
diseño y que el diseño se encuentre completo y revisado antes de comenzar con la
programación.

Con las pruebas de sistemas vemos la misma evolución del pensamiento, pero con 15 o 20 años
de retraso. Inicialmente, las pruebas solo significaban ejecución, refiriéndose a pruebas dentro del
enfoque dinámico. Esto no quiere decir que una buena prueba no enfatizara en el análisis y diseño
de las pruebas, sino que simplemente no eran actividades reconocidas como fases con sus
entregables propios. Hoy, se reconoce que se necesitan construir casos de pruebas antes de
correrlos y que la planificación y análisis de los objetivos, así como los requerimientos de pruebas
tienen que ser realizados antes de diseñar y construir los casos de pruebas.

Lo que surge aquí es un modelo de ciclo de vida de las pruebas que se parece a la metodología
de desarrollo a la que estamos acostumbrados.
¿Para qué definir una metodología?
La idea es establecer una disciplina o un modo de trabajo de cómo llevar adelante cada actividad
y que cada paso requerido es completo en una secuencia apropiada. Está totalmente aceptado
que definir una metodología de desarrollo sobre la cual podamos tener control y que sea una
buena metodología va a llevar a construir un buen software.

Lo que sí tiene que quedar en claro es que es justificadamente necesario tener una metodología
de pruebas bien integrada con el proceso de desarrollo. ¿Y cómo se integra?

“Más allá del modelo de ciclo de vida que adopte el proyecto para el desarrollo del sistema, las
pruebas deben adaptarse e integrarse al modelo de [CVD] (Ciclo de vida de desarrollo) adoptado
por desarrollo”. (Uninotas, 2017, https://bit.ly/2PmQswL)

“Considerando un proceso de desarrollo en términos generales, se puede decir que éste contiene
las etapas de Análisis, Diseño, Implementación o Desarrollo propiamente dicho y Mantenimiento”
(Uninotas, 2017, https://bit.ly/2PmQswL)

Pueden llevar otros nombres, pero sencillamente son las etapas principales.

Nótese que no se ha establecido una etapa de pruebas, ya que la misma estaría

contenida en la fase de Implementación. Como ya se ha visto: Análisis o
Requerimiento, sería la etapa de requerimientos y es la que determina la viabilidad y
especificación de los requerimientos, Diseño la etapa en la que se especifica el diseño
general y detallado del sistema, Implementación implica la codificación, pruebas,
depuración e instalación del sistema y el Mantenimiento es la parte del ciclo de vida de
desarrollo en la que el sistema se mejora y/o se modifica. (Uninotas, 2017,
https://bit.ly/2PmQswL)
2. Modelo secuencial

“También llamado modelo en cascada. En este CVD las actividades de desarrollo se llevan una
después de la otra, es decir secuencialmente” (Uninotas, 2017, https://bit.ly/2PmQswL).

Se consideran las etapas principales como antes se indicó, pero “la etapa de pruebas se la separa
de la etapa de Implementación, siendo que es la materia de estudios o lo que se desea destacar”
(Uninotas, 2017, https://bit.ly/2PmQswL).

Como se puede apreciar en la gráfica, “el control de la calidad y las pruebas llegan
tarde al proyecto. Y eso genera que se realicen sólo si resta tiempo. Cuando las
pruebas se hacen tan tarde, cada error encontrado tiene un alto costo”. (Uninotas,
2017, https://bit.ly/2PmQswL)

Figura 1: Modelo secuencial

Fuente: elaboración propia.

Si se sostiene, además del ciclo de vida secuencial, la visión temprana de las pruebas de que sólo
paquetes de sistema como código pueden ser probados, la evaluación tardía de la calidad puede
llevar al fracaso completo del proyecto.

Se deben introducir puntos de control de calidad de manera anticipada en el CVD.

3. Modelo V
Es uno de los más usados en interacción con pruebas, ya que organiza las actividades
de pruebas en sus diferentes niveles.

En este modelo hay un ordenamiento de las actividades, tanto de desarrollo como de

pruebas, en una secuencia de tiempo. Las actividades de Desarrollo y de Pruebas
están desarrolladas como dos ramas iguales dibujando una V, donde para cada nivel
de desarrollo existe un nivel de pruebas correspondiente. (Uninotas, 2017,
https://bit.ly/2PmQswL)

Figura 2: Modelo V
Fuente: elaboración propia.
Ahora, las preguntas que se responderán son:

Las pruebas de aceptación, ¿se hacen en el mismo momento que la etapa de

requerimientos?
¿En qué actividades se adelanta?
¿Cuál es la ventaja de este modelo respecto del secuencial?

Si bien en la representación gráfica existe una correspondencia entre cada actividad de desarrollo
con cada nivel de pruebas, el momento de ejecución es el indicado en el eje x, que representa a t.

Partiendo con los requerimientos, ni bien se cumple con esta etapa de desarrollo, se
sigue con la siguiente que es diseño. Respecto de pruebas, se puede ver una
correspondencia con las pruebas de aceptación. Lo que se puede adelantar de este
nivel, no es la ejecución, ya que el producto todavía no fue programado, ni siquiera fue
diseñado. Lo que se puede adelantar es la especificación de los casos de pruebas
para el nivel de aceptación. (Uninotas, 2017, https://bit.ly/2PmQswL)

Se basa en la premisa que establece que si con la definición que se haga de los requerimientos el
diseñador va a poder llevar adelante el diseño de este, los probadores tendrán todo lo necesario
para poder hacer la especificación de los casos.

Lo mismo para todas las etapas siguientes. Ni bien se termina con el diseño funcional,
se cuenta con todo para poder hacer la especificación de los casos de pruebas de
sistemas, y otros.

Cuando se tiene ya el código desarrollado, es el momento en que se puede comenzar

con la ejecución de los casos. (Uninotas, 2017, https://bit.ly/2PmQswL)

Es por ello que la ejecución de las pruebas sigue la recta de tiempo x (t1, t2, t3… t6).
Figura 3: Modelo V en el tiempo
Fuente: elaboración propia.
“Al adelantar la especificación, ni bien se cuenta con los primeros componentes, se puede
comenzar con la ejecución” (Uninotas, 2017, https://bit.ly/2PmQswL). En un modelo secuencial, se
estaría comenzando, en ese punto, con la especificación de los casos de pruebas. Esta es una
primera ventaja explicada.

“La otra es que, cuando se están especificando los casos de pruebas, por ejemplo, con el
documento de requerimientos listo, necesariamente se están revisando esos documentos,
eliminando ambigüedades, supuestos y puntos que pudieran estar faltando” (Uninotas, 2017,
https://bit.ly/2PmQswL). De alguna manera se está forzando la corrección, de haber alguna
deficiencia.

“Es verificación porque cada nivel de desarrollo, verifica respecto de los contenidos del nivel que
le precede. Recordar que verificar significa comprobar si los requisitos y definiciones de niveles
previos han sido implementados correctamente” (Uninotas, 2017, https://bit.ly/2PmQswL).

La flecha gruesa coloreada de azul abarca todas las actividades de calidad que llevan a controlar
la calidad. La flecha gruesa coloreada de verde es la que abarca las actividades de calidad que
llevan a asegurarla.

“Es validación porque se refiere a la corrección de cada nivel de desarrollo. Validar significa
comprobar lo adecuado de los resultados de un nivel de desarrollo” (Uninotas, 2017,
https://bit.ly/2PmQswL).
Figura 4: Verificación y validación en el modelo V

Fuente: elaboración propia.

4. Modelo incremental
Este modelo responde al proceso de establecer requerimientos, diseñar, construir y
probar un sistema en ciclos de desarrollos más cortos. Estas actividades se segmentan
en pasos reducidos y se ejecutan de forma continua, constituyendo una iteración. Tras
cada iteración se debe alcanzar la aprobación del cliente con el objetivo de poder
modificar el rumbo del proyecto si fuera necesario. (Uninotas, 2017,
https://bit.ly/2PmQswL)

Representa un proceso que evoluciona. Debe contar con personal entrenado, ya que la calidad
que obtenga va a depender de la calidad del equipo.

En este modelo la gestión de la configuración es importante porque se debe tener un claro control
de lo que se tiene ya en producción respecto del siguiente paquete para entregar y del resto que
falta. Sin una adecuada gestión de la configuración, probablemente un nuevo paquete de entrega
puede volver atrás funciones o generar fallos sobre funcionalidades que estaban correctas.
Figura 5: Modelo incremental
Fuente: elaboración propia.

Cada iteración contribuye con una funcionalidad a desarrollar, y puede ser probada por
separado. En cada iteración, la verificación (relación con el nivel precedente) y la
validación (grado de corrección del producto dentro del nivel actual) se pueden
efectuar por separado. (Uninotas, 2017, https://bit.ly/2PmQswL)

La automatización de pruebas está más que justificada en este modelo de desarrollo, “ya que, por
cada iteración, es necesario probar las funcionalidades nuevas y a su vez volver a probar el
sistema completo para asegurar que lo que antes funcionaba, sigue funcionando” (Uninotas, 2017,
https://bit.ly/2PmQswL).

5. Proceso de pruebas
Una metodología define los pasos y las actividades, por lo que define los procedimientos para
cada fase de trabajo. “Los procedimientos especifican lo que debería hacerse durante cada fase y
cada subfase de trabajo, y tareas son detalladas suficientemente” (Uninotas, 2017,
https://bit.ly/2PmQswL).

Es importante, como ya se ha demostrado, que exista una metodología. “Dependiendo del

enfoque que se seleccione el proceso de pruebas tendrá lugar en diferentes puntos del proceso
de desarrollo” (Uninotas, 2017, https://bit.ly/2PmQswL).

¿Qué debe contener un proceso de pruebas?

Debe contener:

Identificación de requerimientos de prueba

Planeamiento de la prueba
Ejecución de la prueba
Clasificación de los errores
Mediciones
Seguimiento de los errores
Administración del proyecto de pruebas

Como las pruebas constituyen un proceso en sí mismas, partiendo del proceso básico
(Planificación, Especificación, Desarrollo de la prueba, Ejecución, Evaluación y
Seguimiento). (Uninotas, 2017, https://bit.ly/2PmQswL)

Planificación de las pruebas

“Tomando a las pruebas como proyecto en sí mismo, requiere de diversas actividades a
desarrollar que tienen que ver con la planificación” (Uninotas, 2017, https://bit.ly/2PmQswL). Debe
responder mínimamente a las siguientes preguntas:
- “¿Qué va a ser probado?
- ¿Cómo va a ser probado?
- ¿Qué es necesario para probar: ¿equipos, recursos...?” (Uninotas, 2017, https://bit.ly/2PmQswL).
Esta es una fase que no tiene que descuidarse, ya que de ella depende mucho el éxito del
proyecto de pruebas.

Es una actividad de pensar y establecer, y que requiere de una buena inversión de esfuerzo.

Incluye la definición del alcance y de los riegos, la identificación de los objetivos de las
pruebas y los criterios de salida de pruebas, la determinación del enfoque de las
pruebas y en función del enfoque las técnicas, los niveles de cobertura y criterios de
satisfacción. Implica, como en todo proyecto, establecer el equipo de pruebas
requerido y su programación. Se deben explicitar los detalles del nivel de recursos y si
es necesario o no formación adicional. (Uninotas, 2017, https://bit.ly/2PmQswL)

Lo mismo para cualquier otro tipo de recursos, por ejemplo, equipamiento.

“Todo esto que se defina, debe quedar contenido en un documento denominado plan de pruebas.
El mismo puede ser un documento de 20 o más hojas, o sólo un par de hojas” (Uninotas, 2017,
https://bit.ly/2PmQswL). Puede ser un documento separado o contenido en el documento del plan
de proyecto. Eso dependerá de la madurez de la organización en cuanto a esta fase o de lo que la
organización desee adoptar como procedimiento para llevarlo a cabo.
Análisis y diseño de pruebas
Revisando la arquitectura del sistema y el diseño, incluyendo las interfaces entre los objetos de
prueba, se debe analizar la testeabilidad definida como la capacidad del sistema, componente u
objeto, a ser probado.

Esta etapa es el proceso de definir los casos de pruebas que mejor permitan verificar
que se cumplan los requerimientos de prueba.

Se analizan las especificaciones, el comportamiento y estructura del sistema, para

identificar las condiciones de prueba.

Dentro del diseño de los casos de pruebas, está el diseñar el entorno de prueba, con la
carga de los conjuntos de datos y las conexiones con los sistemas adyacentes. Dentro
de esta etapa se debe establecer la trazabilidad bidireccional entre requerimientos,
casos de pruebas y bases de las pruebas. (Uninotas, 2017, https://bit.ly/2PmQswL)

Si se van a emplear herramientas de prueba, se debe dejar lista la herramienta e incluso probada
la infraestructura si fuera necesario.

Como salida de esta etapa se tiene a los casos de pruebas diseñados en la forma documental que
la organización adopte. Los procedimientos de ejecución pueden hacerse aquí en la etapa
siguiente.
Implementación y ejecución de las pruebas

Se debe realizar el cierre de la implementación de los casos de pruebas, los cuales

tienen que quedar priorizados, y a partir de ahí, se deben generar los procedimientos
de pruebas, sean automatizados o no.

Si fuera necesario, se debe verificar y actualizar la trazabilidad de los casos de

pruebas. (Uninotas, 2017, https://bit.ly/2PmQswL)

Esta fase es la de la ejecución propiamente dicha, de forma manual o automática, siguiendo la

secuencia de prueba establecida.

“A medida que se realiza la ejecución de las pruebas, se deben registrar los resultados obtenidos.
Como resultado de la comparación con los resultados esperados, se determinan las fallas”
(Uninotas, 2017, https://bit.ly/2PmQswL). Se deben registrar los incidentes, con todos los datos
que permitan establecer sus causas, la identificación del defecto y su remoción (entidad afectada,
versión, secuencia de pasos, efecto que se produce, entre otros datos).

“La salida de la implementación y ejecución de las pruebas son los registros de pruebas, que
pueden ser: listas de chequeo de sets de pruebas corridos y registros de defectos” (Uninotas,
2017, https://bit.ly/2PmQswL).

Estas actividades de prueba se repiten según como se mostró en la gráfica del ciclo de vida de las
pruebas, ya sea por ciclos de pruebas o para demostrar la corrección de los defectos. “Dentro de
la ejecución también quedan descriptas las pruebas de regresión (asegurar que los cambios no
han revelado otros defectos o introducido nuevos defectos)” (Uninotas, 2017,
https://bit.ly/2PmQswL) que se explicarán más adelante.
Evaluación del criterio de salida

Es necesario evaluar la ejecución de pruebas con respecto a objetivos definidos al

momento de la planificación (por ejemplo, criterios de salida). Esta fase debe
proporcionar información de manera que permita, en función de los resultados
arrojados, decidir si llevar a cabo pruebas adicionales o no. (Uninotas, 2017,
https://bit.ly/2PmQswL)

Es una etapa importante en comunicación, ya que debe dar a conocer los criterios alcanzados,
permitiendo volver en el proceso para repetir fases hasta alcanzar los resultados esperados.
Cierre de las pruebas
A juicio de la experiencia de Bill Hetzel (1988), esta es una de las fases más importantes, ya que
muchos de los inconvenientes que puede traer la instalación del sistema, viene por no hacerse o
no hacerse formalmente el cierre de las pruebas.

Implica:

Cerrar informes de incidencias, o bien, generar de solicitudes de cambio para

cualquier punto que permaneciera abierto (en función de lo que hayan decidido
hacer con ese incidente los responsables del proyecto).
Comprobar qué entregables planificados han sido entregados y probados.
Documentar la aceptación del sistema, que frecuentemente se da al momento de
las pruebas de aceptación. De no llevarse adelante pruebas en este nivel de
pruebas, es indispensable documentar alguna “prueba” de la aceptación.
De la recopilación de datos de las actividades del proceso de pruebas finalizadas,
se debe consolidar la experiencia, alimentando las buenas prácticas para mejorar
la madurez del proceso de pruebas, y las lecciones aprendidas para futuros
proyectos.
Como en todo proyecto, se deben archivar los productos de soporte de prueba
(entorno e infraestructura de prueba) para un uso posterior o transferencia
(Uninotas, 2017, https://bit.ly/2PmQswL).

Control de las pruebas

“El estado del proceso de pruebas se determina comparando el progreso logrado con respecto al
plan de pruebas. El plan de pruebas puede ser modificado en función de la información adquirida
a partir del control de prueba” (Uninotas, 2017, https://bit.ly/2PmQswL).

Esta actividad es una actividad continua que influye en todas las etapas anteriores.
Figura 6: Control de las pruebas
Fuente: elaboración propia.
“Dentro del control de pruebas, además de lo anterior, se miden y analizan resultados, se diseñan
e inician las medidas correctivas y se preparan y toman decisiones”. (Uninotas, 2017,
https://bit.ly/2PmQswL)

Referencias
Hetzel, B. (1988). An introduction. The complete guide to software testing (2.da ed.).
Massachusetts, USA: QED Information Science.

Uninotas. (2017). Las pruebas que comprueban la corrección del código fuente de una aplicación
son. Recuperado de: https://www.uninotas.net/las-pruebas-que-comprueban-la-correccion-del-
codigo-fuente-de-una-aplicacion-son-2/