Enfoque estratégico para las pruebas de Software

• Las pruebas comienzan a nivel de modulo y trabajan hacia fuera.  
• Según el momento son apropiadas diferentes técnicas de prueba.
• La prueba la lleva acabo el responsable del desarrollo del SW.
• La prueba y la depuración son actividades diferentes, pero la depuración se debe incluir en cualquier estrategia de prueba.

 

Depuración 

La depuración no es una prueba, pero siempre ocurre como consecuencia de la prueba. El proceso de depuración siempre tiene uno de los dos resultados siguientes:

 

se encuentra la causa, se corrige y se elimina;

o no se encuentra la causa.  

 

En este último caso, la persona que realiza la depuración debe sospechar la causa, diseñar un caso de prueba que ayude a confirmar sus sospechas y el trabajo vuelve hacia atrás a la corrección del error de una forma iterativa. 

 

Durante la depuración encontramos errores que van desde lo ligeramente inesperado (por ejemplo, un formato de salida incorrecto) hasta lo catastrófico (por ejemplo, el sistema falla, produciéndose serios daños económicos o físicos.

 

Pruebas del Software

Las pruebas de software o testing, es el proceso que se ejecuta con el propósito de detectar fallos o anomalías en la aplicación desarrollada. Además se busca también comprobar si el programa cumple con as funciones para las cuales fue diseñado.

La idea fundamental es conocer si realmente se está desarrollando de manera correcta el producto planeado, si se están guardando los parámetros correspondientes. Para realizar dicha comprobación se realizan procesos de verificación con ejecuciones controladas de la aplicación antes de ser entregado al cliente o al usuario final.

http://ciclosoftware.wordpress.com/2010/09/26/pruebas-del-software/

Pruebas Funcionales

Se centran en las funciones, entradas y salidas --> Es impracticable probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba.

Reduce el número de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el máximo número de posibilidades de entrada diferentes para así reducir el total de casos. Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto específico de entradas que prueba, así como de otros conjuntos similares.

Pruebas de Sistema

Al final del desarrollo el software se incorpora a otros elementos del sistema (hardware, personas, información) y se realiza una serie de pruebas de integración del sistema y de validación.

Estas pruebas están más allá del alcance del proceso del software y no las realizan únicamente los ingenieros de software.

Sin embargo, los pasos dados durante el diseño y la prueba del software mejorarán en gran medida la probabilidad de tener éxito en la integración del software del sistema mayor.

Técnicas de Pruebas

Hay dos maneras de probar cualquier producto construido:

1. Si se conoce la función específica para la que se diseño el producto, se aplican pruebas, que demuestren que cada función es plenamente operacional, mientras se buscan los errores de cada función. (Prueba de Caja Negra)

2. Si se conoce el funcionamiento interno del producto, se aplican pruebas para asegurarse de que todas las “piezas encajan”, es decir, que las operaciones internas se realizan de acuerdo a las especificaciones, y que se han probado todos los componentes internos de manera adecuada. (Prueba de Caja Blanca)

• Caja blanca o pruebas estructurales. El conocimiento del diseño interno del software se usa para desarrollar los casos de Pruebas.

• Caja negra o pruebas funcionales. Los casos de prueba son diseñados basadossólo en la especificación externa del software

• Pruebas basadas en escenarios o casos de uso. Actuar como un usuario final y crear escenarios reales para detectar errores.