PLAN DE PRUEBAS (apoyarse en los 10 pasos para la elaboración
En el desarrollo de software, la fase de pruebas es crítica para asegurar que el producto
sea enviado a ambiente de producción con la calidad esperada por el cliente.
Es por esto que hoy en día es indispensable contar con un Plan de pruebas de software
para especificar minuciosamente las funciones a probar, como serán ejecutadas esas
pruebas, quienes serán los responsables y el cronograma para su ejecución.
El Plan de pruebas de software puede aplicarse a todo el proyecto de desarrollo de
Software, o puede acotarse a una iteración o conjunto de casos. Además, puede definir
jerarquías de casos de prueba a considerar.
Aquí les dejamos una plantilla de Plan de pruebas de software, entre sus secciones están
el resumen ejecutivo, alcance de las pruebas, funcionalidades a probar, pruebas de
regresión, criterios de aceptación y rechazo, criterios de suspensión y
reanudación, especificaciones de ambientes de pruebas, recursos de personal y
entrenamiento, matriz de responsabilidades, cronograma, riesgos, entre otros aspectos.
documento empleado: plantilla casos de prueba
Pruebas de software: 10 pasos para elaborar el plan de pruebas
El plan de pruebas de software se elabora para atender los objetivos de calidad en un
desarrollo de sistemas, encargandose de definir aspectos como por ejemplo los módulos
o funcionalidades sujeto de verificación, tipos de pruebas, entornos, recursos asignados,
entre otros aspectos.
¿Te solicitaron elaborar un plan de pruebas de software para tu próximo proyecto o
iniciativa?, pues entonces es recomendable que definas un método para hacerlo y que
luego puedas afinarlo por medio de la mejora continua.
Aquí te compartimos un método para documentar las diferentes secciones del plan de
pruebas de software, incluyendo el alcance, estrategia de pruebas, tipos de pruebas de
software a incluir, criterios de aceptación, requisitos de infraestructura, requisitos de
personal y la planificación.
1.- Analizar los requerimientos de desarrollo de software
Para elaborar un plan de pruebas de software lo primero que debes hacer es entender
los requerimientos de usuario que componen la iteración o proyecto, que son el sujeto
de la verificación de calidad que se va a realizar.
Deberás analizar toda la información de la ingeniería de requisitos, incluyendo la matriz
de trazabilidad, especificaciones y diseño funcional, requisitos no funcionales, casos de
uso, historias de usuario (si estás trabajando con metodologías ágiles), entre otra
documentación.
También es muy importante realizar entrevistas con el equipo encargado de la ingeniería
de requisitos para aclarar dudas y ampliar la información que sea necesaria.
Además de las preguntas específicas de cada requisito, es importante hacer preguntas
del alcance general, por ejemplo:
¿Es un sistema nuevo o existente?
¿Cuáles funcionalidades existentes están siendo modificadas?
¿Cuáles son los requisitos no funcionales? Entre otras.
2.- Identificar las funcionalidades nuevas a probar
A partir de la documentación del análisis de requisitos y de las entrevistas con el equipo
de ingeniería de requisito y desarrollo, debes identificar e incluir en el plan de pruebas de
software la lista de las funcionalidades (Características) totalmente nuevas.
Si estás trabajando con un sistema informático nuevo, no tendrás problemas en discernir,
pues todas serán nuevas.
En el caso de desarrollos de software integrados a un sistema existente es necesario
revisar con los analistas de negocio y también con los arquitectos de software las
funcionalidades que forman parte del desarrollo de software, en todas las capas de la
arquitectura.
3.- Identificar las funcionalidades de sistemas existentes que deben probarse
Se debe identificar las funcionalidades existentes que estén siendo impactadas por el
desarrollo de alguna forma, considerando todos los componentes afectados en todas las
capas de la arquitectura de software.
Existen dos situaciones que se puede encontrar al identificar estas funcionalidades:
• Funcionalidades modificadas de cara al usuario: Por ejemplo si una
funcionalidad está siendo modificada agregando más pantallas o cambios a su
flujo de proceso, debe ser incluida en el plan de pruebas de software.
• Funcionalidades modificadas en sus componentes internos: Son
funcionalidades no modificadas de cara al usuario, manteniendo la misma interfaz
gráfica y flujo de procesos, sin embargo, si se modifican componentes internos
que comparten con otras funcionalidades del sistema, en las capas de lógica de
negocio o acceso a datos. Estas deben incluirse en el plan de pruebas de software
para determinar a partir de ellas pruebas de regresión a realizar.
Quienes pueden suministrar la información serán los Analistas de
negocio o Arquitectos de software, familiarizados con el sistema informático
implementado en entorno de producción.
4.- Definir la estrategia de pruebas
iStockPhoto / HS3RUS
Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se
deben realizar.
Es recomendable seguir un marco de referencia para determinar los tipos de prueba,
como por ejemplo los tipos de pruebas de software definidos por el ISTQB.
Pruebas funcionales
Se determinan los conjuntos de pruebas a realizar, correspondiente con cada
funcionalidad nueva o existente que se esté modificando.
Se tienen distintos tipos de pruebas funcionales, por ejemplo, las pruebas de sistema (o
pruebas integradas de sistemas), que se realizan después que el equipo de desarrollo ha
integrado los componentes de distintas capas.
Las pruebas funcionales son definidas por el ISTQB como pruebas basadas en
especificación. Son diseñadas usando técnicas de diseño de pruebas de caja negra. Aquí
te compartimos un artículo interesante que habla sobre el tema.
> Pruebas de caja negra según el ISTQB
> Pruebas de caja negra: Ejemplos
Entre las pruebas funcionales, también están las pruebas de aceptación, en las cuales el
equipo de calidad e inclusive personas del área de negocio o cliente del proyecto verifican
el funcionamiento del sistema o funcionalidad.
Pruebas no funcionales
Se define un conjunto de pruebas no funcionales para cada requisito de este tipo. Aquí
se pueden incluir pruebas sobre el desempeño, tiempo de respuesta, mantenibilidad,
Pruebas de seguridad de software, entre otros aspectos, según la clasificación de
requisitos no funcionales que se tenga para el proyecto.
Pruebas de caja blanca
Según la estructura y arquitectura del software que se esté desarrollando.
Pruebas de regresión
Se definen sobre las funcionalidades modificadas en sus componentes internos.
Tipos de pruebas de software en metodologías ágiles
Si estás trabajando con metodologías ágiles, te recomendamos usar como base los 4
cuadrantes del Agile Testing, que define el marco de referencia con todos los tipos de
pruebas que debes considerar.
5.- Definir los criterios de inicio, aceptación y suspensión de pruebas
Criterios de aceptación o rechazo:
Para definir los criterios de aceptación o rechazo, es necesario definir el nivel de
tolerancia a fallos de calidad. Si la tolerancia a fallos es muy baja puede definirse como
criterio de aceptación que el 100% de los casos de prueba estén sin incidencias. Lograr
este margen en todos los casos de prueba principales y casos borde será muy difícil, y
podría comprometer los plazos del proyecto (incrementa los riesgos), pero asegura la
calidad del producto.
Por otra parte, puede ser que la intención sea realizar un Soft Launch, o un mínimo
producto viable, en ese caso se podría definir como criterio de aceptación el 100% de los
casos de prueba principales (considerados clave) y 20% de casos de prueba no
principales (casos borde).
Una vez logradas las condiciones, se darán por aceptadas las pruebas y el desarrollo de
software.
Criterios de inicio o reanudación:
Definen las condiciones que deben cumplirse para dar inicio o reanudar las pruebas. Por
ejemplo, en el caso de inicio la condición podría ser la instalación de los componentes de
software en el ambiente y que los casos de pruebas de verificación de ambiente sean
exitosos.
Para el caso de la reanudación las condiciones están relacionadas, se determina a partir
de cuales criterios de suspensión se presentaron para detener las pruebas. Una vez que
estás condiciones ya no existan (sean solventadas) se procede con la reanudación.
Criterios de suspensión:
Las condiciones van a depender de los acuerdos de nivel de servicio (SLAs) internos de la
organización y también de los acuerdos establecidos en cada proyecto individual.
Por ejemplo, si se tiene un equipo de pruebas que comparte su esfuerzo entre varios
proyectos, se puede definir un criterio de suspensión exigente, un determinado porcentaje
de casos fallidos que resulten en incidencias. Si la condición se cumple, se detienen las
pruebas y se dedica el personal a otras actividades,
Por otra parte si se tiene un equipo de pruebas con personal dedicado, el criterio de
suspensión puede ser poco exigente, por ejemplo solo ocurriendo si se bloquean
por incidencia todos los casos de prueba.
6.- Identificar los entornos (ambientes) requeridos
iStockPhoto / Trout55
Posteriormente se definen y documentan las características de los entornos de Hardware
y Software necesarios para realizar la ejecución de las pruebas de software.
Esta información se obtiene a partir del equipo de desarrollo y de los arquitectos de
software, quienes pueden suministrar los requisitos mínimos y óptimos para la operación
del sistema.
Como mejor práctica, el ambiente de pruebas de software debería ser lo más similar
posible al ambiente de producción, sin embargo, no siempre es posible debido a
limitaciones de recursos (financieros). En estos casos debe estudiarse cuales son los
requisitos que aseguran un mínimo de confiabilidad de estas pruebas respecto al entorno
de producción.
Además en esta sección del plan de pruebas, también se definen los requisitos de
sistemas operativos, software y herramientas de las estaciones de trabajo de los Testers.
Si el alcance del proyecto incluye pruebas de aplicaciones (Apps) para móviles, es
necesario definir los emuladores y teléfonos inteligentes, con sus respectivos requisitos.
También deben definirse los requisitos de harware y software para los siguientes
componentes:
• Herramienta de gestión de calidad de software.
• Herramientas para automatización de pruebas.
• Herramientas de BDD, TDD y Testing de Web Services).
7.- Determinar necesidades de personal y entrenamiento
Debe completarse previamente la estimación del esfuerzo de pruebas a partir del diseño
de casos de prueba.
Si aún no se cuenta con la estimación, se puede comenzar por definir los tipos de perfiles
de habilidades y conocimientos en Software Testing que se necesitan.
Para ello se puede buscar la respuesta a las siguientes preguntas:
¿Qué conocimientos de procesos de negocio se necesitan?
¿Qué sistemas se están probando y quienes tienen experiencia en su funcionamiento?
¿Se necesitan conocimientos específicos en pruebas de requisitos no funcionales? Por
ejemplo para pruebas de desempeño o estrés.
¿Cual herramientas de gestión de calidad de software se va a utilizar?
¿Se necesitan conocimientos en herramientas técnicas como Lenguajes de
programación o herramientas de pruebas de webservices?
¿Se necesitan conocimientos en herramientas de pruebas automatizadas?
Requisitos de entrenamiento
Por ejemplo:
• Transferencia de conocimientos en el sistema y su operación con el área
de negocio.
• Formación en metodologías de pruebas de software.
• Entrenamiento en tipos de pruebas especializados (desempeño, estrés,
arquitectura, caja blanca).
• Formación en automatización de pruebas de software.
8.- Establecer la metodología y procedimientos de prueba
La metodología de pruebas de software dependerá de la que se esté utilizando para la
gestión del proyecto.
Si se está utilizando una metodología predictiva, las pruebas de software comenzaran con
la estimación del esfuerzo de pruebas, diseño y luego la ejecución de las pruebas, como
te lo contamos en el artículo de Pruebas de calidad de software en 10 pasos.
Si se están utilizando metodologías ágiles de desarrollo de software, debes considerar
las diferencias de las pruebas ágiles de software respecto al enfoque predictivo, por lo
que la metodología debe estar alineada con el manifiesto ágil.
En nuestra serie de artículos de Agile Testing te contamos más al respecto.
Luego se seleccionar la metodología de referencia, se documentan los procedimientos
para diseño y ejecución, siguiendo el orden de los pasos definidos, flujos de procesos,
condiciones para tomar decisiones, y demás aspectos.
9.- Elaborar la planificación de las pruebas
iStockPhoto / appleuzr
La planificación de las pruebas abarca:
Matriz de responsabilidades
Puede usarse una Matriz RACI Una matriz RACI, también conocida como la matriz de
responsabilidades, es un cuadro que muestra el personal asignado a cada paquete de
trabajo o actividad en un proyecto. Se utiliza para identificar las relaciones entre los
integrantes del equipo de proyecto y las actividades (o paquetes de trabajo), del plan.
(Fuente: La guía del PMBOK).
Las siglas de la matriz de responsabilidades RACI, significan "Responsable, Aprobador,
Consultado e Informado", en las filas de esta se identifica cada actividad de proyecto y en
las columnas encabezado los integrantes del equipo (por nombre y apellido). Luego, en
cada cuadro de la matriz se identifica el tipo de relación entre cuatro posibles tipos: R:
Responsable, A: Aprobador, C: Consultado, I: Informado. o Matriz RAM La matriz de
responsabilidades básica es la RAM (Responsibility Assigment Matrix), la cual enumera
los Paquetes de Trabajo de la EDT (WBS) y establece referencia cruzada con cada
integrante del equipo, el tipo de relación puede ser P: Responsabilidad Primaria
o S: Responsabilidad Secundaria. como plantilla. Esta se define con perfiles genéricos o
inclusive con el equipo de trabajo si ya se conoce cuál es el que será asignado.
Las tareas del plan de pruebas deben estar alineadas con las habilidades y conocimientos
de cada persona.
Cronograma
Elaborado a partir de la estimación de las actividades de Software Testing realizada por
el equipo.
Para elaborar un cronograma real, es importante definir actividades críticas como por
ejemplo los tiempos de instalación de versiones en los entornos de pruebas, pruebas de
validación de ambientes antes de comenzar a hacer las pruebas y las iteraciones por
incidencias, que es el tiempo invertido en volver a probar los casos de prueba fallidos.
Premisas
Son las condiciones que deben cumplirse para que el cronograma sea realizable, estas se
determinan a partir de la documentación de entornos y de los requisitos de personal. Por
ejemplo disponibilidad de ciertos entornos, disponibilidad de personal con algún
conocimiento técnico especifico, la metodología que se va a utilizar, premias que deben
cumplirse para poder aplicarla, entre otros.
10.- Identificar los riesgos y definir planes de respuesta
La gestión de riesgos en pruebas es muy similar a la gestión de riesgos en proyectos de
la que hemos escrito en artículos como Las 5 preguntas y respuestas sobre la
identificación de riesgos, así como el artículo sobre Cómo hacer seguimiento de los
riesgos del proyecto.
Para el Software Testing, los riesgos por lo general están vinculados con factores como:
• Posibles dificultades en la disponibilidad de entornos.
• Pruebas que dependen de factores externos al proyecto y la organización.
• Disponibilidad de personal con conocimientos especializados en alguna
herramienta, o en la funcionalidad especifica que se está desarrollando.
• Dependencias con otros proyectos.
• Posibilidad que alguna premisa no se cumpla.
Para identificar los riesgos es necesario enumerar cada una de estas dependencias y por
medio de mesas de trabajo y tormentas de ideas pensar en las posibilidades de que algo
salga mal (u oportunidades para que salga bien).
Luego de la identificación, es necesario también definir planes de respuesta, los cuales
deben ser específicos para cada situación particular y riesgo.
DISEÑO DE CASOS DE PRUEBA
Durante la fase de análisis de pruebas de un proyecto de desarrollo de software, el
principal producto que se elabora es la especificación de diseño de casos de pruebas y
sus respectivos datos de entrada, los cuales serán utilizados para evaluar la calidad del
software y determinar si este cumple con los requisitos del software solicitados por el
usuario.
Para elaborar el diseño de casos de prueba, el equipo de pruebas puede valerse de una
plantilla de casos de prueba, la cual se las presentamos a continuación, como parte de la
colección de plantillas que ofrecemos en PMOInformatica.com
Un diseño de casos de prueba bien elaborado debe especificar el área funcional sujeta de
pruebas, la Funcionalidad que se está probando, el título y descripción del caso de
prueba, los datos y acciones de entrada, resultados esperados (salidas), requerimientos
específicos del ambiente de pruebas o de procedimiento, así como información para el
seguimiento como el estatus actual, última fecha de cambio de estado y observaciones.
documento empleado: plantilla diseño casos de prueba
INFORME DE EJECUCIÓN DE PRUEBAS
Cuando ejecutamos proyectos de desarrollo de software, la fase de pruebas (Software
Testing) suele ser crítica, y es un momento en el cual diversos interesados
(stakeholders) requieren información al minuto sobre el estado de la calidad del software
que se está desarrollando.
Para ello, se suele manejar un informe de avance de cómo van las pruebas, el cual según
la criticidad del proyecto puede ser solicitado una o varias veces al día.
La intención es comunicar a todos los involucrados de las áreas de pruebas, desarrollo,
funcionales y área de negocio cual es la situación de las pruebas, que defectos críticos se
están reportando y cuantos casos faltan por ejecutar.
Aquí les compartimos un modelo de informe de ejecución de pruebas de software, con el
cual podrás comunicar la información más relevante del avance del plan de pruebas,
como por ejemplo cuantos casos de prueba están con estatus exitoso, cual es la relación
entre el porcentaje de avance planificado y el real, cual es la situación de los defectos en
cuanto a cuantos están abiertos, han sido corregidos o no aplican, entre otros aspectos.
documento empleado: planilla informe modelo pruebas de software
