Puede que eliminar al equipo de QA haya sido, en realidad, una mala decisión
- La parte más lenta del despliegue de software es el testing. La razón por la que existe el despliegue continuo es precisamente el testing, así que se considera que este sea el cuello de botella en un estado optimizado.
- El hábito y las conductas de optimización llevaron a la industria a ver al equipo de QA como un cuello de botella y a intentar eliminarlo. Esto redujo el respeto por el rol de QA y generó problemas para producir software de buena calidad.
- Los desarrolladores no comprenden adecuadamente cómo gestionar la calidad del software. Muchas organizaciones no saben de quién es la responsabilidad sobre la calidad del software, e incluso las que mantuvieron la función de QA tienen dificultades para encontrarle un lugar.
Qué se debe hacer para gestionar la calidad en la práctica del software
- Seguimiento de defectos: Se necesita una forma para que los usuarios proporcionen información sobre bugs y para que los desarrolladores los registren.
- Triaje: El triaje de bugs es el proceso de gestionar la asignación, priorización, organización, clasificación y eliminación de duplicados de los bugs.
- Investigación de defectos: Reproducir un bug es una parte importante de su gestión, y requiere trabajo de ingeniería para identificar el problema real y resolverlo.
- Enfoque: Debe haber personas en la empresa enfocadas en la calidad, y se necesita alguien que la defienda para equilibrarla con la velocidad.
- Testing de extremo a extremo: Los problemas de propiedad del sistema surgen por arquitecturas complejas, y eso lleva a la ausencia de pruebas de uso real antes del lanzamiento del producto.
La opinión de GN⁺
- Eliminar al equipo de QA puede ser un error de gestión que, a largo plazo, afecte gravemente la calidad del software.
- En el proceso de desarrollo de software, el aseguramiento de calidad es una labor importante, y ignorarlo o restarle importancia puede terminar llevando al fracaso.
- Este artículo resulta interesante porque vuelve a poner de relieve la importancia de QA dentro de la industria del software y enfatiza la necesidad de una percepción adecuada de la gestión de calidad y de una distribución apropiada de roles dentro de la organización.
1 comentarios
Opiniones de Hacker News
A fines de los años 70 trabajé en IBM en aseguramiento de producto, y escribía código de pruebas y armaba hardware para el producto a mi cargo (un sistema de procesamiento de texto). No le compartíamos al equipo de desarrollo los casos de prueba específicos, sino solo los problemas generales, para incentivar que corrigieran los bugs. Con la discrepancia entre los bugs descubiertos de esta manera y los bugs corregidos por el equipo de desarrollo, se podía calcular estadísticamente una estimación de los bugs restantes.
En organizaciones sin equipo de QA se introdujo el concepto de "sniff test". Era una sesión en la que toda la empresa probaba una funcionalidad nueva de forma intensiva durante un periodo corto (normalmente 1 hora), y eso terminaba generando muchos tickets de bugs. Muchas veces eran pruebas simples las que causaban problemas, pero ya no sorprende.
Dos empresas en las que trabajé hace 15-20 años invirtieron en equipos de QA de primer nivel, y tenían una habilidad sobresaliente para encontrar bugs en los que los desarrolladores no pensaban. El equipo de QA tenía la autoridad final para decidir si un producto se lanzaba o no. Hoy muchas empresas creen que es mejor que los desarrolladores escriban pruebas automatizadas y dediquen mucho tiempo a la cobertura de código, pero he visto muchos productos que en la práctica no funcionan. No es que las pruebas automatizadas sean malas, sino que cuestiono eliminar a los testers humanos de QA.
Los empleados más conscientes dentro de una organización suelen ser también los más inconformes. Reconocen los problemas de calidad e intentan resolverlos, pero no reciben reconocimiento, y cuando hablan de calidad se les trata como personas que quieren frenar el avance. Mientras los que "se mueven rápido y rompen cosas" siguen siendo recompensados, ellos se enfurecen por tener que arreglar el desastre después, y sienten que preocuparse de verdad dentro de la organización puede perjudicar su carrera.
QA tiende a ser visto por el negocio y la alta dirección como un "centro de costos". Existe la hipótesis de que conviene evitar trabajar en departamentos considerados "centros de costos", porque la compensación y el reconocimiento siempre van para quienes generan ingresos. QA tiene que hacer más trabajo con menos gente, recibe la culpa por los fracasos, y puede ser el primer lugar donde haya despidos cuando el negocio necesita adelgazar.
Los ingenieros de QA tienen capacidades sobresalientes de debugging. Trabajan en todos los aspectos de una aplicación, como pipelines, código fuente y directorios de pruebas, y a menudo ven a ingenieros de software pasar días sin leer los mensajes de error del pipeline, ignorando el problema base y adivinando soluciones. El desprecio hacia los ingenieros de QA no está exagerado en el artículo, y como las organizaciones de QA no pasan por procesos de entrevista tan rigurosos como los de ingeniería, se les considera inferiores.
Por experiencia personal, nunca he visto un equipo de QA que realmente escriba pruebas para ingeniería. La mayoría de los equipos de QA ejecutan un "plan de pruebas" de forma manual o, rara vez, mediante pruebas automatizadas de navegador/dispositivo. Estos tipos de pruebas tienen valor, pero no tanto como las "pruebas unitarias" o las "pruebas de integración". En este modelo, el equipo de ingeniería termina haciendo el verdadero trabajo de QA más que el propio equipo de QA, y el equipo de QA a menudo reduce su valor al reportar como bugs cosas que no lo son.
Microsoft, después de eliminar sus equipos de QA, vio aparecer más bugs en Windows y en sus productos de nube.