Te contamos por qué en Abstracta somos una empresa de ingeniería de calidad de software: el testing es responsabilidad del equipo y parte fundamental de la filosofía agile.

A menudo, se culpa a los testers cuando un error llega a producción: ¿quién probó esto? ¿Quién dejó esto sin probar? ¿Cómo pudo pasar esto? ¿Dónde estaba el control de calidad?.

He visto varios casos en los que un tester resulta siendo cuestionado si ha probado algo o no. Luego, para defenderse, genera un documento con la evidencia de cuándo realizó la prueba, con qué datos, en qué entorno, etc. trabajó.

Esto se convierte en un esfuerzo costoso e ineficaz que no agrega ningún valor al negocio o al usuario. Cuando las personas dentro de una empresa tienen que dedicar tiempo y energía a defenderse de las amenazas internas, seguramente tendrán menos tiempo y energía para concentrarse en las necesidades del usuario y en las oportunidades comerciales más importantes.

Calidad: responsabilidad de todo el equipo y parte de la filosofía agile

Las anteriores preguntas no están alineadas con los valores ni con los principios ágiles. Si continuamos con la mentalidad tradicional de desarrollo de software, que genera conflictos de interés entre desarrolladores y testers (los desarrolladores construyen y los testers destruyen lo construido), no podremos aprovechar los beneficios reales de las metodologías ágiles, que ocurren cuando el equipo actúa como uno solo y trabaja mancomunadamente.

En una charla que brindé en la conferencia Argentesting con Gabriel Montero de Peregrinus, Partner de Abstracta, debatimos este tema y compartimos esta imagen a continuación. Alguien me había dicho que les recordaba a un Manager que tuvieron una vez y que usó una expresión similar, acusándolos de no probar lo suficiente cuando un error llegó a los usuarios.

¿Qué es el Software Quality Assurance?

Como sabes, software quality assurance significa garantía o aseguramiento de calidad. Al presentarse un tester como “el QA del equipo”, está insinuando que es quien asegura/garantiza la calidad y es quien será responsable de los bugs que surjan.

Una de las cosas que los testers tienen que cambiar para alinearse con una mentalidad ágil es dejar de considerarse como QA.

No son los testers los que determinan si la calidad es adecuada o correcta antes de avanzar con el lanzamiento de un producto digital.

En una entrevista de TechWell, Michael Bolton, también expresa su opinión sobre el tema, que está en línea con nuestro pensamiento:

“Es muy extraño, muy extraño que un tester apruebe la calidad de un producto. Es como un periodista de investigación que firma la decisión del colegio electoral. No es así como debería ser la distribución de responsabilidades en una empresa”.

Michael Bolton, director de DevelopSense y co-creador de Rapid Software Testing

Los testers de software no aseguran nada. No hay forma de que lo hagan. Somos testers. Y como testers, hacemos pruebas.

¿Qué son las Pruebas de software?

Las pruebas de software son un proceso en el que los testers proporcionan información sobre la calidad de un producto.

Por ejemplo, la información que un tester levanta llega a un gerente o un CEO, quien debe decidir si lanzar la última versión, posponer el lanzamiento para hacer más pruebas o tomarse un tiempo para corregir los incidentes identificados.

Lo que necesita saber un gerente para tomar una buena decisión es qué incidentes se encontraron, qué fue probado y qué quedó pendiente por probar. Solo así es posible tomar una decisión basada en riesgos.

Insisto en que deberíamos dejar de llamar “QA” al rol del tester porque no deberíamos asumir ninguna responsabilidad que no le corresponda.

En lugar de enviar un reporte y señalar: “El software no tiene errores, se puede poner en producción”, intenta decir: “Según las pruebas realizadas, no encontramos nada que nos indique que no debemos entrar en producción”.

Primero tenemos que comenzar el cambio con nosotros mismos, y luego podemos hacer las preguntas que realmente importan. En lugar de buscar a quién culpar, los líderes del equipo deben organizar un análisis retrospectivo para comprender cómo se están probando las cosas actualmente.

Como equipo, pregúntate: ¿Cuál es la calidad del proceso de calidad? Porque a fin de cuentas, todos somos responsables de la calidad.

No somos una empresa de Aseguramiento de la Calidad del Software

Dicho todo lo anterior, en Abstracta no somos una empresa de aseguramiento de calidad de software.

Como descargo de responsabilidad, algunas páginas en nuestro sitio utilizan este tipo de conceptos, porque la mayoría de las profesionales todavía ven lo que hacemos como control de calidad de software. ¡Tenemos la misión de cambiar eso!

Somos una empresa de Ingeniería de Calidad de Software

Usualmente, transmitimos a nuestros clientes que nuestros ingenieros de calidad trabajarán codo con codo con sus equipos para ayudar a co-construir un mejor software, lanzarlo en el momento oportuno y reducir los riesgos y costos asociados. Sin embargo, nunca asumiremos la función de garantizar la calidad de sus productos.

No existe un software libre de errores, pero sí hay software que cumple con las expectativas de las partes interesadas por su funcionalidad, rendimiento, seguridad, etc.

¿Cuál es tu opinión? ¿Has estado en una situación en la que el título de quality assurance te haya impactado negativamente en el trabajo? ¡Cuéntanos tu experiencia en los comentarios!

Otros contenidos relacionados

Testing Ágil para crear productos digitales de alta Calidad

Abstracta, un experto en Testing Ágil y Calidad de Software

El rol de un Quality Engineer en el Desarrollo de Software