Una estrategia de pruebas es un esquema que describe el enfoque de pruebas del ciclo de desarrollo de software . El propósito de una estrategia de pruebas es proporcionar una deducción racional de los objetivos organizacionales de alto nivel a las actividades de prueba reales para cumplir esos objetivos desde una perspectiva de garantía de calidad. La creación y documentación de una estrategia de pruebas 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 pruebas también debe apuntar a alinear a las diferentes partes interesadas de la garantía de 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 en el nivel de prueba, qué tipos de pruebas se deben realizar y qué criterios de entrada y salida se aplican. Se crean en función de los documentos de diseño de desarrollo. Se utilizan principalmente documentos de diseño del sistema y, ocasionalmente, se puede hacer referencia a 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 funciones.
La estrategia de prueba describe el nivel de prueba que se realizará. Existen principalmente tres niveles de prueba: pruebas unitarias , pruebas de integración y pruebas del sistema . En la mayoría de las organizaciones de desarrollo de software, los desarrolladores son responsables de las pruebas unitarias. Los evaluadores individuales o los equipos de prueba son responsables de las pruebas de integración y del sistema.
En esta sección, las funciones y responsabilidades del líder de pruebas, los evaluadores individuales y el gerente de proyectos deben definirse claramente a nivel de proyecto. Puede que no haya nombres asociados, pero la función debe definirse con mucha claridad.
Los desarrolladores deben revisar las estrategias de prueba. También deben revisarlas los líderes de todos los niveles de prueba para asegurarse de que la cobertura sea completa, pero sin superposiciones. Tanto el gerente de pruebas como los gerentes de desarrollo deben aprobar la estrategia de prueba antes de que puedan comenzar las pruebas.
Los requisitos del entorno son una parte importante de la estrategia de pruebas. Describen qué sistemas operativos se utilizan para las pruebas. También informan claramente los niveles de parches del sistema operativo y las actualizaciones de seguridad necesarias. Por ejemplo: un determinado plan de pruebas puede requerir la instalación de Windows 8.1 como requisito previo para las pruebas.
Existen dos métodos que se utilizan para ejecutar casos de prueba: manual y automático . Según la naturaleza de la prueba, suele darse el caso de que una combinación de pruebas manuales y automáticas sea el mejor método de prueba.
Todos los riesgos que afectarán el proceso de prueba deben enumerarse junto con las medidas de mitigación. Al documentar un riesgo, se puede anticipar su ocurrencia con bastante anticipación. Se pueden tomar medidas proactivas para evitar que ocurra o para mitigar sus daños. Algunos ejemplos de riesgos son la dependencia de la finalización de la codificación realizada por subcontratistas o la capacidad de las herramientas de prueba.
Un plan de pruebas debe hacer una estimación de cuánto tiempo tomará completar la fase de prueba. Hay muchos requisitos para completar las fases de prueba. En primer lugar, 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 evaluadores deben volver a probar el caso de prueba fallido hasta que funcione correctamente. Por último, pero no menos importante, los evaluadores deben realizar pruebas de regresión hacia el final del ciclo para asegurarse de que los desarrolladores no rompieron accidentalmente partes del software mientras arreglaban otra parte. Esto puede ocurrir en casos de prueba que funcionaban correctamente anteriormente.
El cronograma de pruebas también debe documentar la cantidad de evaluadores disponibles para realizar las pruebas. Si es posible, asigne casos de prueba a cada evaluador.
A menudo resulta difícil hacer una estimación precisa del cronograma de pruebas, ya que la fase de pruebas implica muchas incertidumbres. Los planificadores deben tener en cuenta el tiempo adicional necesario para dar cabida a cuestiones contingentes. Una forma de hacer esta aproximación es observar el tiempo que necesitaron las versiones anteriores del software. Si el software es nuevo, multiplicar la aproximación del cronograma de pruebas inicial por dos es una buena forma de empezar.
Cuando se identifica un problema en particular, se depuran los programas y se les aplica la solución. Para asegurarse de que la solución funciona, se vuelve a probar el programa para comprobar si cumple con ese criterio. Las pruebas de regresión reducen la probabilidad de que una solución genere otros problemas en ese programa o en cualquier otra interfaz. Por lo tanto, es posible que haya que repetir un conjunto de casos de prueba relacionados para comprobar si una solución en particular afecta a algo más. En esta sección se explicará cómo se llevará a cabo esto.
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 para el negocio que demuestren que los escenarios comerciales básicos aún funcionan. Recuerde también que las pruebas no funcionales (seguridad, rendimiento, usabilidad) desempeñan un papel importante a la hora de demostrar la continuidad del negocio.
En algunas empresas, siempre que hay una solución en una unidad, se repiten todos los casos de prueba unitaria para esa unidad.
A partir 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 reservas 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 la funcionalidad.
Entre los casos de prueba, debemos establecer prioridades. Al probar proyectos de software, ciertos casos de prueba se tratarán como los más importantes y, si fallan, no se podrá lanzar el producto. 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 estar claramente establecidos. Estos también pueden asignarse a los grupos de prueba.
Cuando se ejecutan los casos de prueba, el líder de pruebas y el gerente de proyecto deben saber exactamente en qué punto se encuentra el proyecto en términos de actividades de prueba. Para saber en qué punto se encuentra el proyecto, los comentarios de los evaluadores individuales deben llegar al líder de pruebas. Esto incluirá qué casos de prueba se ejecutaron, cuánto tiempo tomó, cuántos casos de prueba pasaron, cuántos fallaron y cuántos no se pueden ejecutar. Además, se debe indicar claramente con qué frecuencia el proyecto recopila el estado. Algunos proyectos tendrán la práctica de recopilar el estado a diario o semanalmente.
Cuando se ejecutan los casos de prueba, es importante llevar un registro de los detalles de la ejecución, como cuándo se ejecuta, quién lo hizo, cuánto tiempo tardó, 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. Estos datos pueden almacenarse en un directorio específico en un servidor central y el documento debe indicar claramente las ubicaciones y los directorios. También debe mencionarse la convención de nomenclatura para los documentos y archivos.
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 cada requisito se aborda en cada uno de los documentos, todas las celdas individuales tienen identificadores de sección válidos o nombres completos, entonces sabemos que cada requisito se aborda. Si alguna celda está vacía, representa que un requisito no se ha abordado correctamente.
Es posible que a la alta dirección le interese recibir un resumen de las pruebas semanal o mensualmente. Si el proyecto es muy crítico, es posible que lo necesiten incluso a diario. Esta sección debe abordar qué tipo de informes de resumen de pruebas se elaborarán para la alta dirección junto con la frecuencia.
La estrategia de pruebas debe ofrecer una visión clara de lo que hará el equipo de pruebas durante todo el proyecto. Este documento se puede presentar al cliente, si es necesario. La persona que prepare este documento debe tener experiencia en el área del producto, ya que este es el documento que guiará a todo el equipo en las actividades de pruebas. La estrategia de pruebas se debe explicar claramente a los miembros del equipo de pruebas desde el comienzo del proyecto.