Los falsos mitos del testing (II)

En un post anterior mencioné algunos falsos mitos del testing. Hoy continúo con una segunda parte:

• Si no identificas defectos es porque eres un mal  tester

No es correcto culpar siempre a los testers por los bugs que pueden aparecer,  después de que la prueba se ha realizado. Aquí me  refiero al tiempo, coste y requisitos cambiantes.

A menudo, por estrategias empresariales de tiempo y dinero, nuevas campañas, cambios de planificación o de las especificaciones en los requisitos, tenemos un impacto en el planteamiento inicial de los planes de prueba, siendo absolutamente necesario reajustarse a la nueva realidad, por lo que aquí, es muy importante una impecable y correcta FLUIDEZ EN LA COMUNICACIÓN entre TODOS los equipos implicados por tal que  sean conscientes que  estos supuestos  cambios pueden derivar en  errores, cayendo injustamente en la responsabilidad del tester por no haber  sido previamente informado de estas modificaciones de requisitos por parte de la dirección de proyecto.

No obstante  no estoy quitando de responsabilidad al tester, ya que si el canal de comunicación ha sido el correcto, pero la estrategia de prueba no se ha modificado en la línea oportuna (responsabilidad del tester),  puede dar lugar a errores no detectados,  por parte del equipo de pruebas debido a una prueba errónea o deficiente.

• Solo con la automatización de pruebas es suficiente

La automatización de pruebas agiliza el proceso de pruebas mediante el uso de herramientas concretas, pero esto no deja de ser eso: un proceso automático por lo que no va a ser capaz de reemplazar todas las pruebas manuales. En el ámbito de  la automatización deben constar las  pruebas de regresión y ciertas pruebas funcionales, pero no abarcará  todas las áreas de pruebas de software. Hay elementos de prueba que sólo pueden ser alcanzados por la herramienta automatizadora utilizada, y que el tester podría tardar horas en ejecutar (la automatización consigue disminuir este tiempo), pero hay que tener en cuenta que ciertos elementos de prueba sólo pueden ser factibles por  los testers.

Las pruebas automáticas, deben iniciarse cuando el software ha sido probado manualmente por el tester y es estable en cierta medida. Por otra parte hemos de tener en cuenta que  la automatización no se podrá  utilizar si existen  cambios en los requisitos.

• Tester y desarrollador no pueden llegar a entenderse

La entrega de productos de calidad para los usuarios finales es un trabajo en equipo. Muchos compañeros en TIC piensa que testers y desarrolladores están destinados a recriminarse o “tirarse los platos a la cabeza”, pero esto no tiene porque ser así. No perdamos de vista que el objetivo global de ambos, dentro del proyecto, es común. Por lo tanto la afirmación merece un  “ROTUNDAMENTE NO”. 

• Las pruebas no se pueden iniciar si el producto no está completamente desarrollado.

Falso. La prueba depende del código, y si este no está completo, lo que no se puede realizar es  una prueba definitiva. Si realizamos algún tipo de prueba en esta fase, se trataría de una prueba  tipo “exploratoria” con la que podríamos ver cómo va el desarrollo y detectar ciertos defectos en una fase “embrionaria” del desarrollo (uno de los objetivos de la metodología SCRUM –pero esto es otro tema para hablar en otro post-).

La revisión de los requisitos y el desarrollo de casos de prueba son independientes del código desarrollado. Sin embargo (en el caso de que el ciclo de vida del desarrollo sea mayor del estimado dentro de un ciclo global marcado para las partes implicadas), esta dependencia  afectará al tester, reduciendo el tiempo estimado para poder probar el software totalmente desarrollado.

• Los Testers son los responsables de la calidad de un producto

Es muy común, y de manera errónea,  que sólo  el equipo de pruebas debe ser responsable de la calidad del producto. No obstante no se puede cargar esta responsabilidad exclusivamente sobre el equipo de pruebas.

Las responsabilidades de los testers incluyen la identificación de los bugs e informar, de manera clara y con la mayor argumentación posible, de esta incidencia a los demás grupos de trabajo implicados en el proyecto. En este punto y,  una vez que han sido convenientemente informados todos los grupos,  se tomará la decisión de si se   corregirán los  errores en la release o se liberará el software con los defectos detectados. Por este motivo, para muchos responsables o jefes de proyecto, liberar el software, según en qué  momento, implica poner más presión sobre el equipo de test, pues probablemente serán “señalados” por cualquier error, pero como vemos, esto realmente es fruto de una mala interpretación en cuanto a asunción de responsabilidades.

Creo que la conversación con antiguos compañeros me sirvió para ver que, desde fuera del mundo del test, hay ciertos prejuicios que aún faltan por aclarar y limar…. ¿Pedagogía?  Estamos en ello.

¿Quieres conocer cómo SOGETI puede ayudarte a mejorar el proceso de pruebas? Descubre nuestras soluciones y servicios de testing.

Josep María Rivera

Test Lead-Team Manager | SOGETI ESPAÑA