Siguientes pasos del desafío

3.- Encontrar un video en YOUTUBE interesante sobre testeo ágil y verlo.

El video que yo he visto es este, en español y útil, aunque la parte final sobre el genero del testeador me parece un poco absurdo:

4.- Leer el manifiesto y pensar en lo que implica según el rol que ocupas.

El testeo debe ser continuado en cada iteración, es importante tener buena relación con todo el equipo y colaborar, ser uno mas. Siempre pensar en el modo de hacer las cosas más fáciles y sencillas o al menos plantearselo.

5.- Habla con un programador sobre una historia /feature.

Tras generar una historia y sus test necesarios, sobre un código ya implementado por el programador, se vieron aspectos que no se habían incorporado y que fueron útiles, por lo que es conveniente que primero se realicen los test o su definición al menos y luego la programación en base a estas pruebas ya definidas.

6.-Comenta como es tu testeo exploratorio, compáralo con lo que otros testers hacen.

El testeo exploratorio implica seguir el sentido común y probar sin contar con casos de uso definidos. Rastrear y ser un usuario torpe o malintencionado, para descubrir más posibles fallos del software. Entiendo que el resto de testers hacen un testeo exploratorio similar, basado en la propia intuición y también focalizado en las partes mas críticas del aplicativo.

7.- Encuentra una manera visual de representar los test, por ejemplo un diagrama, modelos, etc.

La mejor manera es la gráfica. En la que pueda verse los test correctos en verde, los fallados en rojo y la cantidad de cada tipo. En cada iteración puede verse.

Lo mejor es incluirlo en el Runner las opciones para que la salida sea tipo gráfico:

Profundizando mas en este tema, y ya que usamos la integración continua y desde Jenkins lanzamos también los tests, he buscado un plugin de Jenkins que me mostrara la información más gráfica y útil para facilitar el trabajo.

El plugin de Jenkins es el llamado : Test Results Analyzer, al cual debes indicarle donde está el fichero XML con los resultados de la ejecución de los tests. Si no lo tienes en formato XML genéralo de algún modo.

El aspecto es algo así:

 Esto nos permite tener la lista de lo que se ejecutó en cada build y si falló o no de un vistazo.

Para la parte de las pruebas con cucumber, en nuestro caso , las pruebas del back, de los servicios web, hay otro plugin en jenkins que te da tambien el aspecto visual, llamado cucumber report, necesita un json para obtener los resultados de la ejecución.

Ya así los tienes documentados y la lista exacta de lo que se ejecutó en cada ocasión.