¿Eres tester? ¿Conoces las funciones reales de un tester? ¿Los testers juegan en equipo? ¿Héroe o villano? En este post vamos a presentar una recopilación de los mitos del testing con las que intentaremos resolver estas dudas y que seguramente a aquellas personas que se consideren o que se hayan considerado tester en algún momento de su carrera profesional, hagan sentirse identificados:

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

Aparte de los testers, todo el mundo va a argumentar 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. Pero esto no es cierto.
Habilidades especializadas, perspicacia, creatividad, conocimiento a fondo del sistema y la tecnología, son necesarios 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 agente siempre es positivo a la hora de detectar posible errores.
Esto solo puede lograrse mediante la formación y la experiencia.

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

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, que no se preocupan por nada mas, dudando incluso de su involucración con el proyecto, pero esto no es así.
La función de un tester comienza con la revisión de documentos de arquitectura, documentos con requisitos, documentos de ayuda, etc. para ayudar a los desarrolladores y analistas de negocio. De esta forma, se conseguirá entender el funcionamiento global del software, sus dependencias, así como los impactos de un módulo sobre otro.
Como bien sabemos, “mas vale prevenir que curar”, por lo que 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 monetarios a futuro.

Mitos del testing-Globe Testing

• Un software probado estará completamente libre de errores

Esto es un error común entre los testers, desarrolladores o clientes. Pensar que si la cobertura de las pruebas es del 100%, entonces habrá un software de calidad libre de Bugs, no es posible, ya que el Testing es un ciclo interminable. Incluso si un tester con excelentes habilidades de prueba, ha probado la aplicación. Solo pensando que »Siempre habrá alguien mejor tu», se puede decir que nadie puede afirmar con absoluta certeza que una aplicación de software es 100% libre de Bugs. Puede haber algunos escenarios que nunca han sido ejecutados por el equipo de pruebas o 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.

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. En un producto inútil. Aquí aplicaríamos el dicho «lo barato al final sale caro».

• No identificar defectos se debe siempre a los Testers.

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

A menudo, por estrategias de tiempo y dinero, nuevas campañas, cambios de planificación o de las especificaciones en los requisitos, puede afectar al planteamiento inicial en los planes de prueba, siendo necesario reajustarse a la nueva realidad, por lo que aquí, es muy importante que todo el equipo sea consciente y este informado de estos cambios para evitar los errores.
Es imprescindible una buena comunicación, ya que sin ella, los errores pueden aparecer, y no tiene porque haber sido culpa del tester, si este no ha sido previamente informado de estas modificaciones de requisitos.
Sin embargo, aquí no estamos quitando de responsabilidad al tester, ya que si el canal de comunicación ha sido bueno, pero la estrategia de prueba no se ha modificado correctamente, también puede dar lugar a errores que se pierdan por parte del equipo de pruebas.

• Solo con la Automatización de pruebas es suficiente

Falso. La automatización de pruebas agiliza el proceso de pruebas mediante el uso de herramientas, pero esto no deja de ser un proceso automático. No va a ser capaz de reemplazar todos los tester manuales. Esta bien incluirlas en el ámbito de automatización de pruebas de regresión y pruebas funcionales, pero no en todas las áreas de pruebas de software. Hay elementos de prueba que sólo pueden ser alcanzados por la herramienta, y que el tester podría tardar horas cuando la automatización consigue disminuir este tiempo, pero hay elementos de prueba sólo pueden ser factibles para los humanos.
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, la automatización no se puede utilizar si se producen cambios en los requisitos.

Mitos del testing-Globe Testing

• ¿Tester y desarrollador enemigos?

Rotundamente no. La entrega de productos de calidad para los usuarios finales es un trabajo en equipo. Mucha gente piensa que testers y desarrolladores están destinados a odiarse, pero esto no tiene porque ser así. Al fin y al cabo el objetivo global de ambos en el proyecto es común.

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

La prueba depende del código fuente, y si este no esta completo, no se puede realizar una prueba definitiva. En el caso de realizar algún tipo de prueba en esta fase, se trataría de una prueba “exploratoria” con la que podríamos ver como va el desarrollo.
Por otro lado, 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 ambas partes, esta dependencia puede 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 una mala interpretación muy común que sólo los testers o el equipo de pruebas debe ser responsable de la calidad del producto. No se puede cargar esta responsabilidad únicamente en el equipo de pruebas.
Las responsabilidades del tester incluyen la identificación de los bugs e informar de esta anomalía a los demás grupos de trabajo dentro del equipo, los cuales tomarán la decisión de si van a corregir el error o liberar el software. Por eso para muchos, liberar el software en el momento pone más presión sobre los testers, ya que serán culpados por cualquier error, pero como vemos, esto realmente es una mala interpretación.