Siete Principios de pruebas de software ISEB

Posted by admin on February 11, 2013

ISEB Software Testing cursos de formación de la Fundación introducir a los estudiantes a los fundamentos de las pruebas de software, incluyendo las razones para llevar a cabo las pruebas, los procesos básicos de las pruebas y los principios generales que sustentan las pruebas de buenas prácticas. Conocer estos principios, y comprender cómo afectan al probador de software, es fundamental para pasar la Prueba de Software ISEB examen de Fundamentos.

1. Las pruebas muestran la presencia de insectos

Es decir, las pruebas pueden demostrar que existen problemas, pero no que los problemas no existen.

Este principio se encuentra en el centro de orientación ISEB Software Testing. Un analista de la prueba astuto entiende que incluso si una prueba no revela los fallos, el sujeto de la prueba no es necesariamente libre de errores.

El objetivo principal de llevar a cabo una prueba para detectar defectos. Trabajando bajo la premisa de que cada producto contiene defectos de algún tipo, una prueba que revela los errores es generalmente mejor que uno que no lo hace. Todas las pruebas por lo tanto, deben ser diseñados para revelar los errores de tantos como sea posible.

2. Las pruebas exhaustivas es imposible

Las pruebas exhaustivas alimenta todas las combinaciones posibles de datos en el software, a fin de garantizar que ninguna situación puede surgir, una vez probado el software ha sido puesto en libertad. Excepto en aplicaciones muy simples, el número de combinaciones posibles de datos es prohibitivamente alta, es más eficaz y eficiente de los probadores para centrarse en los riesgos y prioridades, por lo que las pruebas están dirigidas a las necesidades de pruebas.

3. Las primeras pruebas

Un producto (incluidos los documentos, tales como la especificación del producto) se puede probar tan pronto como se ha creado. El software de pruebas de orientación ISEB recomienda probar un producto tan pronto como sea posible, corregir los errores en la orden lo más rápidamente posible. Los estudios han demostrado que los errores identificados al final del proceso de desarrollo por lo general cuestan más para resolver.

Por ejemplo: un error en un pliego de condiciones puede ser bastante sencillo de solucionar. Sin embargo, si ese error se transfiere a la codificación de software, que se fijan a continuación, el error puede ser costoso y consume tiempo.

4. Defecto de la agrupación

Los estudios sugieren que los problemas en un elemento de software tienden a agruparse en torno a un conjunto limitado de módulos o áreas. Una vez que estas áreas han sido identificadas, los administradores eficientes de prueba son capaces de enfocar las pruebas en las zonas sensibles, mientras que siguen buscando a los errores en los módulos de software restantes.

5. El ‘plaguicidas’ paradoja

Al igual que sobre-usado pesticida, un conjunto de pruebas que se utilizan repetidamente en el producto mismo software disminuirá en la eficacia. Usando una variedad de pruebas y técnicas expondrá una serie de defectos a través de las diferentes áreas del producto.

6. La prueba es dependiente del contexto

Las mismas pruebas no se deben aplicar en todos los ámbitos. Distintos productos de software tienen diferentes requisitos, funciones y propósitos. Una prueba diseñada para realizarse en un sitio web, por ejemplo, puede ser menos eficaz cuando se aplica a una aplicación de intranet. Una prueba diseñada para una forma de pago con tarjeta de crédito puede ser innecesariamente rigurosa si se realiza en un foro de discusión.

En general, cuanto mayor es la probabilidad y el impacto de los daños causados ​​por el software fallado, mayor es la inversión en la realización de pruebas de software.

7. La ausencia de errores falacia

Declarando que una prueba se ha descubierto ningún error no es lo mismo que declarar que el software “libre de errores”. Con el fin de garantizar que los procedimientos adecuados de software de prueba se lleva a cabo en todas las situaciones, los evaluadores deben asumir que todo el software contiene algunos (aunque disimulada) faltas.

Resumen

La práctica de pruebas de software bien es un elemento esencial para garantizar la calidad de los productos de TI. Si bien las pruebas de software no puede garantizar que el software no contenga errores, que contribuye significativamente a la identificación y reducción de fallas, mejorar la probabilidad de que la implementación del software tendrá éxito.

Categories: Software

Comments are closed.