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 Maria Rivera

Josep María Rivera

Test Lead-Team Manager | SOGETI ESPAÑA

Anuncios

2 comentarios

  1. Muchísimas gracias Borja por tu aporte.

    Paso a responderte con ánimos constructivos: como visión general (el objetivo del post era dar una visión general) si te fijas, se especifica que la automatización no debería iniciarse si existen requisitos cambiantes (es decir el tester, el desarrollador y el responsable del producto deben corroborar que los requisitos son los que son y por lo tanto se puede/debe automatizar sobre algo estable -de lo contrario estaremos perdiendo tiempo y dinero-).
    Estoy absolutamente de acuerdo en ejecutar un pair de equipos (tester/developer -visión de TDD, por ejemplo-) por tal de ejecutar un código testeado a la par (cosa que dará como resultado una optimización de la automatización y una mejor calidad de software), por lo que, salvo el matiz de requisitos no cambiantes, estoy de acuerdo con lo que apuntas.

    Muchas gracias y te animo a seguir colaborando.

    Me gusta

  2. Muy interesantes los dos artículos con el que estoy en general de acuerdo. Pero como lo que enriquece es la confrontación de ideas hay una paragrafo con el que no estoy de acuerdo y quería comentar:

    “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.”

    Depende de lo que tengamos en mente sobre las pruebas automáticas, si es UI podría estar de acuerdo, aunque tengo el gusanillo personal de afrontar el reto de contradecir eso también.
    Pero si de lo que hablamos es de servicios no solo no es que se pueda crear los scripts automaticos antes de ser probados por el tester manualmente, sino que es bueno hacer esos scripts a la vez que el desarrollo y utilizar esos scripts como validación del código generado por parte de desarrollo y antes de mergear su rama dentro de la branch principal.

    Un saludo
    Borja

    Me gusta

Deja tu comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: