Unidad 1 / Escenario 2

Lectura fundamental

Ciclo de vida de las pruebas

Contenido
1 Ciclo de vida de las pruebas

2 Verificación de requerimientos

3 Verificación del diseño

4 Verificación de la programación

5 Principios de calidad del ciclo PDCA

6 Las pruebas en metodologías ágiles

7 Notas finales

Palabras clave: pruebas de software, inspecciones, pruebas unitarias, pruebas de sistema.

1. Ciclo de vida de las pruebas

Las pruebas no se pueden apartar del ciclo de vida del desarrollo de software. Una vez que se
ha definido el proceso y ciclo de vida del proyecto, la calidad y las pruebas van de la mano; se
gestionan con el mismo ritmo en un plan específico para el aseguramiento que defina y se alinee
con los objetivos, alcance, costos y tiempo establecidos por el plan general del proyecto. Las
tareas relativas al aseguramiento forman parte del plan general y son consideradas actividades
del proyecto. Como en todo proceso de software, las fases mínimas son el análisis, el diseño, la
codificación, las pruebas y el mantenimiento.
Usualmente las pruebas se consideran una fase, pero es claro que la calidad debe asegurarse
en todas las etapas. Por lo tanto, el proceso de pruebas se realiza en cada una de estas fases.
El propósito de las pruebas es validar que el análisis, diseño y codificación correspondan a los
requerimientos, a través de un método de monitoreo y control ordenado. El mantenimiento (o
avance por etapas) exige cambios sobre el software, que debe ser controlado por un proceso de
administración de configuraciones que permita identificar componentes, versiones y facilite la
integración. De allí la importancia de contemplar la documentación del usuario y la del sistema
para cambios a futuro.
Pero si hay una fase de verificación, ¿qué hacemos en las otras fases? Bien, ya vimos que la calidad
no es solamente probar. Se requiere de procesos en los cuales la calidad se evidencie. Por ello,
cada fase tiene una validación de la calidad que determina si el propósito de tal fase se cumple
estableciendo los criterios de aceptación correspondientes. Cada proceso debe ir ligado con los
datos de prueba que determinen que el producto se puede aceptar y el tipo de pruebas a realizar,
como se muestra en la Figura 1, que desglosa el método V, diseñado por la Administración
Federal Alemana para el control del proceso de desarrollo de software. En tal método, los
requerimientos de usuario determinan las pruebas de aceptación por parte del cliente, dado que
se define cada requisito como un conjunto verificable y medible, que el aplicativo debe cumplir.
Así mismo, las pruebas del sistema corresponden al documento de especificación de
requerimientos del software, que cubren en detalle los objetivos del programa que se debe
entregar al cliente. La arquitectura del sistema se valida para establecer si cumple con las pruebas
de integración de todos los subsistemas, módulos, aplicativos o librerías usadas para dar solución
al problema planteado. El diseño detallado de cada programa, función o rutina debe cumplir con
las pruebas unitarias para verificar que cada uno de los componentes cumple con las funciones
asignadas, a partir de las entradas y salidas específicas y establecidas por los diseñadores e
implementadas por los programadores.
El plan de pruebas adaptado al ciclo de vida a desarrollar, en resumen, documenta la cobertura,
los métodos, la documentación y las responsabilidades en cada fase del proyecto.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 2
El plan debe incluir al menos los objetivos, los elementos a probar, la estrategia a usar en el
desarrollo de los procedimientos de prueba, su ambiente, criterios de aceptación, datos de
prueba, tipos de prueba a realizar, sus responsables, el cronograma, los reportes y formatos, los
riesgos, el control de cambios, la administración de la configuración, etc.

Figura 1. Modelo V de pruebas

Fuente: 1tjf (s.f.)

En cada fase, las revisiones técnicas (inspecciones, presentaciones o revisión de pares) son las
más adecuadas porque reducen la cantidad de errores producidos, porque se centran en áreas y
objetivos particulares más pequeños, para asegurar que los componentes sean aptos para las fases
posteriores de integración. Estas últimas son más costosas de corregir por las tareas a rehacer,
las revisiones sirven además para documentar lecciones aprendidas y mejorar los procesos locales
en cada etapa. De nuevo se usa el mecanismo de dividir y conquistar, al establecer un plan de
pruebas en cada proceso llevado a cabo de manera estática, aunque en etapas posteriores, ya que
hay software real a revisar en ejecución y pueden realizarse pruebas dinámicas.
El modelo cíclico PDCA se aplica en cada fase con la definición del plan a seguir, la ejecución
de las pruebas, el reporte de fallos encontrados y la corrección de los mismos. Así, no se pasa a
la siguiente fase hasta que se esté libre de errores. En un modelo ágil, en espiral o por prototipos
esto es igualmente válido que en los modelos tradicionales de línea conservadora. Para llevar
a cabo una inspección de sigue el modelo de Fagan en el cual hay un líder, un relator, un
programador y un inspector.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 3
 Cómo mejorar...
El estándar IEEE 829-2008 para la documentación de pruebas de software indica los elementos y
etapas a ser cubiertas en un plan de pruebas.

La inspección se planea preparando el material, los participantes y la agenda. Se prepara para

determinar el alcance de la prueba, asignar los roles y conocer del tema específico. Se lleva a
cabo la inspección y el programador con los resultados conseguidos en el reporte, rehace el
trabajo para entregar al líder y generar la siguiente inspección hasta su aceptación. Se llama
prueba de pares porque son personas del equipo de trabajo y no auditores formales externos.
Las inspecciones serán el mecanismo más usado en la gestión de pruebas, pues solo en las
fases finales se tiene suficiente código para realizar pruebas dinámicas y de aceptación con la
formalidad y rigor establecidos en el plan.

2. Verificación de requerimientos

Las necesidades de usuario deben siempre terminar en una especificación de requerimientos

de software que debe incluir una descomposición de funciones y una descripción de todas
las interfaces. Esto para verificar el cumplimiento de requerimientos y definir los criterios de
aceptación del sistema.
En los procesos de mejora continua, los resultados de procesos anteriores llevan a la construcción
de listas de chequeo que, clasificada en una taxonomía definida por la empresa, ayuda a la revisión
de problemas presentados en el pasado y a la prevención y detección temprana de nuevos casos.
Los errores deben ser documentados y reparados a la brevedad posible, porque ello fijará la
prioridad y objetivos del proyecto a realizar, junto con sus costos, tiempo y esfuerzo requeridos.
Una vez llegado a un acuerdo inicial, es necesario mantener un rastro que permita seguir cada
requerimiento a través del código, las pruebas, los cambios, el tratamiento dado y su criterio de
aceptación. Estas pruebas de aceptación son formales lideradas por el usuario final, en aras de
validar el cumplimiento del producto final de software.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 4
Esto no quiere decir que no se puedan aceptar funciones por etapas o a medida que se vayan a
montar en ambiente de producción. Esta es la base para la construcción de los casos de prueba,
ya que se basa en las funciones solicitadas y en la descripción de los procedimientos o flujo de
tareas obligados para llegar a los resultados requeridos por el cliente.
Cada elemento de prueba debe documentarse indicando las características del mismo, de modo
que se conozca su estado en cada momento del proyecto. A partir del PMBOK del PMI, en la
Internet se ofrece una amplia gama de formatos que pueden servir a este propósito. Igualmente,
la cantidad y esfuerzo deben estimarse para construir el plan de pruebas e integrarlo al proyecto
determinando costos, tiempo, personal y adquisiciones necesarias para llevarlo a cabo.

3. Verificación del diseño

El diseño es una representación del problema presentado en términos de los datos, el proceso de
transformación y la presentación de las salidas en la plataforma del cliente y con la arquitectura
adecuada a la solución requerida, de acuerdo a la lista de funciones determinada. El plan de
pruebas de la fase anterior se complementa con la verificación de que todos los elementos
representados en la especificación de requerimientos estén completos en el diseño realizado. Se
generan adicionalmente matrices que determinan el tipo de pruebas a realizar y las de integración
de acuerdo al grupo de funciones y módulos generados en el diseño. La logística y manejo de
correcciones se agrega en esta fase, junto con el esbozo de la administración de configuraciones y
las herramientas de pruebas.
La fase de diseño proporciona la definición de la interfaz pública entre los programas a especificar,
por lo que, de nuevo, las inspecciones son el medio de prueba preferido para detectar errores.
Ya sea por fallas en el paso de argumentos o en el flujo de tareas de cada función definida para
alcanzar la solución del problema. Igualmente, en este momento se alcanza a definir el conjunto
de datos persistentes y la afectación que desde diferentes elementos del producto de software
se tendrá. Con ello se pueden agregar factores de verificación adicionales como control de
concurrencia, fallas de seguridad, doble afectación, etc. Las pruebas de integración y modulares
empiezan a surgir por el agrupamiento de componentes y la separación de módulos con
funciones específicas y necesarias en la interfaz pública de los programadores. Se puede validar
el cumplimiento de prerrequisitos y las condiciones de las salidas, así como el tratamiento de los
errores controlados por el sistema.
El diseño de los algoritmos, que luego se codificarán, permite delinear los casos de prueba
unitarios, avanzar en las pruebas de integración y modulares y terminar las de aceptación y
del sistema. Los casos de prueba y el conjunto de datos se hacen cada vez más claros.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 5
La matriz de funciones, requerimientos, programas y elementos de prueba se va refinando. El
flujo del programa permite la definición de combinación de datos a revisar y el establecimiento de
límites y rangos a verificar la determinación de pruebas de carga, rendimiento y eficiencia. Con el
diseño detallado podemos establecer casos de prueba de caja blanca y de caja negra, para las fases
posteriores, además de las inspecciones del código, que son igualmente eficaces. La cobertura de
las pruebas debe revisarse para establecer que todo el producto de software será probado; pues el
detalle lleva a listas más largas de funciones y dejar de lado alguno es una posibilidad.

4. Verificación de la programación

Para esta fase, el plan de pruebas está completo. Los resultados ya han sido definidos y la
ejecución de los programas debe conducir a lograrlos. Se inician las pruebas dinámicas, a partir de
las pruebas unitarias, las de integración, las modulares o de sistema y las de aceptación por parte
del usuario. El propósito es detectar errores en ámbitos pequeños y solo al establecer su correcto
comportamiento agregarlos al sistema.
Cobra importancia el uso de herramientas para automatización de pruebas o la generación de
datos aleatorios para las pruebas. Se pueden establecer técnicas de caja blanca y combinación de
datos específicos para validar la lógica correcta del programa.
Las pruebas se deben llevar a cabo en el ambiente de ejecución, pero no en el de producción,
de tal suerte que no se afecten los datos reales, pero sean válidas las pruebas relacionadas con
el desempeño y la interacción entre elementos internos y externos al sistema. Las pruebas de
aceptación son ejecutadas por el usuario final y validan que los requerimientos establecidos se han
cumplido y se realizan luego de que el equipo de desarrollo ha concluido las suyas, de acuerdo al
plan de pruebas definido en el proyecto.
Como se observa en la Figura 2, las diferentes fases del ciclo de desarrollo interactúan y aplican a
lo largo del proyecto para obtener un producto de software de calidad y no de modo secuencial e
independiente como era la usanza en el siglo pasado con proyectos de menor escala y con pocos
o ningún usuario directo. Hoy en día estos elementos se entrelazan en ciclos de desarrollo cortos
para mostrar avances y tomar decisiones sobre la marcha.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 6
Figura 2. Fases de desarrollo
Fuente: Aksoy (s.f.)

5. Principios de calidad del ciclo PDCA

Deming, en 1986, en su libro Out of the Crisis, indica que la calidad se logra con el cambio
de filosofía, no con el seguimiento de pautas. Repasemos los puntos claves expuestos
por él. Se debe pensar a futuro, planear a largo plazo, con la base de que la calidad requiere de
educación, investigación e innovación para la mejora continua del producto, con un plan de
aseguramiento de la calidad que mantenga el rumbo constante para las actividades diarias. Se
debe cambiar de pensamiento, el aceptar los niveles de defectos y calidad va en contra de las
leyes de la mejor continua de la calidad y afecta la productividad, mantenga criterios de tolerancia
baja para los defectos y estándares altos para la calidad a lograr.
Se debe anticipar los errores y detectar las causas que los producen, no se debe basar el sistema
de calidad en la ejecución de pruebas exhaustivas; por el contrario, la mejora de los procesos y las
técnicas de producción deben revisarse para asegurar la calidad, no solo del producto final sino
de cada paso ejecutado. Se debe pensar en la calidad de los proveedores y no guiarse solo por su
precio. La conciencia del trabajo en solitario no existe, las relaciones de negocios y el enfoque en
aspectos especializados es cada vez más palpable. Por ello, se debe prestar atención a quienes
proveen servicios en aras de obtener alineamiento en los aspectos de calidad, que aseguren un
futuro para ambas partes y relaciones a largo plazo.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 7
La mejor continua exige actores instruidos constantemente. El entrenamiento es vital para el
proceso; de lo contrario, los avances se harán por etapas y se tenderá a permanecer en un estado
sin cambios a futuro, pues se creerá que ya las técnicas fueron aplicadas y no hay espacio para
mayores mejoras. Se debe incentivar el conocimiento y la novedad en las personas. Se debe
invertir en la gente. No basta con tener personal que haga el trabajo, toca que valore lo que hace
y se sienta orgulloso de ello. Se debe entrenar al personal, escuchar sus opiniones, conocer los
problemas que dificultan el desarrollo de su trabajo.
Se debe inculcar que la calidad es parte de su responsabilidad, pero también el reconocimiento
de un trabajo bien hecho. Se debe incentivar el liderazgo al delegar responsabilidades para que
cada persona sienta que aporta al grupo y que se requiere de su buen desempeño. Se debe evitar
generar retos que no se puedan cumplir y quemar el recurso. Es mejor contar con personas
fiables y en mejora continua que quebrarlos y despedirlos por llevarlos más allá de sus limitaciones.
Por el contrario, se debe descubrir sus fallas y entrenarlos para su mejora.
Asociar la calidad con la detección de fallas en el personal conlleva al miedo. Igualmente, el
temor entre áreas y las escalas de jerarquía en el personal afectan el desarrollo de la calidad, los
aportes y sugerencias de mejora se convierten en piedras en el zapato. Por el contrario, se debe
incentivar el trabajo en equipo, pero pensado siempre en la mejora de la empresa y que los errores
descubiertos internamente no afectan, como sí lo hacen los hechos por el cliente. Se deben fijar
metas realistas que describan el modo de lograrlas y especifiquen qué es aceptable y qué no lo es.
La calidad no se consigue fijando metas sino mejorando los procesos y entendiendo las fallas que
en ellos se presenta. Se deben definir estándares y procedimientos que ayuden a la empresa a
tener calidad. Se debe impulsar la calidad desde el tope de la empresa. La calidad no se genera
solo en las actividades operativas. El norte a seguir está dado por la mejora continua de la calidad;
esta se logra a través del tiempo, con políticas e incentivos que redunden en beneficio para todos
los integrantes de la organización.

6. Las pruebas en metodologías ágiles

Como hemos dicho, el modo de llevar a cabo las pruebas va de la mano del ciclo de vida del
desarrollo. Esto es válido aún para modelos en que el ciclo de vida no parece tan definido;
más bien que parece planearse sobre la marcha. Si se siguen prácticas de desarrollo ágil, en
consecuencia, las pruebas deben aportar al desarrollo. Deben verse no como una fase (una vez
construido el software), sino en paralelo con el desarrollo, para garantizar que el avance continuo
sea fiable.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 8
Ya que se da retroalimentación permanente de los cambios y las correcciones necesarias
definidas, para que los tiempos de cada iteración se cumplan. No solo en cuanto a liberación
de código sino en la verificación de su correcto comportamiento y aceptación antes de pasar al
siguiente ciclo. Esto conlleva una reducción de la planeación y documentación de las pruebas,
pero a cambio se centra en los casos de prueba siguiendo listas de chequeo. Por ello, debe
involucrarse personal experto que aporte al grupo y no lo retrase.
Algunos ingenieros que aplican métodos ágiles de desarrollo consideran que las técnicas de
conducción de pruebas no aplican para las metodologías ágiles; aunque realmente sí lo hacen.
Solo que lo antagónico entre los sistemas de desarrollo ingenieriles versus los métodos de
desarrollo ágil se reflejan más en una lucha de pareceres que en las diferencias reales que
los separan, las cuales son pocas. En pruebas ágiles se habla de desarrollo dirigido a pruebas,
desarrollo dirigido a comportamiento o a aceptación, pero su núcleo se basa en los mismos
principios y planes de los sistemas tradicionales, solo que, aplicados a cada iteración y
funcionalidad, que se va agregando al software.
De este modo, pequeños ciclos de la metodología de pruebas se desarrollan para pequeños
grupos de requerimientos y en ciertos casos pueden ser probados dinámicamente solo hasta
que se tenga el código fuente desarrollado o integrado. Por el contrario, en otras iteraciones las
pruebas unitarias sí se realizan en el orden establecido, según como avance la programación. El
reto es el tiempo, los imprevistos y la buena comunicación entre los integrantes para resolver
rápidamente los inconvenientes presentados.
El marco de referencia de pruebas ágiles se basa en 4 cuadrantes que dividen las pruebas entre
dos ejes: i) aquellas que soportan el equipo de desarrollo y las que son críticas para el producto;
el otro eje ii) las divide entre las que se hacen de cara al negocio y las que se hacen de cara a la
tecnología. En cada cuadrante se ubican diferentes tipos de prueba y recomendaciones acerca de
cómo llevarlas a cabo, pero es básicamente la aplicación de lo que se presenta en el módulo, solo
bajo la filosofía de asegurar ciclos cortos, refactorización y reutilización del código.
Para terminar, vale la pena indicar que en los cuadrantes se hacen recomendaciones para
automatizar las pruebas. Sin embargo, esto debe hacerse con precaución, de tal suerte que la
labor de programación de pruebas sea para aquellos aspectos que estén definidos como vitales y
necesarios a entregar al cliente. De otro modo, se corre el riesgo de gastar esfuerzos en pruebas
de elementos que no se sabe si serán o no importantes y definitivos en el software final a entregar.

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

Un plan de pruebas define las condiciones en que se ejecutarán, de acuerdo con el ciclo de
vida del proyecto planteado. Se lleva a cabo a lo largo del proyecto en cada fase, para tratar de
prevenir errores y hallarlos lo más pronto posible, esto evita costos mayores en etapas posteriores.
La calidad y detección de errores va de la mano con las metodologías y herramientas de mejora
de los procesos y el control a través de inspecciones para asegurar la calidad en cada etapa. La
calidad no es labor de un día, ni un intento de un grupo de héroes, es una línea de pensamiento
integral para cada labor diaria realizada con responsabilidad y entendiendo el beneficio de
realizarla.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 10
Referencias
Boloix, G. (2009). Evaluación en informática. Córdoba, AR: El Cid Editor | apuntes.
Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/
bibliopoligransp/detail.action?docID=3182407&query=Evaluaci%C3%B3n%20en%20
inform%C3%A1tica
Echeverri, J., Aristizabal, M., González, L. Urrego, G., Polo, R. Reflexiones sobre ingeniería
de requisitos y pruebas de software. (2013). Medellín, CO: Corporación Universitaria
Remington. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.
co/lib/bibliopoligransp/detail.action?docID=4795310&query=Reflexiones%20sobre%20
ingenier%C3%ADa%20de%20requisitos%20y%20pruebas%20de%20software
Hernándes, P. F. Á., & Ricardo, Z. P. M. (2006). Glosario de Términos Informáticos. Córdoba,
AR: El Cid Editor. Recuperado de https://ebookcentral-proquest-com.loginbiblio.poligran.
edu.co/lib/bibliopoligransp/detail.action?docID=3167493&query=Glosario%20de%20
T%C3%A9rminos%20Inform%C3%A1ticos
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. Recuperado de
https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/detail.
action?docID=3216137&query=T%C3%A9cnicas%20de%20mejora%20de%20la%20
calidad
Gutiérrez, H. (2013). Control estadístico de la calidad y Seis Sigma (3a. ed.). México, D.F.,
MX: McGraw-Hill Interamericana. Recuperado de https://www.ebooks7-24.com/book.
aspx?i=280
Gutiérrez, H. (2014). Calidad y productividad. (4a. ed.). México, D.F., MX: McGraw-Hill
Interamericana. Recuperado de https://www.ebooks7-24.com/book.aspx?i=751
Maigua, G., & López, E. (2012). Buenas prácticas en la dirección y gestión de proyectos
informáticos. Buenos Aires, AR: Editorial de la Universidad Tecnológica Nacional. Recuperado
de https://ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/
detail.action?docID=4909345&query=Buenas%20pr%C3%A1cticas%20en%20la%20
direcci%C3%B3n%20y%20gesti%C3%B3n%20de%20proyectos%20inform%C3%A1ticos
Marcelino, A. M., & Ramírez, H. D. (2014). Administración de la calidad: nuevas
perspectivas. México, D.F., MX: Grupo Editorial Patria. Recuperado de https://
ebookcentral-proquest-com.loginbiblio.poligran.edu.co/lib/bibliopoligransp/detail.
action?docID=3227569&query=Administraci%C3%B3n%20de%20la%20calidad:%20
nuevas%20perspectivas
Pressman, R. (2010) Ingeniería del software un enfoque práctico (7a. ed.). México, D.F.,
MX: McGraw-Hill Interamericana. Recuperado de https://www.ebooks7-24.com/book.
aspx?i=686
Project Management Institute. (2013). Guía de los fundamentos para la dirección de proyectos
(guía del PMBOK®) -- Quinta edición. Pensilvania, EE.UU.

Referencias de gráficas
1tjf. (s.f.). Detailed Software Development Life Cycle V-Model Including Phases, levels,
Documentation, Review [Ilustración]. Recuperado de https://www.123rf.com/search.
php?word=v+model&imgtype=0&t_word=&t_lang=en&orderby=0&t_word=&t_
lang=en&oriSearch=cwqc&sti=lovmtztqt8wbpc8z3k|&mediapopup=14805492
Aksoy, R. (s.f.). Software engineering concept [Ilustración]. Recuperado de https://
www.123rf.com/stock-photo/software_verification.html?imgtype=0&oriSearch=code+
verification&sti=memnpvejo8m6uzlosi|&mediapopup=75970060
 INFORMACIÓN TÉCNICA

Módulo: Pruebas y Calidad de Software

Unidad 1: Calidad de software y el ciclo de vida
de las pruebas.
Escenario 2: Ciclo de vida de 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 13