Pruebas de QA de Software: ¿realmente mejoran la calidad?

¿Los testers mejoran la calidad, ayudan a mejorarla o solo pasan información a otros que lo hacen?

Últimamente, he estado siguiendo de cerca una discusión muy interesante en Twitter sobre si los testers mejoran o no la calidad del software. Sí, encontramos los errores, pero ¿somos solo los mensajeros? ¿O somos participantes activos en la construcción de grandes productos digitales?

I've never liked the characterisation that a tester doesn't actually improve quality, they provide information that can be used to improve quality. It's too much of a hands off, not my problem, abdication of responsibility attitude and it has never reflected the way I work.
— @[email protected] (@GregPaciga) October 13, 2019

Básicamente, Paciaga se queja de lo que suele decirse que las pruebas no mejoran realmente la calidad, sino que el objetivo es dar información que pueda utilizarse para mejorar la calidad. Es como desentenderse, asumir la responsabilidad y pasársela a otro (a los desarrolladores, un Product Manager, el CEO, etc.).

En ese sentido, y según mucho de lo que han dicho varias personas, me encantó la cita que tuiteó Enrique Almeida que Mónica Wodzislawsky del CES compartió durante su charla en la conferencia JIS.UY 2019 en Uruguay:

"El mejor tester no es el que encuentra mas bugs, sino el que logra que mas bugs sean arreglados". Lo dijo Mónica Wodzislawski en el https://t.co/fLIJb5TDVz y estoy 100% de acuerdo.
— Enrique Almeida (@ealmeida) October 4, 2019

La cita está en inglés originalmente por Cem Kaner:

“El mejor tester no es el que encuentra la mayor cantidad de errores, sino el que logra corregir la mayor cantidad de errores”.
Cem Kaner, director del Centro de Educación e Investigación de Pruebas de Software de Florida

Más ahora gracias al mundo del desarrollo ágil, donde todos somos responsables de la calidad, los testers también son parte de las decisiones que se toman en el equipo como en qué enfocarse, si liberar o no una funcionalidad, cómo resolver las cosas, y mucho más.

Hace algún tiempo, había estado charlando sobre esto con Gabriel Montero (de Peregrinus) cuando preparábamos nuestra charla para Argentesting 2018 revisando la famosa definición de prueba de Cem Kaner: “La prueba es una investigación técnica empírica realizada para proporcionar a las partes interesadas información sobre la calidad de un producto o un servicio“.

Esa definición dice que una vez que el servicio o producto está hecho, hay que probarlo y dar información. En ese momento, discutimos cómo sentíamos que las pruebas deberían tener otro enfoque, no solo para detectar y reportar errores, sino para prevenirlos.

Por lo tanto, tiene sentido que los testers participen desde el día cero , ya que en las reuniones de Definition of Done (historias de usuarios, casos de uso, etc.) el tester hará preguntas pensando en cómo realizará las pruebas más adelante, lo que hace que el desarrollador ya piense en cómo resolver los posibles problemas que puedan surgir y programar para la testabilidad, lo que seguramente ayudará a evitar muchos errores. Esta forma de planificación es más rentable que probar al final esperando que alguien finalmente detecte, informe, corrija y verifique los errores.

Además, existe otro problema con la definición de Kaner: el mero hecho de proporcionar información nos deja a los testers fuera de las decisiones, quitándonos nuestra responsabilidad. Debemos tener un papel más activo y contribuir a la calidad y responsabilizarnos, junto con el resto del equipo, de la calidad del producto.

Creo que la prueba no se trata de entregar información a un desarrollador para que luego haga lo que quiera con ella, o bien que un gerente de proyecto decida si implementar una nueva función en producción o no.

En el mundo actual, los testers tienen como objetivo la responsabilidad de la calidad y nuestra participación en estas decisiones importantes debe reflejarse en la definición de pruebas.

¿Qué opinas? ¿Los testers mejoran la calidad del software? ¡Déjanos un comentario!