Unidad 2 / Escenario 3

Lectura fundamental

El plan de pruebas

Contenido
1 El ciclo PDCA de pruebas

2 Información para el plan de pruebas

3 Elementos del plan de pruebas

4 Notas finales

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

1. El ciclo PDCA de pruebas

El plan de pruebas debe alinearse con el ciclo de vida del proyecto, pues forma parte del mismo,
y la interrelación entre probadores y desarrolladores es estrecha. Un probador valida lo que el
programador hace y un programador corrige los hallazgos del probador; ambos deben conocer del
producto a desarrollar y del modo como están creando la solución. Ahora bien, como las pruebas
se realizan a lo largo del ciclo de vida del proyecto, a medida que se ejecuta cada proceso, como
cada nuevo producto de software se va integrando al sistema y requiere de pruebas propias y
revisiones a los cambios hechos podemos pensar que la metodología de las pruebas es un ciclo.
Sin embargo, en cada vuelta se requiere comprobar lo antes probado (pruebas de regresión) y
agregar al plan de pruebas la nueva funcionalidad agregada. Entonces tenemos una espiral que
incrementa con cada avance del proyecto (Figura 1).

Figura 1. Ciclo PDCA

Fuente: Modificado de Weidenhofer (s.f.)

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 2
De este modo, cada prueba debe ser realizada con el ciclo PDCA (planear, hacer, verificar
y actuar): planear la prueba, diseñar los casos de prueba, ejecutar las pruebas y reportar los
resultados para que se realicen los cambios. En cada prueba llevada a cabo, el proceso de prueba
no debe ser el mismo porque las condiciones específicas de cada producto de software, que se
desea revisar, son distintas y los casos de prueba son propios de cada uno de ellos.
El plan de pruebas (la P del ciclo) guía el proceso y define procedimientos, participantes,
funciones, tipos de pruebas, reportes, listas de verificación, cronogramas y los requerimientos
incluyendo personal, equipos, software y los datos de prueba que deben levantarse a lo largo de la
organización y cada cliente del producto a desarrollar.
»» La D del ciclo se encarga del diseño de los casos de prueba a nivel funcional, de interfaces,
definir los criterios de aceptación, los script y procedimientos detallados para la ejecución
de la prueba concreta a llevar a cabo. Cubre también su desarrollo y el registro de los
hallazgos realizados.
»» La C del ciclo conlleva el análisis de la prueba desarrollada, el registro de las métricas la
comparación contra cronogramas y la estimación de esfuerzo y cambios en el plan y los
reportes de avance al equipo del proyecto.
»» La A del ciclo corresponde a la implementación de los cambios a procedimientos y plan
de trabajo para el siguiente ciclo a ejecutar.

Este modelo se alinea perfectamente con las cuatro fases del desarrollo de software: análisis,
diseño, codificación y pruebas (Figura 2); se usa en pruebas unitarias, de integración, de sistema y
de aceptación. La razón es que, independientemente del ciclo de vida elegido, el grupo de trabajo
del proyecto tiene que realizarlo por partes y cada entregable puede ser sujeto de pruebas y
detección de errores para reducir daños en etapas posteriores, ya que la salida de un proceso es la
entrada de otro. La ganancia fuerte está en que el método es siempre el mismo y la reutilización
es altamente aplicada, pues los casos de prueba pueden servir en varias etapas y ciclos de
revisiones. Igualmente, el conjunto de pruebas puede ser automatizado, pues se ejecuta en cada
prueba realizada de modo repetitivo para evitar daños en componentes antes liberados como
consecuencia de un cambio posterior.
Una ventaja adicional del esquema en espiral es que se ajusta al modelo V de pruebas de un modo
natural. Ya que, sin importar el ciclo de vida escogido, las actividades de programación se realizan
definiendo objetivos (requerimientos), se diseñan (propuesta de solución) y se codifican; con lo
cual se dan los pasos requeridos en el plan de prueba y es posible la verificación a medida que se
construye y la validación mientras se entrega para completar el aplicativo. Los requisitos llevan
a las pruebas de aceptación, las de diseño a las de sistema e integración y la codificación a
las unitarias.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 3
Figura 2. Modelo V
Fuente: Modificado de Zabelava (s.f.)

La espiral asegura que los casos de prueba establezcan si las validaciones sobre los datos de
entrada son correctas, si los procedimientos producen los resultados requeridos y si la ejecución
del sistema está bien definida a lo largo de todo su ciclo de operación. En general, no solo se
trata de encontrar fallos sino de hacerlo pronto para mejora del resultado final (Figura 3). En
cada vuelta se debe prestar atención a lo nuevo, pero sin olvidar todo lo anterior para comprobar;
que los cambios no causaron daño en los componentes anteriormente liberados. Esto hace
que se convierta en un proceso de mejora continua. El final del proyecto o de las pruebas se
debe generar un reporte adicional de resultados que resuma los procesos realizados en gráficos
estadísticos que permitan el análisis de mejoras a implementar a futuro en los procesos y técnicas
de pruebas para los siguientes proyectos.

2. Información para el plan de pruebas

Aunque el plan de pruebas requiere información constante a lo largo del ciclo de vida del
proyecto, por lo general la obtención de información se asocia a la fase de requerimientos en
la construcción de software y el método más usado, pero no el único es el de las entrevistas
(Figura 4).

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 4
Figura 3. Acciones en cada fase del PDCA
Fuente: Modificado de Ivanov (s.f.)

Como las pruebas se trabajan de la mano del equipo de trabajo y la gerencia del proyecto da las
pautas, conviene realizar el levantamiento de requisitos del cliente con el propósito de obtener los
datos necesarios para desarrollar el plan de pruebas y no generar entrevistas aparte que desgasten
al usuario contando varias veces su historia, ya que el propósito es el mismo: obtener información
del proyecto, definir el alcance, las necesidades del usuario, definir el ambiente de ejecución del
producto de software y conocer los datos relevantes para construir el plan de trabajo.

Figura 4. Actividades del proyecto

Fuente: Modificado de Mnsanthoshkumar (s.f.)

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 5
Es importante destacar que el cambio de requerimientos del usuario no solo afecta el esquema de
calidad y pruebas, también puede disparar procedimientos para cambio en los objetivos, tiempo
y costo del proyecto. Una solicitud de cambio debe analizarse para revisar la incidencia sobre el
proyecto y las alternativas para llevarlo a cabo, reestimando todas las actividades del proyecto. Por
el contrario, los fallos del producto de software, aunque pueden implicar retrasos, deben tratarse
como parte del proyecto y las contingencias propias del desarrollo. Igualmente pueden llevar a
situaciones de reparación que alteren de gran modo lo inicialmente planeado. Por ello se insiste
en una buena especificación de requerimientos.
No obstante lo anterior, el plan de pruebas va ligado al proceso de gestión de calidad y a la
administración del proyecto, por lo tanto se requiere que el equipo de pruebas participe en todas
las etapas del proyecto y esté en las reuniones de control para estar al tanto del progreso, cambios
y estrategias seguidas para adaptar su trabajo en la calidad y retroalimentar a la gerencia del
proyecto y a los demás integrantes. Las entrevistas como medio para lograr la comunicación de
la información relevante y necesaria entre los participantes deben realizarse tantas veces como
sea necesario, pero se debe prestar atención a que sean realmente efectivas, su objetivo debe
ser claro y en lo posible tener presentar de antemano el material y aspectos a considerar para
llevar a cabo la reunión. De otro modo, se perderá tiempo enterando al personal del objetivo y las
decisiones no podrán ser tomadas en el lapso de tiempo asignado.
Los horarios y propósito deben ser respetados junto con la agenda y cualquier desvío del tema
debe ser impedido y registrado para establecer las citas futuras y preparación que se deba realizar
en una nueva entrevista. El respeto por el tiempo de las personas, la comunicación efectiva
y la consecución de los propósitos planteados redundarán en el interés de participar y evitar
el desgaste y pérdida de confianza en este mecanismo, lo que permite uno de los aspectos
comunicativos más importantes, que es: habla cara a cara.

3. Elementos del plan de pruebas

Al acomodarse al ciclo de desarrollo del proyecto y al realizarse en espiral, el plan debe ser
repetible, flexible y definido, de tal suerte que los objetivos, estrategia, criterios de aceptación,
diseño de los casos de prueba y la documentación se lleve con éxito con una metodología
constante que permita las variaciones y adecuaciones necesarias a cada caso específico pero
conciso y completo sobre los aspectos a cubrir para impedir que se queden elementos de calidad
por fuera del trabajo a desarrollar. El estándar IEEE-829 Standard for Software and System Test
Documentation de 2008 define 8 documentos diferentes, de acuerdo a la etapa o actividad
del proceso de pruebas. 5 para la especificación de las pruebas, 2 para la ejecución y 1 para el
reporte final.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 6
En cada uno de ellos se desglosan los elementos que debe contener el documento, para asegurar
el cubrimiento y definición de las actividades a desarrollar y los procedimientos a seguir en cada
paso dado. Demos un vistazo a los aspectos que se deben tener en cuenta.
»» Identificación: como cualquier documento del proyecto, se debe seguir un mecanismo
para determinar a qué corresponde un documento y la versión del mismo. Recordemos que
además del plan, se tienen documentos adicionales para cada etapa del proceso de calidad.
»» Referencias: el equipo de pruebas puede ser interno o externo, puede llegar al inicio del
proyecto o en etapas posteriores; así que referenciar los documentos importantes del
proyecto a tener en cuenta no está de más. Igualmente, el detalle externo a las pruebas no
debe volverse a redactar, pero sí determinar en dónde encontrar la información.
»» Introducción: por lo dicho, un bosquejo de los aspectos importantes y críticos del proyecto
y el producto, con respecto al proceso de pruebas, debe mencionarse para generar el
contexto apropiado: objetivo, cronograma, presupuesto, restricciones, procedimientos,
metas, riesgos, etc.
»» Funciones a prueba: el alcance de las pruebas se debe realizar en una jerarquía, del mismo
modo en que se reciben los requisitos y se determinan los criterios de aceptación y se
desciende en el modelo V de pruebas. Es necesario listar las funciones que se probarán,
empezando por las reglas del negocio que son las más genéricas, pero más importantes, o los
principales objetivos del producto de software, que guiarán el plan tanto del proyecto como
de las pruebas.

Una vez definidas las funciones que cumplirán los requerimientos del cliente, y que darán a
lugar a las pruebas de aceptación, se procede a definir el nivel siguiente en la jerarquía para
cubrir las pruebas del sistema. Lo que corresponde a la lista de las funciones de alto nivel,
luego continuaremos hacia abajo para determinar el plan a seguir, de acuerdo con pruebas de
integración y unitarias. Hay que aclara que, de acuerdo al estado del proyecto, es posible que
algunas de estas listas solo se puedan construir con un avance mayor del mismo, por lo que el
plan debe cubrir la especificación posterior de estas etapas y avanzar acorde se tenga la
información necesaria en su detalle. Ahora bien, pare evitar dudas se debe aclarar qué elementos
no están cubiertos por el alcance y objetivo de las pruebas y no serán incluido en el plan de
pruebas a realizar.
»» Criterios de aprobación o falla: el propósito de las pruebas es la detección temprana de
errores, pero esto conlleva costos, tiempo y esfuerzo asociados. En algún momento se debe
parar y el plan debe incluir criterios para ello de acuerdo a un porcentaje de casos de prueba
pasados, la gravedad de los errores encontrados, el tiempo empleado, la cobertura de los
aspectos más críticos, el nivel de riesgo de las funciones restantes con fallas, la disminución
importante de las fallas encontradas, etc.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 7
 De nuevo, juega un papel importante determinar en el plan las pruebas el rigor de la
construcción de los casos de prueba y que los mismos no solo cubran las pruebas funcionales
sino las de regresión para probar lo corregido, como las de integración para corroborar que
los componentes nuevos se adaptan adecuadamente al sistema construido. Un mal conjunto
de datos de prueba puede dejar pasar varios errores que solo se verán reflejados tardíamente
o luego de su entrega y puesta en operación, lo que mina la confianza en el proceso de
calidad seguido.
»» Criterios de suspensión y reactivación: otro aspecto a tener en cuenta es la gravedad del
fallo que afecta los datos utilizados en el caso de prueba. Por lo tanto, se deben establecer
criterios para determinar en qué eventos de falla suspender la prueba viciada, para retomarla
solo a la corrección de tales fallas mayores y evitar el gasto en pruebas de las cuales no se
puede deducir si son válidas o no. Las pruebas de regresión, si están automatizadas, pueden
no ser costosas. Si es el caso, es necesario definir en el plan de pruebas los criterios en los
cuales se correrán para limitar o reducir su uso y el desgaste ante correcciones que no las
ameriten. Todo ello debe incluirse en el plan a desarrollar como política. De nuevo, el trabajo
conjunto con los desarrolladores nos debe brindar el apoyo para determinar el rango de
afectación de una nueva funcionalidad, cambio o corrección realizada.
Si no tenemos acceso a esta información, se debe establecer una estrategia de pruebas de
caja negra basada en el establecimiento de casos de prueba, de acuerdo a las condiciones y
combinaciones de los datos usados por el usuario final. Las pruebas de regresión cobran más
importancia, pues en cada espiral, al no saber la incidencia de una nueva versión liberada,
se debe garantizar que lo probado no sufrió alteraciones inconvenientes. Por lo tanto, es
recomendable pensar en la automatización de tales pruebas.
»» Entregables: un proyecto se divide en actividades, pero se agrupan en entregables que
garanticen que el avance hacia la finalización esté documentado con asignación de roles
muy claros sobre quién hace la tarea, quién responde por ella, quiénes la validan y quiénes
deben ser informados. En el caso de las pruebas la estrategia es la misma, el plan de prueba
debe definir los documentos firmados por las partes, en los cuales se evidenciará que la
labor fue realizada y los hallazgos encontrados. Además del documento mismo del plan de
pruebas, que dice el quién, cómo, cuándo y dónde de las pruebas del proyecto, se tienen los
siguientes:
• Documento de especificaciones del diseño de las pruebas, que indica lo que debe
probarse y justifica cómo las pruebas diseñadas validan las necesidades del cliente.
• Documento de los casos de prueba con datos entrada, salidas, lista de chequeo, orden
y procedimientos para realizar cada prueba, de acuerdo al documento de diseño y el plan.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 8
 • Documento de especificación de procedimientos de las pruebas, con los pasos para
prepararla, ejecutarla y las acciones a desarrollar; de acuerdo a los hallazgos y su
desenvolvimiento.
• Documento de transmisión de pruebas con el reporte de los productos de software, que
pasan de una fase a otra, ya sea por cumplimiento o falla o por el cambio o liberación de
una versión.
• Documento de registro de pruebas con el rastro de la prueba realizada, su orden y los
hallazgos encontrados indicando qué se hizo, quiénes participaron y la lista de cada ítem
aprobado o fallado.
• Reporte de incidentes, con los errores en el procedimiento de pruebas o con los casos de
prueba o con las herramientas de prueba utilizadas para validar el producto de software.
• Reporte resumido de las pruebas con los datos importantes que deben ser conocidos
por los externos participantes del proyecto y permite la toma de decisiones para ajustes
requeridos.
»» Equipo de trabajo: incluye la definición de los roles, las responsabilidades, las habilidades y
entrenamiento requerido y quien lo proporciona, si son internas o externas a la organización,
quién realiza pruebas, quién lidera y quién administra, quién documenta, quién genera
estadísticas y métricas, quién automatiza, quién mejora procesos, etc.
»» Ambiente de pruebas: determina las condiciones físicas, tecnológicas y las herramientas
de hardware y software para realizar las pruebas y el acceso y uso de software, adicional de la
empresa si se trata de adaptaciones o de un producto de software que interactúa con otro.
»» Cronograma: aunque se debe ajustar al proyecto, se debe definir la duración en cada
proceso y definir las dependencias a la entrega del producto de software, más que a una
fecha en particular. Con ello, el proceso fluirá de acuerdo a la disponibilidad de todos los
involucrados y no solo a la del equipo de pruebas, que por lo general requiere de la presencia
de varios actores del proyecto en la ejecución de cada prueba. Nuevamente, el plan debe
especificar estas condiciones para su inserción en el cronograma global del proyecto
y generar los aumentos necesarios en el tiempo y establecer los hitos importantes del
proyecto que afecten la ruta crítica y que puedan generar retrasos de no cumplirse.
»» Estrategia: el plan debe determinar la respuesta a temas como las herramientas a usar, si las
pruebas son manuales o automatizadas, las métricas que puedan establecer tanto el avance
como la calidad del proceso llevado a cabo y el estado de las pruebas, de acuerdo con el
plan elaborado y la administración de configuraciones. Por supuesto cada fase del producto
de software requiere de un conjunto específico o estrategia particular, pues el propósito
u objetivo es diferente para asegurar la calidad. Es necesario establecer los medios de
comunicación de las fallas y el procedimiento de control de su reparación.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 9
 »» Tareas de prueba restantes: la administración de la configuración debe reglamentarse en
el plan para mantener concordancia en el control de versiones en desarrollo y en ambiente
de pruebas, así como para determinar los mecanismos de integración de las nuevas
versiones, una vez probadas, para continuar con la integración del sistema. Si el proyecto
se construye en fases o por varios terceros, es necesario conocer el estado de avance de
cada componente para realizar las pruebas en el contexto adecuado y definir en el plan
el mecanismo para tal flujo de información. Las pruebas que no se hayan podido realizar
por demora en las entregas del producto deben tratarse para no olvidarlas y hacerlas en el
momento en que el componente esté listo.
»» Riesgos y contingencias: el proceso de calidad y pruebas está expuesto a riesgos, como
cualquier otra actividad del proyecto. Estos deben tener un procedimiento para tratarse,
de tal suerte que cuando surjan se puedan tratar adecuadamente y se establezcan los
mecanismos para su solución. Por el contrario, los planes de contingencia pretenden
anticipar acciones para cubrir algunos riesgos del proyecto y rearmar el equipo para atender
tales situaciones, que se han definido como críticas en el proyecto o van ligadas a hitos que
deben cumplirse. De no hacerse requieren de acciones alternas para superarse.
»» Aprobaciones: el plan debe establecer de acuerdo a los roles de los participantes del
proyecto y a los niveles de aprobación que tienen, quienes serán los encargados de aprobar
cada actividad de prueba y los mecanismos a seguir en caso de no conseguir la aprobación.
Las pruebas se realizan con clientes, usuarios, desarrolladores y cada uno de ellos debe
entender el procedimiento, tiempos y reportes a generar en acuerdo o desacuerdo.
»» Glosario: el plan al ser de conocimiento de todos los involucrados en el proyecto, debe
indicar la terminología usada y explicar de modo suficiente de tal suerte que pueda ser
entendido por la audiencia.

4. Notas finales

La calidad es un proceso que debe estar en la mente de todos los participantes del proyecto y
de la empresa. La calidad se consigue con la verificación y la validación encaminadas a detectar
errores y establecer el cumplimiento de los objetivos pactados. Conocer las necesidades del
cliente, establecer claramente los requisitos y saber el ciclo de vida del proyecto son aspectos
fundamentales para establecer el plan de pruebas. Para ello se deben llevar a cabo reuniones o
entrevistas durante todo el proyecto.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 10
El plan de pruebas debe acogerse a los procedimientos del proyecto y el grado de formalidad
establecidos en él. Demasiada o poca formalidad y rigor en el proceso de pruebas puede dar al
traste con el proyecto, ya que siendo una actividad relacionada con los errores se tiende a ver
con ojos de enemistad. Se debe hacer énfasis especial en establecer un plan de colaboración y
ayuda al proyecto, en aras de concluirlo a tiempo con la mejor calidad posible. Eliminar, reducir
o simplificar procedimientos y tareas pueden ayudar a éste aspecto, pero sin comprometer el
aseguramiento de la calidad, que es el objetivo primordial a mantener.

POLITÉCNICO GRANCOLOMBIANO
POLITÉCNICO GRANCOLOMBIANO 11
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
Ivanov, A. Vector. (s.f.). Dark PDCA (Plan Do Check Act) diagram, schema [Ilustración].
Recuperado de https://www.123rf.com/stock-photo/pdca_cycle.html?imgtype=
0&oriSearch=continuous+improvement&sti=o3ipypxwd4s8obpx8y|
&mediapopup=34738124
Mnsanthoshkumar. (s.f.). Software development life-cycle process - concept vector line icons. This
graphic represents steps like specification & planning, coding & development,
execution & testing, optimization & delivery [Ilustración]. Recuperado de https://www.123rf.com/
stock-photo/testing_plannig.html?imgtype=0&oriSearch=testing+plan&sti=lce24gz5rzcphftv-
jp|&mediapopup=30836060
Weidenhofer, V. (s.f.). PDCA Lifecycle - Plan Do Check Act [Ilustración]. Recuperado de
https://www.123rf.com/stock-photo/pdca_cycle.html?imgtype=0&oriSearch=continuous+
improvement&sti=o3ipypxwd4s8obpx8y|&mediapopup=36666238

Zabelava, T. (s.f.). V-model software development [Ilustración]. Recuperado de https://www.123rf.

com/search.php?word=v+model&start=1200&t_word=&t_lang=en&orderby=
0&imgtype=0&oriSearch=deming&searchopts=&itemsperpage=100&sti=
n4c8gadbesvr1dd7ok|&mediapopup=67080188
 INFORMACIÓN TÉCNICA

Módulo: Pruebas y Calidad de Software

Unidad 2: Definiendo y ejecutando el plan de pruebas
de software.
Escenario 3: Definiendo el plan de 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 14