Estrategia de pruebas de software
Revisión del 09:52 9 ene 2014 de Yalexy idict (discusión | contribuciones) (→Los objetivos de la estrategia de prueba son:)
| ||||||
Una estrategia para pruebas de software integra las técnicas de diseño de casos de prueba en una serie de pasos bien planificados que llevan a la evaluación correcta del software.
Sumario
Las características generales son:
- La prueba comienza en el nivel de módulo y trabaja hacia afuera.
- En diferentes puntos son adecuadas a la vez distintas técnicas de prueba.
- La prueba y la depuración son actividades diferentes.
La estrategia define:
- Técnicas de pruebas (manual o automática) y herramientas a ser usadas.
- Qué criterios de éxito y culminación de la prueba serán usados.
- Consideraciones especiales afectadas por requerimientos de recursos o que tengan implicaciones en la planificación.
Los objetivos de la estrategia de prueba son:
- Planificar las pruebas necesarias en cada iteración, incluyendo las pruebas de unidad, integración y las pruebas de sistema. Las pruebas de unidad y de integración son necesarias dentro de la iteración, mientras que las pruebas de sistema son necesarias sólo al final de la iteración.
- Diseñar e implementar las pruebas creando los casos de prueba que especifican qué probar, cómo realizar las pruebas y creando, si es posible, componentes de prueba ejecutables para automatizar las pruebas.
- Realizar diferentes pruebas y manejar los resultados de cada prueba sistemáticamente. Los productos de desarrollo de software en los que se detectan defectos son probados de nuevo y posiblemente devueltos a otra etapa, como diseño o implementación, de forma que los defectos puedan ser arreglados.
Con la realización de una correcta guía para el probador de software o estrategia de pruebas se debe proceder a examinar el software para lo que es necesario algunas recomendaciones de suma importancia.
Recomendaciones para unas pruebas exitosas
- Cada caso de prueba debe definir el resultado de salida esperado que se comparará con el realmente obtenido.
- El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas.
- Se debe inspeccionar a conciencia el resultado de cada prueba, para así, poder descubrir posibles síntomas de defectos.
- Al generar casos de prueba, se deben incluir tanto datos de entrada válidos como no válidos.
- Las pruebas deben centrarse en dos objetivos: probar si el software no hace lo que debe hacer o viceversa, es decir, si provoca efectos secundarios adversos
- No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas siempre hay defectos.
- La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto.
- Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.
