Plantilla del plan de pruebas de software

Imagen de: pmoinformatica.com

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.

PMOInformatica.com, “La Oficina de Proyectos de Informática”, presenta la Plantilla para el plan de pruebas de software:

>> Descargar la plantilla de plan de pruebas de software

¿Cómo elaborar el plan de pruebas de software?

¿Interesado en un método para levantar la información y elaborar el plan de pruebas de software?, sigue el enlace:

> Pruebas de software: 10 pasos para elaborar el plan de pruebas

Información sobre Software Testing

> Visita nuestra página de Recursos en Pruebas de Software

Formación en QA Testing

Curso QA Testing: Guía Básica para QA y Robot Framework

Todo lo que necesitas saber sobre pruebas de software y además a como automatizar tus pruebas usando Robot Framework.

Secciones de la plantilla de plan de pruebas de software

• Historial de versiones: El histórico de las versiones del plan de pruebas de software, indicando quien elaboró la versión y la fecha.

• 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.

• Aprobaciones: Lista de las personas que deben aprobar el plan de pruebas de software, indicando su nombre, cargo, departamento y espacio para su firma.

• 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.

• 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.

• Nuevas funcionalidades a 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.

• 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.

• 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.

• 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.

En caso que se esté elaborando el plan de pruebas para aplicaciones móviles web, nativas o híbridas, es importante considerar en el enfoque los Tipos de pruebas de aplicaciones para móviles.

La definición clásica divide las pruebas de software en dos grandes tipos, las de caja negra y las de caja blanca. Aquí te compartimos artículos sobre las pruebas de caja negra:

> Pruebas de caja negra según el ISTQB

> Pruebas de caja negra: Ejemplos

> Pruebas de aceptación de software según el ISTQB

Entre las pruebas no funcionales y desempeño que se pueden realizar, existen las que se aplican sobre servicios web, usando herramientas como SoapUI. Aquí te dejamos un enlace:

> 5 Herramientas de testing de servicios web

> Tutorial de SoapUI en español - Proyecto de ejemplo

En la sección de alcance y enfoque de pruebas también se puede describir la metodología de pruebas utilizada, por ejemplo si se esta aplicando el Agile Software Testing.

Cuando se está trabajando con metodologías ágiles, pueden usarse los 4 cuadrantes del Agile Testing para identificar los tipos de pruebas a realizar.

Antes de comenzar a documentar el enfoque de Agile Testing, debes considerar las diferencias de las pruebas ágiles de software respecto a los enfoques tradicionales.

A continuación describimos las partes de la plantilla relacionadas con la ejecución de las pruebas. ¿Buscas un modelo de informe de ejecución de pruebas?, sígue el siguiente enlace:

> Modelo de informe de ejecución de pruebas de software

Continuación de la descripción de la plantilla

• 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. 

• 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.

• 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.

• 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.

• 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.

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

¿y tú?, ¿Qué opinas?

¿En tu organización se utiliza el Plan de Pruebas de Software?, o ¿sólo utilizas el diseño de casos de prueba?, ¿Qué información registras en tu plan de pruebas? Te invitamos a dejarnos comentarios en la Web de La Oficina de Proyectos de Informática (pmoinformatica) (Si lo deseas, puedes firmar tu comentario con la dirección de tu web).

¿Buscas más información de gerencia informática?

¿Quieres obtener completamente gratis y directamente en tu correo electrónico plantillas, artículos y otros recursos de gerencia informática?, entonces presiona "suscríbete" a continuación.

Suscríbete a la lista de correo electrónico:


Vía FeedBurner, se abrirá una nueva ventana

También puedes seguirnos vía Twitter, Facebook o Linkedin:

  

Artículos relacionados