Por lo general muchos de los principios de las pruebas de software parecer obvio, pero en realidad sabemos que son muy útiles en el momento de la prueba, que crea una barrera de la conciencia en el tester, que se hará más crítico en el desarrollo de casos de prueba y al ejecutar la prueba.
Principio 1: Una parte importante de una definición de caso de prueba es un resultado esperado.
Si el resultado esperado no se hay definición previa, los resultados con error pueden ser considerados correctos. Debido al fenómeno de que "los ojos ven lo que quieren ver." Hay un deseo inconsciente de ver el resultado correcto. Una manera de probar esto es hacer un análisis detallado de todos los puntos de venta en busca de un hechizo perfecto, antes de comprobar los resultados esperados por el programa.
Principio 2: Un programador debe evitar tratar de probar su propio programa.
Por lo general, una persona no le gusta encontrar errores en su propio trabajo o el programa. Si el programador ha cometido un error cuando hizo el código, es natural que no debe encontrar este error en el momento de la prueba. Pero en el caso de depura la realización es más eficiente cuando se hace por el programador.
Principio 3: Los casos de prueba no deben ser grandes y exhaustivos.
Un buen plan de pruebas tiene casos de prueba que son ejecutados fácilmente por el tester, que no se ejecutan de una manera ambigua. Para ello, los casos de prueba tienen que estar bien escrito y objetivo, pero también debe tener la menor cantidad de pasos.
Principio 4: Analizar a fondo los resultados de cada prueba.
Es la gente normal no detectar ciertos errores, incluso cuando estos errores pueden ser claramente observados en uno checklist o plan de prueba.
Principio 5: Los casos de prueba deben ser escritos con las entradas que no son válidos y inesperados, así como entradas válidas y esperadas.
Principio 6: Examinar un programa para ver si hace lo que se propone es sólo la mitad de la batalla, la otra mitad es comprobar si el programa hace lo que se propone.
Este es un corolario del principio anterior. Los programas deben ser probados debido a problemas secundarios indeseables. Por ejemplo, un programa de nómina que realiza pagos bueno es malo cuando se produce la nómina para los empleados que no existen.
Principio 7: Evite los casos de prueba desechables a menos que el programa también está disponible.
Muchas veces, el tester ejecuta los casos de prueba aleatoriamente y cuando se necesita para volver a probar que el programa de nuevo tiene que dedicar tiempo a crear nuevos casos de prueba. Un problema es que por lo general la nueva prueba no es tan rigurosa como la prueba inicial. Por lo tanto, si una nueva característica para provocar un fallo, es probable que no serán detectados. Mediante el almacenamiento de los casos de prueba en un documento y volver a correr de nuevo en cada iteración se conoce como prueba de regresión.
Principio 8: Nunca tome una prueba de asumir que no hay errores serán encontrados.
Esto es un error que los diseñadores crear y probar por lo general es un signo de mal uso de la definición de la prueba. La definición correcta es que la prueba es un proceso de ejecución de un programa con la intención de encontrar errores.
Principio 9: La probabilidad de encontrar más errores en una sección de un programa es proporcional a la cantidad de errores que ya se encuentran en esa sección.
A pesar de hacer poco sentido, esto ocurre con más frecuencia. Por ejemplo, un programa consta de dos módulos A y B, donde «A» 5 se han encontrado errores y "B" sólo se encontró un error. La probabilidad de encontrar más errores en la 'A' para una segunda ronda de la prueba es mayor que la probabilidad de encontrar más errores en el 'B', porque, como en 'A' tuvo más errores que en el 'B' para corregir los errores " A ', existe la posibilidad de nuevos errores. Otra hipótesis es que los errores ocurren en grupos, es decir, un error desencadena otro, y también algunos sectores son más propensos a los errores que otros.
Principio 10: Hacer prueba es una actividad muy creativa y intelectualmente desafiante.
Es probablemente cierto que la creatividad necesaria para poner a prueba un programa de grandes es mayor que la creatividad necesaria para crear ese programa. Sabemos que es imposible tener 100% de los errores. Hay muchos métodos para crear casos de prueba, pero estos métodos todavía necesita mucha creatividad.
Por lo tanto, al analizar todos los principios que podemos extraer de los tres principios fundamentales que son:
- La prueba es un proceso de ejecución de un programa con la intención de encontrar errores.
- Una buena prueba es la que tiene una alta probabilidad de encontrar un error desconocido.
- Un caso de prueba excelente es el que encuentra un error no se descubre.
Referencia:
MYERS, G. J. Las Artes de pruebas de software - 2da. ed. John Wiley & Sons, Inc., EE.UU., 2004, cap. 2 pag. 14-20.
Redes Sociales