Plan de Pruebas Y Plantilla de Plan de Pruebas

Pruebas

Las pruebas de software o también conocidas como software testing son aquellas investigaciones empíricas y técnicas cuyo objetivo es proporcionar información objetiva e independiente sobre la calidad del producto a la parte interesada o stakeholder. Donde básicamente las pruebas son un conjunto de actividades dentro del desarrollo de software, estas dependerán del tipo de pruebas como ya lo hemos comentado anteriormente, estas actividades podrán ser implementadas en cualquier momento de dicho proceso de desarrollo.

1. Analizar los requerimientos de desarrollo de software

Para elaborar un plan de pruebas de software lo primero que se debe 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. Se deberá analizar toda la información de la ingeniería de requisito, incluyendo la matriz de trazabilidad, especificaciones y diseño funcional, requisitos funcionales, no funcionales, casos de uso etc. 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. Ademas de las preguntas especificas de cada requisito, es importante hacer preguntas de 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 requisitos y desarrollo, se deben de identificar e incluir en el plan de pruebas de software la lista de las funcionalidades (características) totalmente nuevas. En el caso de desarrollos de software integrados a un sistema existente es necesario que se revise 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 aprobarse

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. 

Se debe de considerar que 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

Consiste básicamente en seleccionar cuáles son los tipos de pruebas de software que se deben realizar. Se recomienda 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.

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

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? 

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. Si se están utilizando metodologías ágiles de desarrollo de software, debe estar alineada con el manifiesto ágil, como te contamos e nuestra serie de artículos de Agile Testing.  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

La planificación de las pruebas abarca:

Matriz de responsabilidades: Puede usarse una Matriz RACI o Matriz RAM 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

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.

Plantilla del plan de pruebas de software

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.


A continuación se presenta un propuesta acerca de una plantilla de plan de pruebas



1. Historial de versiones: El histórico de las versiones del Plan de Pruebas de Software, indicando quien elaboró la versión y la fecha.


2. Ficha del proyecto: Información sobre el nombre del proyecto, departamento o área organizacional, Líder o Gerente del Proyecto, el Patrocinador (Sponsor) y el Gerente o Líder de Pruebas.


3. Aprobaciones: Lista de las personas que deben aprobar el Plan de Pruebas de Software, indicando su nombre, cargo, departamento y espacio para su firma.


4. Resumen ejecutivo: Resumen de todo el contenido del plan de Pruebas de Software, describe cuál es su propósito, establece si es un plan maestro o un plan detallado, identifica el alcance del plan de pruebas en relación con el plan de Proyecto de Software, restricciones (por ejemplo de recursos o presupuesto), alcance del esfuerzo de pruebas entre otros aspectos.


5. Alcance de las pruebas:  Elementos de pruebas: Listado de todos los módulos, componentes o elementos que se van a probar. Si es de alto nivel, se listan las áreas funcionales (módulos o procesos que cubre el Testing), por otro lado, si es de un nivel detallado se listan los programas, unidades o módulos.

6. Nuevas funcionalidades que probar: Es un listado de lo que se va a probar “Desde el Punto de vista del Usuario”. No es una descripción técnica del software sino sus características y funcionalidades. Se incluyen tanto las que son nuevas como las que se están modificando.


7. Pruebas de regresión: Listado de las funcionalidades no directamente involucradas en el desarrollo, pero cuyos componentes están siendo afectados y por ende deben probarse para asegurar que continúan funcionando adecuadamente. Al igual que en el punto anterior, se describen desde el punto de vista del usuario. Las pruebas de regresión son de particular importancia al realizar pruebas nuevamente después que el equipo de desarrollo ha corregido, la omisión de estas pruebas y la no identificación de errores que no han sido corregidos es el error más frecuente cometido en los procesos de seguimiento de incidencias.


8. Funcionalidades a no probar: Listado de las funcionalidades que NO se van a probar. Debe incluir información de las razones por las cuales no se van a probar y los riesgos que se están 

asumiendo.


9. Enfoque de pruebas (Estrategia): La Estrategia de Pruebas puede definirse como un documento aparte, o puede ser incluido dentro del Plan de Pruebas según su extensión. Aquí pueden definirse los tipos de pruebas a realizar (funcionales, de desempeño, de interfaces, pruebas no funcionales, etc.), requerimientos especiales de las pruebas, configuraciones a probar, subconjuntos de datos a considerar, nivel de pruebas de regresión, entre otros aspectos.


10. Criterios de aceptación o rechazo:

• Criterios de aceptación o rechazo: Son los criterios de aceptación que serán considerados para dar por completado el Plan de Pruebas de Software, por ejemplo: Completar 100% de pruebas unitarias, cierto porcentaje de casos exitosos, cobertura de todos los componentes y líneas de código, porcentaje de defectos corregidos, entre otros.

• Criterios de suspensión: Establece claramente bajo qué condiciones se detienen un conjunto de casos de pruebas, por ejemplo en caso de existir defectos que impidan la ejecución de más casos de pruebas, cierto porcentaje de casos fallidos, o cualquier otro que se especifique. 

• Criterios de reanudación: Luego de haber suspendido las pruebas, aquí se establece bajo qué criterios se reanudaran. 

11. Entregables: Establece que se entregará como parte de la ejecución del plan, por ejemplo: Documento de Plan de Pruebas, Casos de Pruebas, Especificación de Diseño de Casos, Logs de errores, Reportes de errores (bugs), evidencias de pruebas, reportes emitidos por herramientas de pruebas y cualquier otro que se establezca.

12. Recursos:

• Requerimientos de entornos – Hardware: Lista de los requerimientos de equipos, hardware y red necesarios para completar las actividades del Plan de Pruebas de Software. Incluye Servidores de Aplicación, Bases de Datos, Equipos de PC que necesitan los Testers, Conectividad a la red (incluyendo accesos), entre otros.

• Requerimientos de entornos – Software: Lista de los requerimientos de software necesarios para completar las actividades de prueba, puede incluir accesos a Sistemas (en entorno de pruebas) y Bases de Datos, así como instalación de software en los Computadores asignados a los Testers.

• Herramientas de pruebas requeridas: Especifica las herramientas de software, metodologías o técnicas especiales empleadas en las pruebas, por ejemplo las herramientas de gestión de casos de pruebas. Adicionalmente, si se está haciendo uso de software de automatización, aquí también se especifican las Herramientas de Automatización de Pruebas.

• Personal: Lista del personal necesario para completar las actividades de pruebas, especificando sus roles, por ejemplo: Un (1) Líder de Pruebas, Cinco (5) Analista de Pruebas (Testers), Dos (2) especialistas en automatización de pruebas, entre otros.

• Entrenamiento: Necesidades de entrenamiento en el Sistema o Aplicación que se está desarrollando, así como en las herramientas de prueba a utilizar.

13. Planificación y Organización:

Procedimientos para las pruebas: Especifica los procedimientos o metodología de pruebas de software a emplear durante la ejecución del plan de pruebas de software.

• Matriz de responsabilidades: Lista cada una de las personas integrantes del equipo de QA y sus responsabilidades. Se puede hacer uso de una Matriz RACI (Responsable, Aprobador, Consultado, Informado).

• Cronograma: Debe estar basado en estimaciones de actividades realizadas por el equipo de prueba. En él se Identifican los hitos relevantes en las pruebas de software, se establecen las dependencias (actividades predecesoras) y demás aspectos componentes de un cronograma.

• Premisas: Las premisas relacionadas con las tareas de pruebas de software, incluyendo limitaciones de tiempo, disponibilidad de recursos que se asumen, uso de una metodología de pruebas, uso de una herramienta, entre otros.

• Dependencias y Riesgos: Aquí se listan los riesgos identificados en el proceso de pruebas de software, por ejemplo, algunas fuentes de riesgos suelen ser:

• Dependencias con Desarrollos.
• Dependencias con otros proyectos.
• Disponibilidad de recursos.
• Restricciones de tiempo.
• Premisas que resulten no ser ciertas.

• Los riesgos se pueden clasificar en función de su probabilidad e impacto, cada uno debe contemplar un plan de mitigación para evitar que ocurra o plan de contingencia cuando el riesgo no puede mitigarse y tiene que aceptarse.

14. Referencias: Lista de todos los documentos que pueden citarse como apoyo o para ampliar el contenido del plan de pruebas. Algunos ejemplos de lo que se puede hacer referencia aquí son:

• Plan de Proyecto.

• Especificaciones de Requerimientos. o Matriz de trazabilidad de requisitos

• Diseño General.

• Diseño Detallado. 

• Procedimientos y estándares de Desarrollo. 

• Procedimientos y estándares de Pruebas. 

• Metodologías, Procedimientos y estándares corporativos.

15. Glosario: Definiciones de términos usados en la documentación, y general sobre el área de pruebas.

Referencias Bibliográficas

choselin. (9 de diciembre de 2012). Slideshare. Obtenido de Plan de Pruebas: https://es.slideshare.net/choselin/plan-de-pruebas-15563690

PMOinformatica. (19 de mayo de 2014). PMOinformatica.com. Obtenido de Plantilla del plan de pruebas de software: http://www.pmoinformatica.com/2014/05/plan-de-pruebas-de-software.html

PMOinformatica. (18 de enero de 2016). PMOinformatica.com. Obtenido de Pruebas de software: 10 pasos para elaborar el plan de pruebas: http://www.pmoinformatica.com/2016/01/elaborar-plan-pruebas-software.html

Ramos, O. (28 de junio de 2012). Slideshare. Obtenido de Plan de pruebas: https://es.slideshare.net/iguamba666/plan-de-pruebas

Rojas, E. (6 de septiembre de 2012). Slideshare. Obtenido de Plan de pruebas de software: https://es.slideshare.net/edgardohrojas/plan-de-pruebas-de-software