¿Quieres saber que es lo que da miedo a los testers? Si trabajas en testing, seguro que conoces muchas situaciones en las que te asusta en la forma en que perjudicará en la calidad del proyecto. Día a día, en los proyectos de desarrollo, nos encontramos con situaciones de estrés que requieren ser ágiles. Y por desgracia, en ocasiones se confunde el ser ágil con saltarte los procesos que aseguran la calidad. Por ejemplo, el no mantener los entornos herméticos. Te dejo mi post por si te gustaría leer más al respecto: La importancia de los entornos de pruebas herméticos en QA.
Aunque hoy nos vamos a centrar en los comentarios más escalofriantes de nuestros desarrolladores.
Índice de contenidos
El desarrollo está finalizado, pero...
Es importante que todos seamos conscientes de que significa finalizado. En este sentido, es vital la transparencia con la que se traslada esa información al resto del equipo. No es lo mismo decir: “El desarrollo está finalizado”, a decir: “El desarrollo está al 95%, y ese 5% depende del cliente. Estamos pendiente a recibir una información que aún no ha confirmado”. En la primera afirmación, el entorno está listo para probar el desarrollo. En la segunda, hay que evaluar si se puede probar el desarrollo o si puede haber algún impacto que haga que sea necesario reprobar.
Lo que nos da miedo a los testers es que nos digan que el desarrollo está finalizado y posteriormente comprobar que hay un pero. Es importante que todo el equipo sepa cuál es la definición del DONE.
El "No consigo replicarlo" da miedo a los testers
Cuando se detecta que algo no funciona cómo debe, o no se visualiza cómo corresponde o no indica el texto indicado siempre se deben capturar imágenes con las evidencias. Lo ideal es hacer captura de imágenes o vídeos de todo el proceso. En otras palabras, debemos tener «pruebas». De esta forma podemos saber si se ha ejecutado el caso de prueba de forma correcta en primer lugar. Y en segundo lugar, el desarrollador tendrá el flujo para replicar el proceso. Si aun así no se consigue detectar nuevamente el bug, es cuando nos asustamos. ¿Cómo es posible que el sistema se comporte de forma distinta ante el mismo estímulo? ¿Cómo para el mismo caso de prueba, con el mismo dato no se obtiene el mismo resultado? Esto es uno de los puntos que les da miedo a los testers. ¿Qué se nos está escapando? Es importante detectar este factor.
En mi ordenador si funciona
¿Cómo puede ser que estemos probando un entorno web y a mí me muestre un resultado y a otro compañero algo distinto? En general, cuando estamos en entornos web, suele ocurrir, que no se está haciendo algo correctamente. En primer lugar, puede ser que el navegador tenga algo cacheado o en las cookies. Hasta sucede, a veces, que el propio ordenador cachea algunos comportamientos y es necesario reiniciar. ¿A qué parece broma? ¡Reiniciar siempre funciona! En segundo lugar, puede ser que no se haya realizado la prueba desde el mismo punto origen, y en la navegación el usuario se pone «la mochila» de un conjunto de datos que modifica el resultado obtenido. En conclusión, siempre hay algo que hace que el software se comporte de distinta forma, independientemente de si somos capaces de identificarlo o no.
Re-planificamos, ¡Esto sí que da miedo a los testers!
Cuando escuchamos la frase de «Re-planificamos» realmente, no siempre nos da miedo. Solo en el 50%. Hay veces que una replanificación significa que al no llegar a la entrega, se mueven los distintos niveles de pruebas de forma progresiva a la nueva fecha de pase a producción. Esta es la situación que tiene sentido, pero por desgracia, no es siempre con la que nos encontramos.
La situación que más da miedo a los testers es cuando tenemos 2 semanas para probar un desarrollo y debido a que el desarrollo se extiende, tenemos que comprimir la pruebas en 1 semana. En la mayoría de los casos, es una objetivo difícil de completar, pero en otras es imposible. En este sentido, los responsables de los proyectos deben ser conscientes de que no se puede comprimir la pruebas, simplemente se reducirá la cobertura de ejecución de pruebas. Si nos encontramos en esta circunstancia, se debe determinar si se ejecutan solo las pruebas de prioridad Alta o si, además las de prioridad media. En cualquier caso, se descartan las de prioridad baja. Sin embargo, en otros casos se opta por incluir en el equipo personas de apoyo. Estas personas no tienen el contexto global del proyecto, por lo que pueden obviar algo sin querer.
¿Qué consecuencias tendremos? En todo momento, es muy posible que se escape algún defecto, aunque no podremos determinar si será de los críticos o no.
Ese defecto ya se solucionó
Mi respuesta-pregunta me gustaría que fuera: ¿Estás seguro? Más que nada, porque en muchas ocasiones se quema un dato (escaso a veces) y perdemos el tiempo. ¿No sería lo correcto verificar que la corrección es la adecuada y sacar una evidencia? Yo entiendo que sí, que es lo mejor para el equipo, lo mejor para el proyecto, pero entiendo que a veces no sea lo mejor para el desarrollador que esta al 120% de tareas. Aunque este punto no da miedo a los tester.
Lo que da miedo realmente es cuando te dicen: «Ya está probado, aquí te dejo a evidencia. No tenemos más datos para probar». Y te dan una captura de pantalla (triste), donde solo está la pantalla final. Sobre todo, sin que se visualice el entorno de pruebas. ¿Dónde están las evidencias del flujo completo? ¿Dónde están los datos introducidos? No es cuestión de confianza, es cuestión de ser realistas y transparentes. Cualquiera puede cometer un error, pero, ¿cómo identificamos ese error si no tenemos el testimonio de que ha ocurrido, ni las pistas que nos lleven a su descubrimiento? Es importante, entrar estas dinámicas de trabajo, en las que en primer lugar parece que nos quita mucho tiempo, pero a la larga nos ahorra impactos en la calidad.
Conclusión: Si nos da miedo a los testers, perjudica a la calidad
Es importante poner foco en no caer en estas dinámicas. Si algo da miedo a los tester es porque perjudica el proceso de calidad. Es necesario ser transparentes, dialogar con los compañeros y re-planificar teniendo en cuenta a todo el equipo. También es interesante tener una bitácora de los problemas encontrados o un listado de instrucciones para poder consultar y resolver las duda rápidamente. Y cómo no, verificar que las correcciones se han realizado correctamente. Si aplicamos todos estos consejos, tendremos mejores herramientas para mejorar la calidad de nuestro producto. Del mismo modo mejoraremos la percepción de nuestro equipo y organización.
¿Te ha gustado la entrada? ¿Tienes algo qué añadir? Deja un comentario o subscríbete al blog y hablamos de ello.
Quizás te puede interesar
