Ingenieria en Softwarekali linux

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.

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.

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.

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

>> Descargar el Modelo de estudio de factibilidad de un proyecto

Joan Manuel Gregorio Pérez

Ingeniero en software, Magister Gestión de la Tecnología Educativa, amante de la tecnología y videojuegos, docente, padre y gamers

Publicaciones relacionadas

Botón volver arriba