Los falsos mitos del testing (I)

Semanas atrás coincidí con unos antiguos compañeros de trabajo (todos programadores informáticos) que hacía tiempo no nos veíamos. Después de los saludos de rigor, la conversación derivó a la profesión de cada uno. Transcribo, de manera aproximada,  la parte de la conversación que derivó hacia el mundo laboral:

………………..

• Amigos: Es bueno conocer a un “tester” de confianza…nunca se sabe. Porque tu tienes conocimiento de las funciones reales de un tester, ¿no?… hay mucho farsante por ahí.
•  Yo: ¿? Bueno, gracias por lo de “confianza”. Supongo que sí, que conozco las funciones de un tester.
• A: Me sorprende gratamente que   hayas sido tester – aunque …con lo monótono que debe ser,  siempre probando…..-. Además para mi los testers no estan “programados” para trabajar en equipo, son unos individualistas….  tengo dudas de si son “héroes o villanos”… no sé.
• Yo: Gracias… por dejarnos a los que trabajamos en el mundo del test más o menos como unos egoístas e individualistas solo programados para engrandecer nuestro ego ¿?… pero creo que estáis bastante alejados de la realidad.

……………………….

A raíz de esa conversación me  decidí hacer una  recopilación  (a mis antiguos compañeros ya se la envié hace unos días) de los falsos mitos del testing con las que intentaré resolver estas dudas  que, probablemente a aquellas personas que se consideren o que se hayan considerado tester en algún momento de su carrera profesional, puedan sentirse identificados:

• Probar es fácil y aburrido, cualquiera puede hacerlo.

Aparte de los testers, todo el mundo  argumenta que probar es fácil, que cualquier persona puede poner a prueba unas líneas de código, y que probar no es un trabajo creativo. Yo en esto discrepo. Considero necesarias habilidades especializadas, ser perspicaz, ser creativo, conocer el sistema así como la tecnología utilizada, para probar el software.

Hay que tener en cuenta que estas funciones, para una persona que ha desarrollado el software, es muy complicado, ya que esta figura, trata de hacer que el funcionamiento sea el correcto, por lo que la visión de otro perfil siempre es positiva y necesaria a la hora de detectar posibles errores (que los habrá).

• La función de un tester es solo encontrar errores

Cierto es que encontrar los defectos en el software es la tarea de los tester, pero muchos expertos en tecnología piensan que es su única función y que no se preocupan por nada más, dudando incluso de si están realmente involucrados con el proyecto en el que participan. Nada más lejos de la realidad.

Tengamos claro que la función de un tester comienza con la revisión de documentación en general (documentos de arquitectura, documentos con requisitos, documentos de ayuda, documentos funcionales, etc. para ayudar a los desarrolladores y analistas). Solo de esta forma, se conseguirá entender el funcionamiento global del software que se va a desarrollar, sus dependencias, así como los impactos de un módulo sobre otro.
Gracias a esta función del tester, un buen análisis previene la identificación de bugs y ayuda a ahorrar posibles costes tanto de tiempo como de  dinero.

• Un software probado estará “completamente” libre de errores

Uffff, este es un error común entre los testers, desarrolladores y clientes. Pensar que si la cobertura de las pruebas es del 100%, nos encontraremos un software de calidad y  libre de bugs es un error, debido a que el proceso de testing puede ser un ciclo interminable,  incluso para un tester con excelentes habilidades de prueba que ya  haya probado la aplicación. Solo pensando que ”siempre habrá alguien mejor tu ahí afuera”, se puede decir que nadie puede afirmar con absoluta certeza que una aplicación está 100% libre de bugs o defectos. No es extraño, por ejemplo, encontrarnos con algunos escenarios que nunca han sido probados por el equipo de pruebas o por el cliente durante el ciclo de vida de desarrollo de software y que se ejecuten una vez que el proyecto ha sido implementado.

• Probar es muy caro.

Mmmm eterna duda: los directivos y empresarios siempre se encuentran con el mismo dilema, pagar menos para las pruebas durante el desarrollo de software o pagar más por el mantenimiento o corrección posterior.
Con las primeras pruebas se ahorra tiempo y coste en muchos aspectos, sin embargo, la reducción del coste y de tiempo de pruebas, puede derivar en el diseño inadecuado de una aplicación de software, es decir en un producto inútil. Aquí aplicaríamos el dicho “lo barato al final sale caro”, y no solo económicamente, pues la imagen de la compañía puede quedar “tocada”, por lo que tomemos dicha expresión con su total amplitud.

Continuará…

Descubre solución integral de SOGETI para mejorar el proceso de pruebas y garantizar la calidad y la eficiencia de los sistemas de información de las empresas.

Josep María Rivera

Test Lead-Team Manager | SOGETI ESPAÑA