Algo de Testing Automatizado

Objetivos del Testing Automatizado

• Tests should improve quality

• Tests should help us understand the system under test

• Tests should reduce risk

• Tests should be easy to run

• Tests should require minimal maintenance as the system evolves

• Tests should be executed as part of the build process if possible

 

Tipos básicos de Testing donde se puede automatizar

• Unit tests

• Customer Test

• GUI Testing

 

Que tener en cuenta para iniciarse en los Procesos Automatizados de Pruebas

¿Cuales son los objetivos de nuestro Testing Automatizado?  Estos deben estar alineados con todos los objetivos de Calidad. Algunos factores que afectarían a nuestros objetivos:

Deseamos automatizar las pruebas regresivas?

Deseamos realizar Integración Continua en nuestro Proceso de Desarrollo?

Estamos buscando resolver un ítem específico de Aseguramiento de Calidad?

Comencemos a Organizarnos

Elegir una estrategia

Escojamos un Tipo Básico de Testing al que nos queremos aproximar con la automatización. Debería ser una combinación de aproximaciones basadas en:

• Objetivos
• Tipo de sistema que queremos Testear:
  • Testabilidad. Definir la capacidad del sistema a soportar automatización de pruebas
  • Nivel de automatización actual. Si la base es cero podría ser el peor escenario
• Podemos modificar el Proceso de Desarrollo y los Requisitos del Sistema para lograr una aproximación al nuevo Ciclo de Vida que exigen las pruebas automatizadas?
• Con solo la automatización de pruebas resolvemos algún problema o debemos tener en cuenta otros ítmes?
• Seleccionemos un tipo de Testing Automatizado: Unitario, Integración , Requerimientos, etc.

Seleccionemos las herramientas basándonos en

• Estrategia seleccionada
• Orientación del Testing Automatizado (Aceptación del Cliente, de Componente, GUI)
• Open Source o Comercial?
• La aplicación seleccionada se adapta a nuestra aplicación o debemos hacer adaptaciones de la aplicación a la herramienta?
• Definamos cuales son nuestros costos

Dos puntos son necesarios para facilitar el mantenimiento

• Definamos las expectativas de la Gestión de las pruebas
• Definamos los estándares o patterns para implementar las pruebas automáticas.

Por ejemplo usemos Palabra Clave como patrón que puede utilizarse para reducir los costos de mantenimiento al utilizar la interfaz de usuario basada en la automatización. Algunos de los enfoques de benefician directamente con el trabajo de control de calidad.

El enfoque que realizamos afectan a las acciones 

• Los desarrolladores serán responsables de crear y mantener las Unidades de Pruebas Automatizadas, aunque puede ayudar a QA y su criterio será fundamental
• SQA puede crear los otros tres tipos de pruebas automatizadas, como siempre lo mejor es integrar directamente en el proceso de desarrollo
• Debemos asegurarnos de que el Testing Automatizado es realmente parte del proceso y se complementa con el Testing No Automatizado

Revisemos el Plan de Pruebas Automatizadas

En todos los casos se debe hacer revisiones de la efectividad del proceso y buscar la forma de mejorarlo. Las siguientes cuestiones podrían ayudarnos:

• Son lentas las automatizaciones?
• Son difíciles de mantener?
• Disminuyen la velocidad del Proceso de Desarrollo?
• Son eficaces en el logro de nuestros objetivos de calidad?

Estas pruebas tienen como principales objetivos comprobar que el código se comporta de la manera esperada y prevenir la aparición de errores inesperados al modificar o refactorizar el código. También, en algunos casos como en el desarrollo dirigido por pruebas, las pruebas unitarias ayudan a obtener el diseño del código. Las ventajas de realizar este tipo de pruebas son: código más depurado, mayor seguridad a la hora de refactorizar y mayor velocidad de desarrollo, aparte de obtener código de mayor calidad asegurando que nada se ha roto cuando cambiamos la lógica interna del software.

Actualmente las pruebas unitarias se desarrollan con herramientas tipo jUnit [3] y objetos mock [4]. Las herramientas tipo jUnit se aplican para comprobar que el estado de un objeto, los valores retornados por los métodos, excepciones lanzadas, etc, son los esperados. Los objetos ficticios o mocks, en cambio, permiten aislar el código a probar de las dependencias con otras clases colaboradoras mediante el desarrollo de clases ficticias que simulan el comportamiento de estas clases colaboradoras. Esto permite centrar la prueba sólo en el código que se desea probar.

Aquí introduzco conceptos de Testing Driven Development (TDD) tomados de un blog amigo WebTrun:

| View | Upload your own