Un par de testers, trabajando juntos, a menudo pueden hacerlo tan bien o mejor que un "cazador" de defectos experto. El trabajo de a pares puede ser estable (es decir, dos personas regularmente trabajando juntas) o mucho más fluído, como en XP (Extreme Programming) para desarrollo. En ese caso, el tester que es resposable de un área dada buscará compañeros de testing temporales quienes tengan experiencia útil o conocimiento para abordar alguna parte de dicha área.
El trabajo de a pares, en testing, es diferente a cualquier otra clase de trabajo de a pares debido a que el testing es una actividad de generación de ideas, más que una actividad para implementar un plan. El testing es una busqueda heurística de un espacio abierto y multidimencional. El trabajo de a pares tiene el efecto de alentar a cada tester a reaccionar y aclarar ideas. Si es ejecutado fielmente, el resultado de este proceso serán más y mejores ideas que informarán los tests.
Fomentamos fuertemente que previo a iniciar una sesión de testing, quienes trabajen de a pares estén de acuerdo en un plan de actividades a seguir. Para crear un plan de actividades, podrían utilizar 5 a 10 minutos apartados de sus PC (quizá en una pizarra) pensando en la dirección que seguirán en la próxima hora o dos. Quizá pongan foco en investigar los riesgos del producto a testear, en predecir defectos a detectar, o en las herramientas a utilizar. Esta es una guía general, no una lista detallada de casos de prueba. Los testers son libres de desprenderse del plan, para explorar nuevas oportunidades (por ejemplo, para localizar un comportamiento sospechozo que hayan notado pero que implica una funcionalidad diferente). Sin embargo, cuando hacen una pausa luego de seguir el nuevo enfoque, deberían mirar nuevamente su plan de actividades para ayudarse a decidir qué hacer luego. Sin un plan previo para aprovechar esas dos horas en que estén reunidos, el par de testers podría perder el foco.
Creemos que testear de a pares ayuda a ambos testers a estar focalizados en una tarea, a replicar y analizar defectos, y a que mientras uno de los testers se mantiene llevando adelante su tarea el otro pueda sortear las interrupciones o salirse del plan para aprovechar su tiempo en algo que se necesite hacer. También creemos que será menos probable que otros los interrumpan con temas menores. Además será más divertido.
Sospechamos que es al menos más eficiente que dos testers trabajen de a pares que sólos. Harán más cosas en menos tiempo. (1)
Recomendaciones para trabajar de a pares (2)
- Comiencen con una tarea bien definida. Cuando los dos se junten, sepan hacia donde van, su objetivo común, y que lo que se han propuesto pueden terminarlo en una hora o dos.
- Compartan todo, el trabajo de a pares se trata de funcionar como una sola mente; por ejemplo, mientras uno está escribiendo un caso de prueba, el otro lo está revisando y dándo su retroalimentación.
- Intercambien los roles: para el ejemplo de la escritura de un caso de prueba, intercambien el turno de escribir y revisar.
- Hablen de todo lo que sea necesario, expresen claramente que es lo que van a hacer, pregúntense siempre la mejor manera de implementar un objetivo común, dándose soluciones alternativas; etc.
- No se tomen las cosas muy a pecho. Cuando alguien tiene el ego muy alto, tiende a no aceptar críticas de los demás. Al ego excesivo se le puede atribuir la actitud defensiva ante críticas de quien expresa u ejecuta una opinión, llevándolo a pensar que lo que se le dice es personal y en su contra.
- Suelten el excepticismo. Esperen beneficiarse y disfrutar del proceso, si tendemos a pensar en el fracaso, lo más probable es que fracasemos.
- Utilicen las heurísticas de testing para generar rápidamente ideas para vuestras pruebas (ver explicación a continuación)
- Celebren los éxitos obtenidos y aprendan de ellos. No olviden aprender también de los errores cometidos.
Utilicen las heurísticas de testing para generar rápidamente ideas para vuestras pruebas (3)
Una heurística es una regla práctica; una manera de hacer una pregunta educada. La palabra viene del griego y significa "hallar, inventar". Las heurísticas no son la garantía para llegar a la respuesta correcta o a la mejor respuesta; pero nos son útiles.
La popularización del concepto se debe al matemático George Pólya, con su libro Cómo resolverlo (How to solve it, 1957); quién quería saber cómo los matemáticos llegaban a las pruebas matemáticas. Algunos ejemplos de recetas heurísticas extraídas de su libro, ilustran el concepto mejor que ninguna definición (nosotros apliquemos dichos ejemplos a nuestras tareas de testing):
- Si no consigues entender un problema, dibuja un esquema.
- Si no encuentras la solución, haz como si ya la tuvieras y mira qué puedes deducir de ella (razonando a la inversa).
- Si el problema es abstracto, prueba a examinar un ejemplo concreto.
- Intenta abordar primero un problema más general (es la "paradoja del inventor": el propósito más ambicioso es el que tiene más posibilidades de éxito).
Debido a que el número de casos de prueba posibles es infinito, nos frenamos haciéndonos preguntas sobre la pequeña porción de casos de prueba que serán efectivas para el tiempo y presupuesto con que contamos para llevar adelante nuestras pruebas. Testers experimentados coleccionan y comparten las heurísticas de testing que mejoran la calidad de sus preguntas. Un buen conjunto de heurísticas nos ayudan a generar pruebas muy rápidamente.
Aquí algunos ejemplos de heurísticas de testing, que podrían tener en cuenta en el trabajo de a pares:
- Prueben en los límites: Es más probable que en los límites se revelen ambiguedades de la especificación.
- Prueben cada mensaje de error: El código de manejo de errores tiende a ser más débil que la funcionalidad principal.
- Prueben configuraciones que son diferentes a la de los programadores: El programador estará predispuesto a asegurarse que su propia configuración funciona.
- Ejecuten pruebas que son fastidiosas de configurar: Son más probables de ejecutar las pruebas fáciles de configurar.
- Eviten pruebas redundantes: Si una prueba duplica realmente otra, ¿qué valor les estará entregando?
Para utilizar las heurísticas sabiamente, recuerden una cosa: no hay sabiduría en las heurísticas. La sabiduría reside en ustedes. Todo lo que la heurística hace son sugerencias para vuestra consideración. Seguir ciegamente heurísticas que no entiendan no es una buena práctica de testing. A medida que coleccionen heurísticas, traten de entender el razonamiento detrás de cada una y las condiciones bajo las cuáles es más o menos probable que funcionen.
___________________________________________
