Riesgos del proyecto

Acabamos de discutir el uso de pruebas para gestionar los riesgos para la calidad del producto.

Sin embargo, la prueba es una actividad igual que el resto del proyecto y por lo tanto está sujeta a los riesgos que ponen en peligro el proyecto. Para hacer frente a los riesgos de los proyectos que se aplican a las pruebas, podemos utilizar los mismos conceptos que aplicamos a identificar, priorizar y la gestión de riesgos de los productos.

Recordando que un riesgo es la posibilidad de un resultado negativo, los riesgos del proyecto afectan a la prueba, Existen riesgos directos tales como la demora en la entrega de elementos de prueba al equipo de pruebas o problemas de disponibilidad con el entorno de prueba. Ahí son también riesgos indirectos, tales como retrasos excesivos en la reparación de los defectos que se encuentran en prueba o problemas con la obtención de apoyo para la administración profesional del sistema el entorno de prueba.

Por supuesto, estos no son más que cuatro ejemplos de los riesgos del proyecto; muchos otros pueden aplicar a su esfuerzo de pruebas. Para descubrir estos riesgos, hágase y hacemos a otros participantes en el proyecto y las partes interesadas algunas preguntas, ¿lo que podría ir mal en el proyecto de retrasar o invalidar el plan de pruebas, la estrategia de prueba y la estimación de prueba? ¿Qué son inaceptables los resultados de las pruebas o en las pruebas? ¿Cuáles son las probabilidades y el impacto de cada uno de estos riesgos? ' Se puede ver que este proceso es mucho al igual que el proceso de análisis de riesgos de los productos. Listas de control y ejemplos pueden ayudarle a identificar los riesgos del proyecto de prueba [Black, 2004].

Para cualquier riesgo, producto o proyecto, tiene cuatro opciones típicas:

• Mitigar: Tomar medidas con antelación para reducir la probabilidad (y posiblemente el impacto) del riesgo.

• Contingencia: Tener un plan en marcha para reducir el impacto debería tener el riesgo convertido en un resultado.

• Transferencia: Convencer a algún otro miembro del equipo de proyecto o de las partes interesadas para reducir la probabilidad o aceptar el impacto del riesgo.

• Ignorar: No hacer nada acerca del riesgo, que es por lo general sólo una opción inteligente cuando hay poco que se puede hacer o cuando la probabilidad y el impacto son bajo.

Hay otra opción típica de gestión de riesgos, la compra de seguros, que no suele ser usado por proyecto o en productos de proyectos de software, aunque no es desconocido. Aquí hay algunos riesgos típicos, junto con algunas opciones para la gestión de los mismos.

• Logística o problemas de calidad del producto que bloquean las pruebas: Estos pueden ser mitigados mediante una planificación cuidadosa, buena clasificación y gestión de defectos, y diseño de una prueba robusta.

• Los elementos de prueba que no se instalará en el entorno de prueba: Estos pueden ser mitigados a través del humo (o aceptación) pruebas antes de iniciar las fases de prueba o como parte de un nightly build (construcción nocturna) o la integración continua. Tener un proceso definido de desinstalación, es un buen plan de contingencia.

actualizaciones para poner a prueba los casos, resultados esperados y ambientes: Estos pueden ser mitigado través de buenos procesos de control de cambios, el diseño de pruebas robusta y ligera documentación de prueba de peso. Cuando se producen incidentes graves, la transferencia del riesgo por la progresividad de gestión a menudo está en orden.

• Entornos de pruebas insuficientes o poco realistas que dan resultados engañosos: Una opción es la transferencia de los riesgos para la gestión, explicando los límites de Los resultados que fueron obtenidos en entornos limitados. Mitigación, a veces completa el alivio, se puede lograr por medio de pruebas de externalización tales como el rendimiento pruebas que son particularmente sensibles a los entornos de prueba apropiados.

Aquí hay algunos riesgos adicionales a tener en cuenta y tal vez para gestionar:

• Cuestiones de organización tales como la escasez de personas, habilidades o entrenamiento, problemas con la comunicación y responder a probar los resultados, mala expectativa de lo que puede lograr la prueba y la complejidad del equipo de proyecto u organización.

• Proveer cuestiones tales como problemas con las plataformas de hardware o subyacentes, las no consideraciones de problemas de pruebas en el contrato o no ajustar correctamente las respuestas a los problemas que puedan surgir.

• Los problemas técnicos relacionados con la ambigua, contradictoria o sin prioridades de requisitos, un número excesivamente grande de los requisitos dados, otra las limitaciones del proyecto, la complejidad y los problemas de alta calidad con el diseño del sistema, el código o las pruebas.

Puede haber otros riesgos que se aplican a su proyecto y no todos los proyectos son sujetos a los mismos riesgos. Véase el Capítulo 2 de [Negro, 2001], los capítulos 6 y 7 de la [Negro, 2004] y en el Capítulo 3 de [Craig, 2002] para una discusión sobre la gestión los riesgos del proyecto durante la prueba y en el plan de pruebas.

Por último, no se olvide de que los elementos de prueba también pueden tener riesgos asociados con ellos.

Por ejemplo, hay un riesgo de que el plan de prueba omitirá pruebas para un área funcional o que los casos de prueba no ejercen las áreas críticas del sistema.