Nota: Este post fue originalmente publicado en el blog de PractiTest. PractiTest, simplifica tu manejo y administración de Testing. Aprende más. Regístrese para empezar una prueba gratuita.
Podrás enseñarle muchos trucos a un perro, pero no puedes enseñarle a volar, eso está reservado para las aves, los aviones o los platillos voladores...
He estado intentando explicarle a un par de equipos de Desarrollo Ágil por qué los desarrolladores no son buenos testers; así que tras haber hecho el esfuerzo de recordar todos los motivos que se me ocurren (basándome en mi experiencia hasta el día de hoy) me decidí a armar una pequeña lista y publicarla.
No me malentiendas, yo creo que los desarrolladores tienen que participar de las tareas de testing, y más aún en equipos de Desarrollo Ágil, pero también estoy al tanto de sus limitaciones y de los puntos ciegos cognitivos que tienden a dañar su testing; y como ya se ha dicho muchas veces, el primer paso para fortalecer tus debilidades es aceptar que las tienes.
¿Por qué los desarrolladores (frecuentemente) son malos para el testing?
1. “Sentimientos paternalistas” hacia su código
Los desarrolladores están conectados emocionalmente con lo que ellos escriben. Puede sonar absurdo pero es muy difícil ser objetivo con lo que tú mismo has hecho.
Por ejemplo, yo sé que mis niños no son perfectos, y así y todo estoy seguro que la pasaría muy mal si alguien viene a mí y se pone a criticarlos por algo (después de todo, ellos son perfectos, ¿no? :) )
2. Orientación hacia la “Ruta Positiva”
El trabajo de desarrollo está basado en tomar escenarios positivos y hacerlos posibles en el producto. La mayoría de sus esfuerzos giran en torno a cómo hacer que las cosas funcionen correctamente, de forma efectiva, eficiente, etc. El cambio de actitud mental necesario para trasladarlos desde una mentalidad positiva/constructiva a una mentalidad negativa/qué-puede-salir-mal no es nada insignificante y es muy difícil de lograr en poco tiempo.
3. Trabajo basado en el principio de la simplificación de escenarios complejos
Una de las tareas cotidianas de un tester es la de pensar en escenarios complejos (como por ejemplo el de realizar múltiples acciones simultáneamente, o repetir varias veces una operación, etc.) para hacer fallar al sistema y así identificar los fallos. Así que básicamente tomamos algo sencillo y buscamos formas en que lo podamos complicar.
Por otro lado, sus contrapartes, los desarrolladores, están entrenados para tomar un proceso o proyecto complejo, dividirlo en componentes lo más pequeños que sea posible, lo cual les permite crear una solución (Todavía me acuerdo de cómo me impresionó en la universidad la primera vez que entendí que todo lo que una computadora podía hacer era trabajar con operaciones AND, OR, NOT, NAND, NOR, XOR y XNOR, con ceros y unos).
4. Dificultad para identificar pequeños detalles desde una perspectiva global
No sé cómo explicar esta, pero sí que la he visto muchas veces, en todo el tiempo que he estado haciendo testing.
Uno de los efectos secundarios de convertirse en un buen tester consiste en desarrollar un sentido para (casi inconscientemente) detectar qué es lo que “no pega en la foto”. La mejor forma de describirlo es con ese sentir que nos dice que algo “no pega en la foto”, aunque no nos sentimos capaces de señalarlo con nuestro dedo; tras lo cual, aplicando ciertos procesos sistemáticos, somos capaces de encontrar cuál es el problema en particular.
¿¿Dónde está Waldo??
Una vez, un desarrollador me dijo que los buenos testers pueden “olfatear los errores”, y tal vez no estuviera muy alejado de la verdad.
5. Falta de perspectiva end-to-end y del usuario real
Debido a la naturaleza de sus tareas, la mayoría de los desarrolladores se centran en un componente o funcionalidad en particular de su producto, mientras que no tienen más que una vaga idea de cómo sus usuarios trabajan con su sistema end-to-end.
De los testers, en cambio, se espera que tengamos una perspectiva mucho más amplia de nuestros productos, se nos exige que los entendamos y los probemos como un todo, a la vez usando técnicas que nos permitan simular la forma en que los usuarios eventualmente trabajarán con ellos en la vida real.
6. Menor experiencia con errores e inconvenientes comunes en las aplicaciones
Una vez más, algo que viene con el tiempo y la experiencia es nuestro conocimiento de los errores e inconvenientes más comunes en las aplicaciones. Obviamente, a medida que un desarrollador acumula KLOCs en su teclado, también tendrá la oportunidad de encontrarse con varios errores e inconvenientes, pero un tester gana experiencia con ellos más pronto y con mayor profundidad.
Un tester experimentado ve un formulario y automáticamente empieza a pensar en los errores y fallos más comunes que puede encontrar en él, tras lo cual se pone a hacer testing con ellos.
En resumidas cuentas
No es que no quieran hacerlo, es tan sencillo como que los desarrolladores no pueden hacer el testing de la misma manera que los testers lo hacen. Eso no quiere decir que no puedan ayudar en el testing, y la verdad es que en algunas áreas en particular puede que lo hagan aún mejor que nosotros, pero antes de que empiecen, puede que les sea de ayuda identificar sus respectivos “puntos ciegos de testing” de forma tal que les sea posible compensarlos.
El testing de un desarrollador añade un montón de valor al proceso general de testing… Es más, mientras escribo esto estoy pensando en un futuro artículo sobre el tema del valor añadido que se obtiene al poner desarrolladores y testers a trabajar juntos.
Mientras tanto, si me olvidé de algo o si no estás de acuerdo con lo dicho, siéntete libre de hacérmelo saber :)
Actualización (23 de diciembre de 2010)
Al final, no escribí el artículo sobre poner a desarrolladores y testers a trabajar juntos (¡por ahora!) pero sí que escribí uno sobre sesiones pensadas para enseñarle a los programadores cómo superar sus limitaciones para el testing (mencionadas más arriba) y proveerles algunas técnicas para ayudarlos a hacer un mejor testing. Si este artículo te pareció interesante, puede que quieras darle un vistazo al otro también.
Sobre PractiTest
PractiTest es una solución end-to end de Administración de Testing y QA diseñada para ayudarte a controlar tu proceso de desarrollo y testing, centrándote en cómo manejar tu proyecto y su información, y en cómo comunicar los resultados de tu testing a todos dentro de la organización.
Este software te permite organizar tus requisitos, crear y ejecutar tests, identificar errores, etc. Es posible integrarlo con las más renombradas herramientas de administración de errores, como por ejemplo: JIRA, Bugzilla RedMine y Pivotal Tracker, así como con herramientas de automatización tales como Sellenium, JUnit, SoapUI, QTP, Jenkins y muchas más http://www.practitest.com/