Capı́tulo 10

El Catálogo de Requisitos y el Plan de

Pruebas de Software

10.1. Introducción

En muchas oportunidades se obliga a empezar a determinar el plan de pruebas de

software en etapas tempranas de la construcción; para hacer esto nos imaginamos lo que se pue-
de probar producto de una visión que se tiene de los interfaces gráficos de usuario. Pocas veces
empleamos el catálogo de requisitos para elaborar este plan, producto del desconocimiento o
de la falta de experiencia de los ingenieros que llevarán a cabo las pruebas de software.

Es común, en las empresas desarrolladoras de software, llevar a cabo las pruebas

de software después de que se haya culminado la etapa de codificación del producto y proceden
a revisar tanto el código ası́ como el problema de la funcionalidad del mismo. Al hacer esto, no
logran conceptualizar el tipo de error encontrado y como la modificación en la funcionalidad
produce un efecto colateral al producto.

Puesto que el catálogo de requisitos contiene la educción, ilación y especificación,

es aconsejable que las pruebas de software se deduzcan de las tablas de especificación aunque
ya se pueden elaborar grandes bosquejos desde la etapa de educción. El diseñar las pruebas
en etapas tempranas de la construcción nos permite un ahorro sustancial de tiempo y costos
aunque es importante que los diseñadores cuentan con la experiencia del caso.

Fundamentalmente debido a la proliferación de lenguajes de programación, sistemas

operativos y elementos de hardware, las pruebas de software se han tornado más complicadas.
Aunque el avance tecnológico implica una sofisticación del software, las pruebas de software
también han adquirido estas caracterı́sticas porque muchos de sus componentes ya han sido
probados en entornos especı́ficos.

Se debe de observar que la prueba de software no es nada más que un proceso o

un conjunto de procesos que se encuentran definidos para entender que lo que fué codificado
es correcto. Las pruebas de software son una tarea técnica que guarda relación con el aspecto
económico y psicológico; y la prueba de una aplicación compleja acarrearı́a demasiado tiempo
porque requiere demasiados recursos humanos para ser económicamente factible.

El probador de software debe tener actitudes adecuadas que le permita tener una

200
10.1. INTRODUCCIÓN 201

visión correcta de lo que tiene que probar. En algunos casos, la actitud del evaluador puede
ser más importante que el proceso en sı́, ya que tiene que vislumbrar situaciones que permitan
ahorrar dinero y proporcionar seguridad en la funcionalidad del producto. Esta experiencia le
permita conocer lo que “tiene que probar”.

Una definición apropiada se puede obtener de [55] quienes indican que: “La prue-
ba de software es el proceso de ejecutar un programa con la intención de encontrar errores”.
Si el objetivo es demostrar que la aplicación no contiene errores entonces se debe seleccionar
datos de pruebas que tengan una alta probabilidad de causar que falle la aplicación para lograr
correcciones consistentes y guiados por los siguientes principios:

1. Todo caso de prueba debe proporcionar un resultado.

2. Toda aplicación debe ser probada por terceras personas.

3. Toda empresa desarrolladora de software no debe probar sus propias aplicaciones.

4. Todo proceso de prueba debe incluir una análisis de los resultados.

5. Todo caso de prueba debe incluir condiciones para entradas válidas o inválidas.

6. Probar un aplicativo implica observar que no haga lo que debe de hacer ası́ como observar
que el código haga lo que no debe de hacer.

7. Todo caso de prueba desechable debe ser evitado.

8. Toda prueba de software no debe ser planificada con supuestos tácitos.

9. Si en una área se han encontrado errores entonces es altamente probable seguir encon-
trando más errores.

10. Toda prueba de software es una tarea creativa.

Los tres métodos más empleados son las inspecciones de código, los recorridos o ca-
minatas y las pruebas de usabilidad. Existen textos especializados en estos temas que no son
el objetivo del presente texto, donde hacen una larga y profunda explicación sobre pruebas de
software, sus metodologı́as y la forma de aplicación. El objetivo que persigue el presente texto
es el de saber como se diseña y aplica.

Existe una gran variedad de pruebas de software y su clasificación se muestra a

continuación.

1. P001: Prueba de caja negra. Técnica en la que se verifica la funcionalidad del producto
sin tomar en cuenta la estructura del código y sus detalles de implementación.

2. P002: Prueba de caja blanca. Técnica que se centra en la estructura del código. Los testers
introducen valores iniciales para probar los flujos de ejecución.

3. P003: Prueba de complejidad ciclomática. Técnica que entrega indicadores que demues-
tran la complejidad lógica de un programa.

4. P004: Prueba unitaria. Técnica que prueba unidades de código o sea funciones, procedi-
mientos o clases de manera separada y que permite comprobar la eficiencia de los mismos
en forma independiente.
202CAPÍTULO 10. EL CATÁLOGO DE REQUISITOS Y EL PLAN DE PRUEBAS DE SOFTWARE

5. P005: Prueba de aceptación. Técnica que se emplea antes de liberar el producto de soft-
ware con la finalidad de determinar si resuelven las necesidades de los usuarios.

6. P006: Prueba de integración. Técnica empleada despues de haber llevado a cabo las
pruebas unitarias con la finalidad de conocer de que juntas funcionan eficientemente.

7. P007: Prueba de regresión. Técnica que evalúa el correcto funcionamiento del software
frente a evoluciones o cambios funcionales con la finalidad de descubrir errores o carencias
de funcionalidad.

8. P008: Prueba de carga. Técnica que permite observar el comportamiento de una aplicación
bajo una petición considerable de datos.

9. P009: Prueba de estrés. Técnica que permite romper la aplicación con la finalidad de
conocer la solidez de la misma.

10. P010: Prueba de escalabilidad. Técnica que permite conocer la fortaleza de los requisitos
no funcionales para determinar el grado de escalabilidad de una aplicación.

11. P011: Prueba de portabilidad. Técnica que permite conocer el grado de dificultad de una
apliación al ser transferido de un sistema operativo a otro.

12. P012: Prueba de seguridad. Técnica orientada a los requisitos no funcionales que permite
constatar su desempeño en función de los requisitos funcionales.

13. P013: Prueba de interoperabilidad. Técnica que permite conocer las deficiencias del tras-
lado de información entre dos o más aplicaciones.

14. P014: Prueba de componente. Técnica que permite validar si los componentes integrados
a la aplicación funcionan correctamente.

15. P015: Prueba de compatibilidad. Técnica que permite conocer las defiencias de las apli-
caciones cuando estas se mueven en diferentes entornos.

16. P016: Prueba de usabilidad. Técnica que permite llevar a cabo las pruebas de software
directamente con los usuarios finales del sistema.

17. P017: Prueba de rendimiento. Técnica que permite determinar la rapidez de respuesta de
un aplicativo en condiciones particulares.

18. P018: Prueba de configuración. Técnica que permite validar y verificar que los sistemas
funcionan correctamente en las estaciones de trabajo seleccionadas.

19. P019: Prueba de conversión. Técnica que permite validar la conversión de los datos en
sistemas antiguos y su real valor en los sistemas nuevos.

20. P020: Prueba de instalación. Técnica que permite validar que los aplicativos se instalen
correctamente en los dispositivos seleccionados.

Existen una serie de metodologı́as que se pueden emplear como por ejemplo para
la prueba de caja negra se puede emplear: Clases o particiones de equivalencia, análisis del
valor lı́mite, grafos de causa y efecto y error de adivinación. Asimismo se pueden emplear las
siguientes metodologı́as para las pruebas de caja blanca: Cobertura de declaraciones, cober-
tura de desiciones, cobertura de condiciones, cobertura de desición-condición y coberturas de
condiciones múltiples.
10.2. DISEÑO DEL PLAN DE PRUEBAS 203

Figura 10.1: Plantilla de pruebas de software para requisitos

10.2. Diseño del plan de pruebas

Existen dos tipos de diseño del plan de pruebas, el primero se encuentra orientado al
catálogo de requisitos y el segundo a pruebas especı́ficas.

1. Pruebas iniciales.

2. Pruebas finales.

Las pruebas iniciales permiten tener una idea general de las pruebas que se pueden
llevar a cabo para que finalmente se defina las pruebas definitivas. Los desarrolladores toman
esto como una pérdida de tiempo; lo que se puede indicar es que cuando no se tiene experiencia
se puede comenzar por lograr un listado completo de las pruebas a realizar a partir del catálogo
para finalmente determinar donde se llevarán a cabo las pruebas finales.

Para el caso del catálogo de requisitos, se puede emplear un diseño básico toman-
do como base la especificación de requisitos. En vista de que no existe un código definido, por
la lectura del mismo se puede establecer el tipo de prueba de manera genérica para que cuando
se genere el código se haga una revisión exhaustiva. Estas pruebas son consideradas iniciales
porque no tienen el análisis profundo adecuado. La figura 10.1 muestra un primer diseño.
En “Organización” se coloca el código de la organización para quien se está prepa-
rando la aplicación (ORG-DDDD). En el campo “Autor” se escribe el código de la persona que
llevará a cabo la prueba de software (AUT-DDDD). Asimismo se agrega la versión (VDDD).
En “Etapa” se esribe con cual de las fases del catálogo de requisitos se trabajará (Educción,
ilación, especificación) para finalmente escribir la fecha cuando se planifican las pruebas de
software.

En el “Código del requisito” se escribe el código de la tabla desde donde se encuentra

escrito el requisito, por ejemplo si se decide trabajar con la tabla de especificación se debe de
ecribir ESP-DDDD, si es ilación ILA-DDD o si es educción EDU-DDD; en “Descripción de la
prueba” se detalla la prueba que se llevará a cabo y en el “Tipo” se especifica el tipo de prueba
de software a llevar a cabo.
204CAPÍTULO 10. EL CATÁLOGO DE REQUISITOS Y EL PLAN DE PRUEBAS DE SOFTWARE

10.3. Ejemplo de un plan de pruebas básico

A continuación se presenta el plan de pruebas de software en la etapa de especificación
del ejemplo que se presenta a lo largo del texto. Aunque no se pretende hacer un tratado sobre
pruebas de software se presentan a continuación un listado de ellas según la especificación de
requisitos (cuadro 10.1).

Requisitos Descripción Tipo

Conexión con el servidor. P008
ESP-0001
Tiempo de carga de la interfaz. P016
Conexión con el servidor. P008
ESP-0002
Tiempo de carga de la interfaz. P016
Campo usuario: El usuario deberá ingresar solo letras. P001
ESP-0003 Verificación del correo institucional con dominio @aqpsurvey.com. P001
Password: El usuario deberá ingresar letras alfanuméricas. P001
Conexión con el servidor. P008
ESP-0004
Tiempo de carga de la interfaz. P016
Conexión con el servidor. P008
ESP-0005
Tiempo de carga de la interfaz. P017
Conexión con el servidor. P008
ESP-0006
Tiempo de carga de la interfaz. P016
Campo usuario: El usuario deberá ingresar solo letras. P001
Campo Razón Social: Se debe ingresar sólo letras. P001
Campo Respresentante Cliente: El usuario deberá ingresar sólo le- P001
tras.
ESP-0007
Campo Correo Cliente: El usuario deberá ingresar sólo letras. P001
Campo Teléfono: El usuario deberá ingresar sólo números. P001
Campo Dirección: El usuario deberá ingresar sólo caracteres alfa- P001
numéricos.
Campo RUC/DNI: El usuario deberá ingresar sólo números. P001
Confirmación de datos ingresados correctamente en la Base de Da- P009
tos.
Conexión con la base de datos P008
ESP-0008 Campo Nombre Cliente: El usuario deberá ingresar sólo letras. P001
Campo RUC/DNI: El usuario deberá ingresar sólo números. P001
Conexión con el servidor. P008
ESP-0009
Tiempo de carga de la interfaz. P016
Conexión con el servidor. P008
ESP-0010
Tiempo de carga de la interfaz. P016
Campo usuario: El usuario deberá ingresar solo letras. P001
Campo Razón Social: Se deberá ingresar sólo letras. P001
Campo Respresentante Cliente: El usuario deberá ingresar sólo le- P001
tras.
ESP-0011
Campo Correo Cliente: El usuario deberá ingresar sólo letras. P001
Campo Teléfono: El usuario deberá ingresar sólo números. P001
Campo Dirección: El usuario deberá ingresar sólo caracteres alfa- P001
numéricos.
Campo RUC/DNI: El usuario deberá ingresar sólo números. P001
Confirmación de datos ingresados correctamente en la Base de Da- P009
tos.
10.3. EJEMPLO DE UN PLAN DE PRUEBAS BÁSICO 205

ESP-0012 Tiempo de carga de la interfaz. P016

ESP-0013 Conexión con la base de datos. P008
Conexión con el servidor. P008
ESP-0014
Tiempo de carga de la interfaz. P016
Conexión con el servidor. P008
ESP-0015
Tiempo de carga de la interfaz. P017
ESP-0016 Tiempo de carga de la interfaz. P016
Campo Nombre Usuario: El administrador deberá ingresar sólo le- P001
tras.
Campo Correo Usuario: El administrador deberá ingresar sólo ca- P001
ESP-0017
racteres alfanuméricos.
Campo Dirección Usuario: El administrador deberá ingresar sólo P001
caracteres alfanuméricos.
Campo DNI: El administrador deberá ingresar sólo números de 8 P001
dı́gitos.
Campo Password: El administrador deberá ingresar caracteres al- P001
fanuméricos.
Confirmación de datos ingresados correctamente en la Base de Da- P009
tos.
ESP-0022 Tiempo de carga de la interfaz. P016
ESP-0023 Conexión con la base de datos. P008
Conexión con el servidor. P008
ESP-0024
Tiempo de carga de la interfaz. P016
El archivo sea válido al tipo de archivo. P001
ESP-0025 El tipo de archivo debe conincidir con la extensión del archivo se- P001
leccionado.
Confirmación de archivo ingresado en la Base de Datos. P009
Conexión con el servidor. P008
ESP-0026
Tiempo de carga de la interfaz. P016
El archivo sea válido al tipo de archivo. P001
ESP-0027 El tipo de archivo debe coincidir con la extensión del archivo selec- P001
cionado.
Confirmación de archivo modificado en la Base de Datos. P009
ESP-0028 Se debe mostrar el estado del archivo en tiempo real. P005
ESP-0029 Tiempo de carga de la interfaz. P016
ESP-0030 Conexión con la base de datos. P008
Conexión con el servidor. P008
ESP-0031
Tiempo de carga de la interfaz. P016
El nombre para la búsqueda del archivo debe ser alfanumérico. P001
ESP-0032 El tipo de archivo debe coincidir con el filtro seleccionado. P001
Tiempo de carga de visualización de datos. P017
Conexión con el servidor. P008
ESP-0033
Tiempo de carga de la interfaz. P016
Conexión con la base de datos. P008
ESP-0034
Tiempo de carga de visualización de datos. P017
Conexión con el servidor. P008
ESP-0035
Tiempo de carga de la interfaz. P016
Campo nombre de Proyecto: El usuario deberá ingresar caracteres P001
ESP-0036 alfanuméricos.
206CAPÍTULO 10. EL CATÁLOGO DE REQUISITOS Y EL PLAN DE PRUEBAS DE SOFTWARE

Campo Tipo de Proyecto: El usuario deberá seleccionar un tipo de P001

proyecto válido.
Confirmación de proyecto guardado en la Base de Datos. P009
Conexión con la base de datos. P008
ESP-0037
Tiempo de carga de la interfaz. P016
Campo nombre de Proyecto: El usuario deberá ingresar caracteres P001
ESP-0038 alfanuméricos.
Campo Tipo de Proyecto: El usuario deberá seleccionar un tipo de P001
proyecto válido.
Confirmación de actualización en la Base de Datos. P009
ESP-0039 Tiempo de carga de la interfaz. P016
ESP-0040 Conexión con la base de datos. P008
Conexión con la base de datos. P008
ESP-0041
Tiempo de carga de la interfaz. P016
El nombre para la búsqueda del proyecto debe ser alfanumérico. P001
El nombre del representante asociado al proyecto para la búsqueda P001
ESP-0042
debe ser alfanumérico.
El tipo de proyecto debe coincidir con el filtro seleccionado. P001
Tiempo de carga de visualización de datos resultados. P017
Conexión con la base de datos. P008
ESP-0043
Tiempo de carga de la interfaz. P016
Conexión con la base de datos. P008
ESP-0044
Tiempo de carga de visualización de datos. P016
Conexión con la base de datos. P008
ESP-0045
Tiempo de carga de la interfaz. P016
ESP-0046 Verificación de cierre de sesión. P012
Cuadro 10.1: Pruebas de software para requisitos especi-
ficados