Muchas veces pasa que al tester le echan la culpa de los errores que pasan a producción. ¿Quién probó esto? ¿Quién dejó esto sin probar? ¿Cómo pudo haber pasado? ¡Es culpa del QA!
Esto desencadena algo horrible. Conozco varios casos en que como el tester termina siendo cuestionado si probó algo o no, entonces, para defenderse de posibles amenazas y culpabilidades, termina generando documentacion con screenshots que muestran evidencia de cuándo probó, con qué datos, qué le dio, en qué ambiente, etc. Esto es sumamente costoso, ineficiente, e inútil. No le agrega valor al negocio ni al usuario.
La calidad es responsabilidad del equipo, eso es parte de una filosofía ágil. Este tipo de preguntas, no están alineadas ni con los valores ni con los principios ágiles. Si seguimos con las reglas de antes, generando esos conflictos de intereses entre devs y testers, no vamos a lograr aprovechar los vedaderos beneficios de las metodologías ágiles, que se dan cuando se conforma un equipo, y este trabaja en sintonía.
Sobre esto y otras cosas estuvimos reflexionando con Gabriel Montero en la charla que dimos en el Argentesting este año. En la ppt se veía esta foto, que luego alguien me dijo que le hizo acordar a un manager que tenía una cara parecida y le hacía este tipo de preguntas jeje.
En esa charla en Argentesting hice un ejercicio para mostrar de dónde viene esa idea de que el tester es el responsable de los errores en producción.
- Primero pedí que levanten la mano todos los QA presentes en el público.
- Muchos levantaron la mano.
- Les saqué fotos como evidencia 😉
Acá está la evidencia de los que se consideran culpables de subir bugs a producción, los que se definen como #QA. De hoy en más serán #testers. Excelente publico! Gracias @argentesting. Terminada la charla con @gmonterol “El día que #scrum mató a la calidad” pic.twitter.com/8x2aBNDLcN
— Federico Toledo (@fltoledo) October 19, 2018
Reflexionemos sobre lo siguiente: ¿qué signifca QA? Viene del inglés y significa quality assurance, o sea, aseguramiento de la calidad.
¿Para qué le pagamos a una aseguradora de autos? Para que cuando tenga un problema, un accidente, esta aseguradora se va a hacer cargo de los problemas. Entonces, ¿para qué le pagamos a un QA? Para que cuando hayan problemas en el software éste se haga cargo.
Esto es parte del problema. Si nos presentamos como “el QA del equipo”, estamos mostrando que creemos que somos los que aseguran la calidad, y vamos a cargar con esas culpas. Claramente nosotros nos tendremos que hacer responsables por los daños. Una de las primeras cosas que temenos que cambiar en nuestro rubro para estar alineados con una mentalidad ágil, es dejar de pensar que somos QA. Nosotros no aseguramos nada. No tenemos forma.
Nosotros somos testers. Como testers hacemos testing. ¿Y qué es el testing? Es un proceso en el cual brindamos información de la calidad de un producto, a alguien que le interesa, a alguien que va a hacer algo con esa información, a alguien que va a tomar una decision. Por ejemplo, a un manager, o al CEO de la compañía, que tiene que decider si pone en producción o no la última version. O si postpone y le hacemos más pruebas, o si corregimos los incidents abiertos. ¿Qué necesita esa persona para tomar una buena decision? Necesita saber:
- cuáles son los incidents que encontramos,
- qué fue lo que probamos,
- y qué fue lo que NO PROBAMOS.
Solo de esa forma va a poder tomar una decision en base a los riesgos.
Insisto en que debemos dejar de llamarle “QA” al rol de testers, no debemos tomar esa responsabilidad que no nos corresponde. Incluso, deberíamos usar un lenguaje más seguro.
¿Esto lo firmó QA? ¿Esto está certificado? ¿Tenemos la aprobación de QA?
Qué tal si enviamos un informe, un mail o lo que sea, diciendo “el software no tiene bugs, puede ser puesto en producción”.
What! Momento, no tomemos responsabilidades que no nos corresponden.
¿Cómo podríamos decir eso con un lenguaje seguro? (e incluso, diciendo algo más real y correcto, ya que es incorrecto asegurar que no hay errores y eso lo tenemos claro todos). Probemos hacer algo de este estilo: “de acuerdo a las pruebas realizadas, no encontramos nada que nos indique que no debamos pasar a producción”.
Tenemos que comenzar el cambio en nosotros mismos, y después podremos comenzar a hacer la pregunta que realmente importa. En lugar de querer saber “quién probó esto que se le escapó un error”, buscando culpas, hagamos un análisis de retrospectiva para entender cómo se están probando las cosas.
¿Cuál es la calidad de nuestro proceso de calidad? Porque al final del día, todos somos responsables de la calidad.
En resumen, un QA, solo está de adorno, cobrando un sueldo por hacer nada, al menos yo como programador creo las pruebas automáticas y el qa ni hace eso, pero eso si, se creen q son lo mejor de lo mejor, muchos niveles es por encima de un programador senior
Claramente no entendiste nada…..