Unidad 2 / Escenario 4

Lectura fundamental

¿Cómo hacer las pruebas?

Contenido
1 Diseñar los casos de prueba

2 Desarrollar las pruebas

3 Chequear los resultados

4 Preparar el siguiente ciclo de pruebas

5 Notas finales

Palabras clave: calidad de software, PDCA, procesos, pruebas.

1. Diseñar los casos de prueba

Un caso de prueba es un conjunto de acciones, por las cuales se valida que un producto de
software cumple con su objetivo a partir de una entrada, unas precondiciones y un resultado
esperado. Una vez aprobado el plan de pruebas que se llevará a cabo en cada fase del proyecto, se
tiene definido el alcance y se debe proceder a definir los casos de prueba específicos a cada fase,
proceso, módulo, componente o función del sistema. El proyecto, por supuesto, se desenvuelve
de la misma manera. Partiendo de lo general se va logrando el detalle necesario para garantizar
que las piezas de la solución encajan para brindar el resultado esperado por el cliente.
La táctica de guerra “dividir y conquistar” se aplica al proceso de desarrollo de software al
descomponer el sistema en módulos o funciones cada vez más reducidos para hacerlos más
simples y ocuparse de uno en uno, con las condiciones adecuadas. En cada caso, dado el objetivo
del proyecto, se debe validar que todos y cada uno de los requerimientos funcionales del cliente
se cumplan en el marco de la prueba específica que se vaya a realizar.
Entonces, la base para crear los casos de prueba son los requerimientos y se sigue trabajando de la
mano con los desarrolladores que siguen la misma estrategia para el análisis, diseño y codificación.
Vale la pena destacar que los requerimientos no funcionales son transversales al aplicativo; por lo
tanto, se deben verificar en un momento dado así no correspondan a un programa en particular.
Luego de descomponer el sistema en jerarquías, en funciones elementales y con la lista de
requerimientos, se definen los casos de prueba a validar para cada función o, si así lo prefieren,
determinan para cada caso de prueba descubierto, a partir de un requerimiento, las funciones
elementales del sistema que necesitan de ese caso de prueba para su validación.
El efecto debe llevar a una matriz de casos de prueba contra funciones elementales, en cuyas
celdas se encuentre la identificación asignada al caso de prueba. Al final, un requerimiento está
representado por una o varias funciones elementales y cada función tiene uno o varios casos de
prueba que validan su correcta operación. Esto ayuda a la trazabilidad de las pruebas (de nuevo
este mecanismo es similar para los codificadores y para los participantes del proyecto con las
actividades que desarrollan, en procura de llevarlo a cabo con éxito).

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 2
 Cómo mejorar...
Como todos los procesos de ingeniería de software, hay técnicas y buenas prácticas que se han
recogido a lo largo de las experiencias, por demostrar ser efectivas. Las pruebas no escapan
a este principio, llevar listas de chequeo, revisar documentación de proyectos anteriores,
lluvias de ideas, opinión de expertos, formatos prediseñados y todo lo que apoye el proceso
es bienvenido.

Como los casos de prueba parten de los requerimientos, estos se deben validar también. Hay una
serie de criterios que definen correctamente una especificación de requisitos de software (ERS)
para determinar que sean completos, consistentes, inequívocos, correctos, trazables, priorizables,
modificables y verificables. Al diseñarlos hay que tener en mente que un caso de prueba puede
servir para varias funciones, para definir las pruebas de integración y para las pruebas de regresión
cuando se generan cambios. Esto ahorra trabajo y permite la automatización; de paso, el control
como lista de chequeo sobre lo que se debe garantizar en cada prueba o cambio del sistema.
En algunos casos la descomposición realizada va más allá de la función misma definida en el
sistema y se deben probar rutinas o fragmentos de código con labores específicas. En este caso,
se requiere conocer sus precondiciones, argumentos de entrada y salidas esperadas, si se trata de
pruebas de caja negra, y de flujo de trabajo, si se trata de una prueba de caja blanca. La definición
de los casos de prueba requiere información adicional que no se encuentra en los requerimientos,
pero sí en los documentos de arquitectura, diseño y especificación, si se tienen. Se reitera
entonces la necesidad de trabajar colaborativamente con el equipo de trabajo y de acuerdo a la
plataforma de ejecución. En ocasiones, en las metodologías ágiles, la documentación es pobre y
las decisiones se toman en reuniones de trabajo, de tal suerte que solo allí se tiene la información
relevante a tales decisiones y vitales para las pruebas y entrega al usuario.
Igualmente, en el caso de proyectos llevados por prototipos, estos no siempre se desarrollan en
el ambiente final de ejecución ni con las herramientas finales del desarrollo entregado, solo son
para agilizar pruebas de concepto. Entonces, los casos de prueba se deben diseñar centrados en la
validación del objetivo planteado ya sea para probar respuestas de funciones críticas o determinar
si las interfaces son “agradables” al usuario. Otro caso frecuente es que el desarrollo del núcleo
funcional del sistema, se construye de modo independiente (al final por supuesto se integra) de la
interfaz de usuario.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 3
Esto se ve en sistemas cliente servidor, en programación orientada a objetos, en sistemas
multiplataforma en los cuales las pantallas se adaptan al tipo de dispositivo (móvil, tableta,
computador) y el sistema operacional que ejecutan y en desarrollos para la web.
Los casos de prueba para las pantallas se deben diseñar contemplado que, para validar estas
interfaces, se debe requerir del usuario final y posiblemente de personal de publicidad y
mercadeo, así como de muchos cambios considerados de “maquillaje”, pero que representan
trabajo en codificación, diseñadores y nuevas pruebas en cada dispositivo hasta lograr que sea y
aceptada y agradable al usuario con colores, tipo de letra, orden y posición de los elementos, su
tipo adecuado, etc.
En el diseño del caso de prueba se debe validar cada elemento de la pantalla, determinar en qué
casos debe ser de entrada o de salida y que invoque la función adecuada, el rastro de los cambios
presentados y si las sugerencias son consistentes entre los diferentes usuarios. El conocimiento
de las funciones generales de elementos gráficos es indispensable pues cambiar tamaño de
pantallas, girado automático y otras funciones gráficas pueden afectar el flujo de datos del
programa. Hay que prestar atención especial al cierre y apertura de pantallas independientes,
mensajes emergentes y validaciones de la navegación correcta entre ellas. De nuevo, listas de
chequeo y matrices de validación de componentes resultan muy útiles, si se identifican de modo
único y adecuado para su prueba y posterior corrección.
De cualquier modo, las pruebas de interfaz deben validar tanto la correcta interacción y
navegación a través de ella como la aprobación de su apariencia por parte del cliente. La validación
de datos de entrada, mensajes de error, alertas ante cierres o cancelaciones, datos vacíos, etc.
son importantes en funciones posteriores que tienen precondiciones establecidas. Es importante
recordar que el sistema no solo interactúa a través de pantallas con el usuario. Se pueden tener
interfaces con otros sistemas o medios electrónicos que deben validarse y en los cuales pueden
tenerse protocolos de entrada o de salida a respetar y que son fuentes potenciales de falla.
Siguiendo el modelo V de pruebas diseñado por la Administración Federal Alemana para el
control del proceso de desarrollo de software (Figura 1), luego de descender hasta el detalle,
debemos ahora validar la integración del producto de software. Con ello, diseñar los casos de
prueba correspondientes.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 4
Figura 1. Objetivos Naciones Unidas
Fuente: elaboración propia

Mucho del trabajo ya está hecho en los casos de pruebas unitarias y funcionales, pero surgen
elementos adicionales a validar cuando ya se han pasado las pruebas de integración y se tienen
módulos o el sistema completo. En cada función adicionada, o sistema entregado, se deben
probar de nuevo los elementos anteriores internamente y solo después presentarlos al cliente
pues las fallas pueden llevar a la pérdida de confianza en el producto. Sin embargo, no involucrar ]
al cliente en pruebas tempranas puede llevar a sorpresas y cambios costosos.
A medida que se acercan las pruebas de aceptación, de acuerdo con los requerimientos, se
deben diseñar casos de prueba para validar el comportamiento del sistema en cuanto a carga,
rendimiento, seguridad, sobrecarga, recuperación ante fallas, etc. El objetivo es comprobar que el
ambiente de ejecución es el adecuado para las condiciones normales en que operará y establecer
picos de carga para validar su comportamiento y límite de crecimiento.
Por lo general las aplicaciones de estar bien diseñadas operan a medida que crece la compañía
y el volumen de información y demanda de la misma sobrepasan las expectativas bajo las cuales
fueron creadas, así que hay que revisar que el rendimiento del aplicativo esté acorde con el
crecimiento de usuarios y datos y determinar su eficiencia.
La aplicación a desarrollar puede funcionar en solitario, pero el caso más común es que opere
con otros sistemas o que reemplace alguno. Por lo tanto, es necesario probar asuntos adicionales
como: compatibilidad, conversión y migración de datos, realización de copias y recuperación del
sistema a partir de las mismas, pruebas de instalación o reinstalación ante fallas o corrección de
funciones o adición de nuevos programas y acceso a la documentación actualizada.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 5
Esto, que a menudo forma parte del mantenimiento del aplicativo, es usado en sistemas que
deben implantarse por fases o de modo incremental.
Por lo tanto, es buena práctica agrupar pruebas de fracciones del sistema que permitan validar
que los cambios no afectaron otras funcionalidades del producto de software, pero que validen por
completo los módulos afectados por el cambio. Esto ayuda a automatización y regresión de las
pruebas asegurando un mejor sistema.
Los casos de prueba diseñados deben presentarse en un documento, exponerse para aprobación
del grupo de trabajo y establecer un cronograma, de acuerdo con el avance del proyecto ya
que se requiere de la coordinación y trabajo dedicado a las pruebas por personal que está en
otras actividades en el proyecto. Esto incide en el cronograma establecido de acuerdo con la
dedicación necesitada para correr las pruebas. Para aprobar los casos de prueba debe tenerse
para cada uno de ellos la documentación que indique los datos de prueba a usar, el objetivo de la
prueba, las precondiciones, el resultado a obtener y la trazabilidad que permita identificar cada
función a probar, cada módulo afectado y el requerimiento, o caso de negocio del cliente, que
será validado, las condiciones de aceptación y su nivel de criticidad.

2. Desarrollar las pruebas

El conjunto de casos de prueba permite validar las funciones del sistema. En cada prueba realizada
se pueden detectar fallos; estos son los primeros a probar en la siguiente ocasión. Además, una
prueba de regresión es requerida para validar que las nuevas funciones o cambios se realizaron sin
afectar lo que ya se tenía aprobado sin errores. Para ello se puede llevar una matriz de repetición
que indique cuáles casos de prueba deben llevarse a cabo por cada función alterada o agregada.
Por supuesto, la anticipación total de los datos de prueba no es posible. A medida que se lleven
a cabo las pruebas será necesario revisarlos, así como la incidencia en la matriz de repetición,
de acuerdo al conocimiento y desarrollo del aplicativo. En cada ciclo de prueba llevada a cabo,
según el avance del proyecto, se debe actualizar el plan, los casos de prueba, los datos a usar, las
matrices de repetición y las pruebas de integración y de aceptación para reflejar el estatus del
sistema y su calidad.
Una vez que se ha probado con la regresión que los fallos fueron superados, se ejecutan las
nuevas pruebas que deben cubrir los cambios recientes del producto de software y que fueron
planteados en el ciclo de pruebas anterior. La ejecución de la prueba debe ser documentada
para mantener el registro actualizado de los defectos y su evolución. Tal reporte sirve no solo de
control sino de soporte para probadores, usuarios y desarrolladores sobre los hallazgos realizados
para reproducirlos y encontrar sus causas. Además, permite datos históricos para usar a futuro en
las estimaciones de tiempo y esfuerzo.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 6
Dependiendo de las herramientas para el desarrollo de las pruebas, es válido considerar una base
de datos de seguimiento a fallas o una herramienta de administración de defectos, que por lo
general se orienta al flujo de trabajo en orden a reportar fallas, remitirlas para corrección y luego
proceder a una nueva verificación.

3. Chequear los resultados

Una vez realizada la prueba, es necesario evaluar los resultados documentados durante la misma,
de modo integral con todas las pruebas efectuadas durante el ciclo. El propósito es establecer
el estado de avance de las pruebas y la calidad del producto desarrollado hasta el momento y
obtener un reporte provisional de pruebas. Entonces, las métricas son un aspecto fundamental
para tomar decisiones y mejorar el proceso. Si bien cada proyecto puede definir métricas
específicas, en general se consideran algunas mínimas necesarias para controlar el proceso de
pruebas y que veremos a continuación. Se debe determinar el estado de ejecución de los casos de
prueba; es decir, conocer cuántos casos de prueba se han realizado o su porcentaje con respecto
al plan establecido, la cantidad o porcentaje faltante y la cantidad de fallas encontradas. En lo
posible, se deben realizar gráficas en el tiempo (histogramas) que permitan comparar el plan con
lo ejecutado y ver la evolución de las métricas a medida que el proyecto se desarrolla.
Por supuesto, la cantidad de fallos clasificados por grado de severidad, o estado de severidad,
nos dan una idea de la calidad del sistema y de aquellos que deben atacarse más prontamente.
Un análisis de fallas no reparadas o brecha de deficiencias, calculada como la cantidad de fallas
encontradas menos las corregidas, es un indicador que visto en el tiempo nos ayuda a determinar
la velocidad para reparar errores y se puede determinar en el histograma si es adecuada o si está
creciendo la cantidad de fallas sin resolver.
El rastreo de pruebas fallidas, o cantidad de fallos encontrados, se puede mostrar por unidades
de tiempo o acumuladas en el proyecto para ver su tendencia hacia su reducción y el momento
en el cual se reducen, ya que esto nos permite estimar la necesidad de pruebas adicionales y
establecer si la calidad del sistema se ha estabilizado. Otros indicadores, como la cantidad de fallas
encontradas de acuerdo a la cantidad de líneas de código o cantidad de programas revisados,
pueden darnos una idea para estimar los fallos a futuro, en la medida en que el producto de
software crezca en tales medidas, a lo largo del proyecto.
Evaluado el estado actual del proceso de pruebas, se deben publicar los resultados preliminares de
la fase en desarrollo desde el área de pruebas, a efectos de evaluar el estado actual, compararlo
con el plan establecido y tomar las acciones de acuerdo a la evaluación realizada.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 7
Por obvias razones, de acuerdo con el avance del proyecto, se deben revisar los cronogramas y las
responsabilidades asignadas, con base en los fallos encontrados y la necesidad de su corrección y
nuevas pruebas. Se deben validar las razones de atrasos, las habilidades del personal, el esfuerzo
requerido contra el estimado, la cantidad de personal y las herramientas a disposición, en aras de
que las pruebas y el control de calidad no afecten negativamente el progreso del proyecto.
Otro punto muy importante en la evaluación de resultados de las pruebas es el cambio de
requerimientos. Estos cambios detectados en las pruebas deben ser transmitidos al gerente del
proyecto para su trazabilidad y aprobación, de acuerdo a los costos y tiempo necesarios para
atenderlos. En cualquier caso, los cambios de requerimientos aprobados deben ser tenidos en
cuenta en la evaluación, pues se requiere agregar tales funcionalidades o cambios al plan de
pruebas, diseñar los casos de prueba, establecer el guion correspondiente, etc. En otras palabras,
todo el proceso de calidad y pruebas debe desarrollarse de nuevo para el cambio aprobado. Como
se observa en la Figura 2, la interacción con los demás procesos desarrollados concurrentemente
para lograr el éxito del proyecto afecta de un modo u otro el proceso definido por el equipo
de pruebas.

Figura 2. Interacción del equipo de pruebas

Fuente: Modificado de Marigranula (s.f.)

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 8
4. Preparar el siguiente ciclo de pruebas

Todo lo anterior corresponde a las etapas de hacer y chequear en la espiral de mejora

continua PDCA de Deming. Lo que nos queda es la fase actuar que consiste en prepararse
para el siguiente ciclo de pruebas refinar el proceso de las pruebas, reevaluar el equipo, los
procedimientos y el ambiente de pruebas. Por último, complementar el reporte preliminar de
pruebas para su publicación e informe a todas las áreas del proyecto.
Refinar el proceso de las pruebas consiste en analizar el impacto de los cambios en el producto
de software en desarrollo para determinar los cambios en el plan de pruebas para cubrirlos.
Por supuesto, esto conlleva a actualizar todas las matrices de información con los nuevos
requerimientos, determinar los casos de prueba que se pueden automatizar, reutilizar, los módulos
afectados, las regresiones necesarias, etc.
Esta revisión cubre los casos de prueba, las unitarias, las modulares, las del sistema y las de entrega
y aceptación. El proceso evolutivo conllevará cada vez menos de unas y más de otras. Pero no es
la única fuente de información que debemos tener en cuenta, el avance de los fallos encontrados
y las nuevas funciones terminadas por el equipo de desarrollo del proyecto afectan la planeación
del nuevo ciclo de pruebas a llevar a cabo.
También, el avance está determinado por automatización y herramientas de administración; si no
se ha contemplado desde un principio es necesario validar el mecanismo bajo el cual se agilizará
o mejorará el proceso. De no tener algún software de pruebas automatizadas a la mano, se
pueden usar bases de datos o Excel como medio alterno. Lo importante es llevar la información
actualizada y unificada. Reevaluar el equipo consiste en determinar si la calidad y la productividad
de las pruebas es la adecuada a la velocidad del proyecto que se lleva a cabo.
Se revisa si las habilidades de los probadores son las establecidas, si el cronograma y esfuerzo
estimado se están cumpliendo y si se requiere el aumento o disminución de personal asignado a
pruebas. Reevaluar los procedimientos para mejora continua requiere establecer si los formatos
son los adecuados, si falta información o si la comunicación es pobre, si los datos de prueba no
son adecuados, si el control de cambios o el manejador de versiones están cumpliendo con su
objetivo y si el procedimiento de cambio de fallos es efectivo, etc.
Reevaluar el ambiente de prueba permite determinar si las herramientas, la tecnología y la parte
física son adecuadas para el avance obtenido en el proceso de pruebas. Cambios en plataformas,
software, redes, bases de datos, hardware y otros componentes deben proponerse a la luz de su
rápida implementación; de lo contrario, el cambio puede tener un efecto adverso. Finalmente,
el reporte preliminar de pruebas debe complementarse documentando el análisis anterior y
reportando las decisiones o recomendaciones tomadas que puedan afectar o no otras áreas
involucradas en el proyecto.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 9
5. Notas finales

Las pruebas se desarrollan a lo largo del ciclo de vida del proyecto, de acuerdo al avance que
se tenga en la construcción del producto de software. Todo proceso, actividad o código es
susceptible de revisión para la detección temprana de errores. Mientras más pronto se detecten,
menor es el costo, esfuerzo y tiempo para su reparación. El arreglo o cambio de planes requiere
de tiempo y reacomodación del personal de pruebas, como del externo a tal área y afecta el
desenvolvimiento del proyecto. Si bien es un proceso para la mejora y debe llevarse a cabo, es vital
establecer desde un comienzo un plan robusto acorde con la dimensión del proyecto a desarrollar.
Por ello, es necesario tener personal con conocimiento y experiencia en pruebas. El modelo de
Demming para la mejora continua involucra actividades específicas en cada una de sus cuatro
etapas, que son necesarias y no deben obviarse para llevar a cabo un proceso controlado.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 10
Referencias
González, G. C., Domingo, N. R., & Pérez, M. Á. S. (2013). Técnicas de mejora de la calidad.
Madrid, ES: UNED - Universidad Nacional de Educación a Distancia.
Gutiérrez, H. (2013). Control estadístico de la calidad y Seis Sigma (3a. ed.). México, D.F., MX:
McGraw-Hill Interamericana.
Gutiérrez, H. (2014). Calidad y productividad. (4a. ed.). México, D.F., MX: McGraw-Hill
Interamericana.
Hernández, P. F. Á., & Ricardo, Z. P. M. (2006). Glosario de Términos Informáticos. Córdoba, AR:
El Cid Editor.
Lewis, W. (2008). Software Testing and Continuous Quality Improvement (3a. ed.). Florida,
EE.UU.: Auerbach Publications.
Marcelino, A. M., & Ramírez, H. D. (2014). Administración de la calidad: nuevas perspectivas.
México, D.F., MX: Grupo Editorial Patria.
Pressman, R. (2010) Ingeniería del software un enfoque práctico (7a. ed.). México, D.F., MX:
McGraw-Hill Interamericana.
Summers., D. (2006). Administración de la calidad (1a. ed.). México, D.F., MX:
Pearson Educación.
Toro, F. (2013). Administración de proyectos de informática (1a. ed.). Bogotá, CO: Ecoe ediciones.

Referencias de gráficas
1tjf. (s.f.). Detailed Software Development Life Cycle V-Model Including Phases, levels, Documen-
tation, Review [Ilustración]. Recuperado de https://www.123rf.com/search.php?word=v+mo-
del&imgtype=0&t_word=&t_lang=en&orderby=0&t_word=&t_lang=en&oriSearch=cwqc&s-
ti=lovmtztqt8wbpc8z3k|&mediapopup=14805492
Marigranula. (s.f.). IT Service Management [Fotografía]. Recuperado de https://www.123rf.com/
stock-photo/request_change.html?imgtype=0&oriSearch=testing+out&sti=m927srec6gmzx-
vdtbk|&mediapopup=64901530
 INFORMACIÓN TÉCNICA

Módulo: Pruebas y Calidad de Software

Unidad 2: Definiendo y ejecutando el plan
de pruebas de software.
Escenario 4: Ejecutando las pruebas

Autor: Nelson Pérez

Asesor Pedagógico: Manuel Fernando Guevara

Diseñador Gráfico: Alejandro Torres
Asistente: Ginna Quiroga

Este material pertenece al Politécnico Grancolombiano.

Prohibida su reproducción total o parcial.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 12