- Comparar con el plan de prueba
Una estrategia de prueba es un esquema que describe el enfoque de prueba del ciclo de desarrollo de software.. El propósito de una estrategia de prueba es proporcionar una deducción racional de los objetivos organizacionales de alto nivel a las actividades de prueba reales para cumplir con esos objetivos desde una perspectiva de aseguramiento de la calidad. La creación y documentación de una estrategia de prueba debe realizarse de manera sistemática para garantizar que todos los objetivos estén completamente cubiertos y comprendidos por todas las partes interesadas. También debe revisarse, cuestionarse y actualizarse con frecuencia a medida que la organización y el producto evolucionan con el tiempo. Además, una estrategia de prueba también debe apuntar a alinear a las diferentes partes interesadas del aseguramiento de la calidad en términos de terminología, niveles de prueba e integración, roles y responsabilidades, trazabilidad, planificación de recursos, etc.
Las estrategias de prueba describen cómo se mitigan los riesgos del producto de las partes interesadas a nivel de prueba, qué tipos de pruebas se realizarán y qué criterios de entrada y salida se aplican. Se crean basándose en documentos de diseño de desarrollo. Los documentos de diseño del sistema se utilizan principalmente y, en ocasiones, se puede hacer referencia a los documentos de diseño conceptual. Los documentos de diseño describen la funcionalidad del software que se habilitará en la próxima versión . Para cada etapa del diseño de desarrollo, se debe crear una estrategia de prueba correspondiente para probar los nuevos conjuntos de características.
Niveles de prueba
La estrategia de prueba describe el nivel de prueba a realizar. Hay principalmente tres niveles de prueba: prueba unitaria , prueba de integración y prueba del sistema . En la mayoría de las organizaciones de desarrollo de software, los desarrolladores son responsables de las pruebas unitarias. Los probadores individuales o los equipos de prueba son responsables de la integración y las pruebas del sistema.
Funciones y responsabilidades
Los roles y responsabilidades del líder de la prueba, los evaluadores individuales y el gerente de proyecto deben definirse claramente a nivel de proyecto en esta sección. Puede que no tenga nombres asociados, pero el rol debe estar definido con mucha claridad.
Los desarrolladores deben revisar las estrategias de prueba. También deben ser revisados por conductores de prueba para todos los niveles de prueba para asegurarse de que la cobertura sea completa, pero que no se superponga. Tanto el gerente de pruebas como los gerentes de desarrollo deben aprobar la estrategia de prueba antes de que pueda comenzar la prueba.
Requisitos ambientales
Los requisitos ambientales son una parte importante de la estrategia de prueba. Describe qué sistemas operativos se utilizan para las pruebas. También informa claramente los niveles de parches del sistema operativo necesarios y las actualizaciones de seguridad requeridas. Por ejemplo, un determinado plan de prueba puede requerir la instalación de Windows 8.1 como requisito previo para la prueba.
Herramientas de prueba
Hay dos métodos utilizados para ejecutar casos de prueba: manual y automatizado . Dependiendo de la naturaleza de las pruebas, suele darse el caso de que una combinación de pruebas manuales y automatizadas sea el mejor método de prueba.
Riesgos y mitigación
Cualquier riesgo que afecte el proceso de prueba debe enumerarse junto con la mitigación. Al documentar un riesgo, se puede anticipar su ocurrencia con mucha anticipación. Se pueden tomar medidas proactivas para evitar que ocurra o para mitigar su daño. Los riesgos de la muestra son la dependencia de la finalización de la codificación realizada por los subcontratistas o la capacidad de las herramientas de prueba.
Calendario de pruebas
Un plan de prueba debe hacer una estimación de cuánto tiempo llevará completar la fase de prueba. Hay muchos requisitos para completar las fases de prueba. Primero, los evaluadores deben ejecutar todos los casos de prueba al menos una vez. Además, si se encuentra un defecto, los desarrolladores deberán solucionar el problema. Los probadores deben volver a probar el caso de prueba fallido hasta que funcione correctamente. Por último, pero no menos importante, el evaluador debe realizar pruebas de regresión hacia el final del ciclo para asegurarse de que los desarrolladores no rompan accidentalmente partes del software mientras reparan otra parte. Esto puede ocurrir en casos de prueba que anteriormente funcionaban correctamente.
El programa de pruebas también debe documentar la cantidad de probadores disponibles para realizar pruebas. Si es posible, asigne casos de prueba a cada evaluador.
A menudo es difícil hacer una estimación precisa del programa de prueba, ya que la fase de prueba implica muchas incertidumbres. Los planificadores deben tener en cuenta el tiempo adicional necesario para adaptarse a los problemas contingentes. Una forma de hacer esta aproximación es observar el tiempo que necesitan las versiones anteriores del software. Si el software es nuevo, una buena forma de comenzar es multiplicar la aproximación del programa de pruebas inicial por dos.
Enfoque de prueba de regresión
Cuando se identifica un problema en particular, los programas se depuran y la solución se aplica al programa. Para asegurarse de que la solución funcione, el programa se probará nuevamente para ese criterio. Las pruebas de regresión reducirán la probabilidad de que una corrección cree otros problemas en ese programa o en cualquier otra interfaz. Por lo tanto, es posible que deba repetirse nuevamente un conjunto de casos de prueba relacionados para probar si algo más se ve afectado por una solución en particular. En esta sección se debe detallar cómo se va a llevar a cabo.
Considere diferentes niveles de prueba al seleccionar casos de prueba de regresión. Los casos de prueba de unidad, integración y sistema son buenos candidatos. Seleccione casos que tengan una relación directa con la solución y que también incluyan algunos casos críticos de negocio que demuestren que los escenarios empresariales básicos aún funcionan. Recuerde también que las pruebas no funcionales (seguridad, rendimiento, usabilidad) juegan un papel importante para demostrar la continuidad del negocio.
En algunas empresas, siempre que haya una solución en una unidad, se repetirán todos los casos de prueba de unidad para esa unidad.
Grupos de prueba
De la lista de requisitos, podemos identificar áreas relacionadas, cuya funcionalidad es similar. Estas áreas son los grupos de prueba. Por ejemplo, en un sistema de reserva de trenes , todo lo relacionado con la reserva de billetes es un grupo funcional; todo lo relacionado con la generación de informes es un grupo funcional. De la misma manera, tenemos que identificar los grupos de prueba en función del aspecto de funcionalidad.
Prioridades de prueba
Entre los casos de prueba, necesitamos establecer prioridades. Al probar proyectos de software, ciertos casos de prueba se tratarán como los más importantes y, si fallan, el producto no se puede lanzar. Algunos otros casos de prueba pueden ser de menor importancia funcional, o incluso cosmética, y si fallan, podemos lanzar el producto sin comprometer mucho la funcionalidad. Estos niveles de prioridad deben indicarse claramente. Estos también se pueden asignar a los grupos de prueba.
Probar recopilaciones e informes de estado
Cuando se ejecutan los casos de prueba, el líder de la prueba y el gerente del proyecto deben saber dónde se encuentra exactamente el proyecto en términos de actividades de prueba. Para saber dónde se encuentra el proyecto, las aportaciones de los probadores individuales deben llegar al líder de la prueba. Esto incluirá qué casos de prueba se ejecutan, cuánto tiempo tomó, cuántos casos de prueba pasaron, cuántos fallaron y cuántos no son ejecutables. Además, debe indicarse claramente la frecuencia con la que el proyecto recopila el estado. Algunos proyectos tendrán la práctica de recopilar el estado de forma diaria o semanal.
Mantenimiento de registros de prueba
Cuando se ejecutan los casos de prueba, es importante realizar un seguimiento de los detalles de la ejecución, como cuándo se ejecutó, quién lo hizo, cuánto tiempo tomó, cuál es el resultado, etc. Estos datos deben estar disponibles para el líder de la prueba y el gerente de proyecto, junto con todos los miembros del equipo, en una ubicación central. Esto puede almacenarse en un directorio específico en un servidor central y el documento debe decir claramente sobre las ubicaciones y los directorios. También se debe mencionar la convención de nomenclatura para los documentos y archivos.
Requerimientos de trazabilidad matriz
Idealmente, el software debe satisfacer completamente el conjunto de requisitos. Desde el diseño, cada requisito debe abordarse en cada uno de los documentos del proceso de software. Los documentos incluyen HLD, LLD, códigos fuente, casos de prueba unitaria, casos de prueba de integración y casos de prueba del sistema. En una matriz de trazabilidad de requisitos , las filas tendrán los requisitos. Las columnas representan cada documento. Las celdas que se cruzan se marcan cuando un documento aborda un requisito particular con información relacionada con el ID del requisito en el documento. Idealmente, si todos los requisitos se abordan en cada documento, todas las celdas individuales tienen identificadores de sección o nombres válidos completados, entonces sabemos que se abordan todos los requisitos. Si alguna celda está vacía, significa que un requisito no se ha abordado correctamente.
Resumen de la prueba
Es posible que la alta dirección desee tener un resumen de la prueba semanal o mensual. Si el proyecto es muy crítico, es posible que lo necesiten incluso a diario. Esta sección debe abordar qué tipo de informes resumidos de prueba se producirán para la alta dirección junto con la frecuencia.
La estrategia de prueba debe dar una visión clara de lo que hará el equipo de prueba para todo el proyecto durante toda la duración. Este documento se puede presentar al cliente, si es necesario. La persona que prepara este documento debe ser funcionalmente fuerte en el dominio del producto, con muy buena experiencia, ya que este es el documento que va a impulsar a todo el equipo para las actividades de prueba. La estrategia de prueba debe explicarse claramente a los miembros del equipo de prueba desde el comienzo del proyecto.
Ver también
Referencias
- Ammann, Paul y Offutt, Jeff. Introducción a las pruebas de software. Nueva York: Cambridge University Press, 2008
- Bach, James (1999). "Estrategia de prueba" (PDF) . Consultado el 31 de octubre de 2011 .
- Dasso, Arístides. Verificación, validación y pruebas en ingeniería de software. Hershey, PA: Idea Group Pub., 2007