Convertirse en un experto en pruebas del software

En esta presentación James Bach habla de las posibilidades a nuestro alcance para pasar de ser un tester experimentado a un verdadero experto.

Cuando alcanzas un determinado grado de experiencia, es dificil encontrar cursos o programas que realmente supongan un avance sobre lo que ya conoces. Entonces, tienes que empezar a gestionar tu formación tu mismo.

Resumen del autor acerca de la presentación:
You're already an experienced tester. You know how to design tests and report bugs. Now what? Do you feel like an expert? Unfortunately, if you want to become very good at testing, there aren't many classes or programs available to help you. This means you must manage your own education. This tutorial is about finding a path from experience to expertise. It's based on the context-driven school of test methodology. It focuses on what it means to think like a tester and how to design and critique testing practices (rather than just copy what the "gurus" tell you to do). You'll also get self- study strategies and methods for developing a colleague network. It's an ideal tutorial if testing is your career and you intend to excel in it.

Leer más...

Novedades para Testing en Microsoft

Microsoft ha dado un paso para facilitar la vida a los equipos de pruebas con el lanzamiento de su Tester Center , una web que pone de relieve que la pruebas son una parte integral del ciclo de vida del desarrollo de aplicaciones.

Además de proporcionar herramientas, se supone que el Tester Center servirá como lugar donde los desarrolladores de software y testers pueden ver vídeos, leer artículos técnicos, e interactuar con testers de Microsoft a través de blogs y foros.

Creo que es una buena vía para incorporar a las proyectos un poco de metodología, técnicas y herramientas de pruebas y mejorar algunas de esas actividades generalmente tan tediosas que nadie quiere hacer.

Los que tengais el ánimo y el interés de utilizar algo de esta web, no dejeis de comentarnos vuestra opinión, para extender su uso si es que vale para algo.

Leer más...

Generación automática de test JUnit gratis

Según una encuesta reciente llevada a cabo por Evans Data para Agitar Software, las pruebas unitarias son una práctica cada vez más frecuente, gracias en gran parte a la aparición y desarrollo de JUnit. El estudio reveló que casi las tres cuartas partes de los desarrolladores de Java en todo el mundo utilizan JUnit, el framework ha sido descargado más de 2 millones de veces y se incluye como un "plug-in" en los principales IDEs.

Entre otras cosas, el estudio reveló que el 87 por ciento de los desarrolladores Java utilizan herramientas de pruebas unitarias y el 71 por ciento son JUnit. También reveló que sólo el 19 por ciento de los desarrolladores de Java han adoptado herramientas de automatización de pruebas unitarias y que las pruebas unitarias se utilizan con más frecuencia en América del Norte y menos en el área EMEA (Europa-Oriente Medio-Asia). También es proporcionalmente más utilizada en las empresas con más de 1.000 empleados.

Una idea del éxito y las posibilidades de JUnit es la acogida que ha tenido el servicio GRATUITO de JUnit Factory (http://www.junitfactory.com/) de AgitarLab, que permite a los usuarios enviar su código y les devuelve test JUnit generados automáticamente.
Incluso proporciona un plug-in para hacerlo desde Eclipse, que además incluye un runtime de JUnit con análisis de la cobertura de código. Como era de esperar, esta versión gratuita es una introducción a una versión de pago con funcionalidades más avanzadas, pero algún beneficio debe aportar cuando ya se han realizado más de un millón de solicitudes de generaciones de tests desde su puesta en funcionamiento en enero del 2007.

Leer más...

Optimizando la realización de pruebas: uso de métricas

Durante el diseño y la ejecución de las pruebas debemos recoger diferentes métricas. La utilidad más habitual es informar al responsable del proyecto del estado del sistema bajo prueba: defectos encontrados, severidad de los mismos, etc.

Habitualmente también se recogen métricas para conocer el grado de cobertura que se ha conseguido con la ejecución de las pruebas: casos de prueba propuestos, ejecutados, fallidos, no ejecutados, bloqueados, etc.

Pero el responsable de pruebas debe prever también la recogida de información suficiente para hacer más efectivas las pruebas realizadas en cada iteración. "Hacer más efectiva" significa aquí detectar el mayor numero posible de errores, o errores más importantes.

Para esto, debemos pensar con antelación cual será nuestra estrategia de mejora de la efectividad, de cara a recoger la información necesaria. Algunas de las suposiciones que podemos seguir son:

Los errores tienden a "agruparse" (1):

• Por zonas de código: un módulo o conjunto de funciones que presenta problemas en un ciclo de pruebas es propenso a presentar problemas en los siguientes
• Por equipos de trabajo de desarrolladores: un equipo que crea código con incidencias tiene a generar incidencias en nuevo código o correcciones
• Por equipos de trabajo de testers: un equipo o grupo de testers es capaz de identificar mayor numero de errores que otro, o un grupo levanta mas errores no reales (que luego, al ser revisados, resultan no ser errores) que otro.

En este caso, deberemos recoger información que nos permita trazar cada error detectado durante las pruebas con la zona en la que se ha producido. Una vez finalizado el ciclo de pruebas, podremos ver las zonas en las que debemos poner mayor atención en los siguientes ciclos de pruebas y en cuales podemos disminuir la intensidad o tomar medidas de mejora.

A la hora de determinar o analizar las zonas, podemos tener en cuenta los distintos factores que determinan el éxito o fracaso durante un proceso de test (2):

• Producción
• Personal
• Comunicaciones
• Operaciones
• Mantenimiento
• Entorno
  

Referencias

1. McGowen, D.J. “C4I Operational Test and Evaluation in Support of Evolutionary Acquisition Strategy.” ITEA Journal of Test and Evaluation 21.2 (2000): 34-39.
2. Phadke, M.S. “Planning Efficient Software Tests.” CrossTalk Oct. 1997 <www.stsc.hill.af.mil/crosstalk/1997/10/index.html>.
   

Leer más...

Sistemas que usan periféricos especiales

Muchos sistemas utilizan o se comunican con periféricos o dispositivos no estándares, como puede ser una puerta automática, una barrera, una impresora de billetes de metro o tren, etc.

En general, es difícil disponer de estos elementos en el entorno de pruebas, especialmente el interno (pruebas alfa, en las instalaciones del desarrollador, de verificación, como queramos llamarlas) ya sea por su tamaño, coste, disponibilidad en el tiempo o pertenecer a otra compañía.

Si no hemos tenido en cuenta esta circunstancia al realizar nuestra estrategia de pruebas (y por tanto, en el planteamiento general del proyecto) nos encontraremos con que el número de pruebas que podemos hacer antes de entregar nuestro producto está limitado por esta causa, y además en elementos cuyo fallo puede suponer un impacto importante en la calidad percibida por el cliente.

Una táctica para solventar este inconveniente es que cualquier implementación de comunicaciones con dichos dispositivos tenga un modo "de prueba" o "test", de tal forma que cuando el sistema está en este modo, la comunicación con el dispositivo es sustiuida por un metodo posible en el entorno de pruebas definido, como puede ser un fichero o impresora.

Este modo "test" debe cumplir con algunas características que nos permitan asegurar que su uso no desvirtua la prueba:

• Debe contruirse de forma que su activación o desactivación no implique la modificación y/o recompilación de código: mediante un valor en un fichero de configuración, entrada de registro, etc
• Para la interpretación/ generación del mensaje, debe ejecutarse el mismo código en el modo "test" que en el modo "en producción".

Ya que esta estrategia implica que el equipo de desarrollo tenga en cuenta en su trabajo las necesidades de pruebas (algo no muy habitual), es necesario conseguir que estas decisiones se tomen lo antes posible en el proyecto, y en el nivel de decisión adecuado que garantice que no se dejaran en el olvido cuando las presiones de tiempo lleguen.

Esta tactica puede extrapolarse a cualquier comunicación que nuestro sistema tenga que realizar con otro sistema del que no dispondremos en nuestro entorno de pruebas, aplicando como siempre el criterio de coste/riesgo correspondiente.

Leer más...

Oráculos

Para tener una prueba bien diseñada es necesario conocer de antemano el resultado de su ejecución. Un oráculo es un elemento o artefacto que nos permite conocer el resultado esperado de la ejecución de una prueba. Por ejemplo:

- Otra aplicación o sistema.
- Un resultado calculado por un método manual
- Datos históricos cuya validez ya ha sido comprobada en la realidad

La utilización o no de determinados oráculos en nuestras pruebas es una decisión que debe plantearse, y resolverse en la medida de lo posible, en la fase de Estrategia, ya que pueden conllevar actividades de preparación que es necesario acometer antes del diseño y/o la ejecución de las pruebas.

En este sentido es necesario evaluar siempre el coste/beneficio de su utilización, la fiabilidad del oráculo y sus necesidades de mantenimiento.

Por ejemplo, es muy común que a la hora de verificar un sistema en el que está implicado un cálculo complejo, el equipo de pruebas se prepare como oráculo una hoja de cálculo (excel o similaar) que lo refleja. Esto conlleva, entre otros, los siguientes inconvenientes:

• Quien prepara la hoja debe llegar a conocer con detalle toda la complejidad del cálculo. Si la información que llega a quien lo implementa en el sistema y a quien implementa el oráculo no es exactamente la misma y no se interpreta de la misma forma, los resultados de ambos pueden no ser coincidentes.
• Pueden producirse errores al preparar la hoja de cálculo
• Un error en las especificaciones del cálculo, producirá el mismo error en el oráculo, por lo que pasará inadvertido
• El oráculo deberá tener al menos el mismo mantenimiento que el sistema.

Asi vemos que esta elección nos lleva a crear y mantener un oráculo de coste considerable en relación a la implementación en el sistema y cuya fiabilidad no es mucho mayor.

En estos casos, siempre que sea posible, es más aconsejable utilizar como oráculo elementos reales que se hayan procesado en el pasado utilizando ese mismo cálculo. Ya que generalmente un sistema se construirá para sustituir a un proceso manual o a otro sistema obsoleto, el propio cliente será capaz de proporcionar datos (entradas, salidas) validados en la realidad.

Leer más...

El proceso de pruebas

La gran mayoría de las metodologías de pruebas distinguen 5 actividades principales en el proceso de pruebas, aunque con nombres diferentes. Estas son:

• Planificación o Estrategia: que se va a hacer, cuando, como y quien lo hará, que necesidades es necesario satisfacer para llevarlo a cabo.
• Diseño de pruebas: que pruebas se van a a hacer y en que consiste cada una (condiciones, pasos, datos, resultados esperados)
• Construcción de pruebas: especialmente en el caso de pruebas automáticas, es necesario materializar el diseño en determinados artefactos (programas, scripts de herramientas de ejecución automatica).
• Ejecución: realización de las pruebas propiamente dichas. Todo lo anterior es la preparación para esta fase.
• Evaluación: análisis de los resultados obtenidos de cara a proporcionar un diagnóstico del sistema bajo prueba y del propio proceso de prueba.

Adicionalmente, hay otros procesos necesarios, que las metodologías suelen desarrollar:

• Seguimiento: para asegurar que las actividades se realizan de acuerdo a lo previsto o, en caso contrario, se toman las medidas adecuadas.
• Gestión de la configuración: para gestionar y controlar productos de entrada y salida de las distintas actividades, y sus relaciones entre ellos y con el sistema bajo prueba.

Leer más...