Señalan que quizá fue una mala decisión desmantelar el equipo de QA

• Tras reducir los cuellos de botella en releases, despliegues, gestión de imágenes y rollbacks mediante optimización al estilo DevOps, el punto más lento en la entrega de software siguió siendo las pruebas
• La industria empezó a ver como cuello de botella no tanto a las pruebas en sí, sino al equipo de QA; aumentaron las expectativas sobre el rol, pero siguieron el deterioro de condiciones, la contratación temporal, el offshoring y los recortes de empleo
• Desmantelar las organizaciones de QA desmoralizó a profesionales con experiencia en QA y, como los desarrolladores no asumieron de forma natural el trabajo de calidad, creció el problema del software de baja calidad
• La gestión de calidad es trabajo real que debe nombrarse y asignarse, como el seguimiento, clasificación e investigación de defectos, la defensa de la calidad y las pruebas end-to-end
• Si el trabajo de calidad no se organiza, quienes detectan y arreglan problemas no reciben reconocimiento, mientras que quienes construyen rápido y rompen cosas son recompensados una y otra vez

---

El cuello de botella que quedó tras la optimización DevOps

• Los profesionales de DevOps aplicaron la Theory Of Constraints para optimizar con fuerza los pipelines y las prácticas de entrega de software
• La gestión manual de releases, los despliegues, la gestión de imágenes y los rollbacks en producción pasaron a ser objetivos de automatización
• En el proceso que va desde el backlog de producto hasta que el código llega al cliente, las actividades de bajo valor se trataron como cuellos de botella que había que eliminar u optimizar
• Como resultado, la parte más lenta de la entrega de software siguió siendo las pruebas
  • Las pruebas son también la razón por la que existe la entrega continua
  • Es posible hacer las pruebas más rápidas, automatizarlas y paralelizarlas
  • Si la actividad más valiosa de una práctica es el cuello de botella, la conclusión es que ya se está cerca del óptimo

La industria vio al equipo de QA como el cuello de botella

• El hábito de optimizar se aplicó más allá de las pruebas en sí, también al rol de QA
• Hubo movimientos para reducir pruebas de integración y pruebas end-to-end a pruebas unitarias para poder paralelizarlas
• En términos de personal, también ocurrió que personas consideradas incapaces de programar fueron empujadas hacia unidades funcionales
• La industria empezó a considerar que el cuello de botella podía no ser las pruebas, sino el equipo de QA
  • Las expectativas sobre el rol de QA subieron
  • Los salarios bajaron o no crecieron frente a otros roles
  • El rol se volvió más temporal y se llevó al offshore
  • Continuaron las decisiones de reducir la contratación de ingenieros de QA

El círculo vicioso creado por la reducción del rol de QA

• Quienes permanecieron en QA quedaron en una estructura cada vez más desfavorable
  • Las personas que programaban lo suficientemente bien, o que estaban agotadas por las condiciones, dejaron QA
  • Otros empezaron a ver a quienes quedaban en QA como “personas que no eran lo bastante buenas para salir de ese campo”
  • También disminuyó la cantidad de personas que recomendaban el área de QA a recién graduados
• Las empresas se separaron de QA con un enfoque de “ya no vamos a tener esta función, arréglenselas”
• Este proceso fue irrespetuoso y desmoralizante para quienes habían construido una carrera en QA
• El desmantelamiento de QA agravó el problema del software de baja calidad, y muchas organizaciones quedaron sin saber quién debe hacer qué en materia de calidad de software
• Incluso las organizaciones que mantuvieron la función de QA tuvieron dificultades para encontrar el lugar de ese rol dentro de un campo que ya había sido dañado

“Despedir testers” no era la solución

• El “truco raro” para entregar software más rápido no era despedir testers
• Dañar el campo de QA se acerca a uno de los peores errores de gestión
  • Fue una decisión que destruyó algo desarrollado durante décadas
  • Sus efectos pueden no sentirse durante años
  • Para cuando una organización siente el problema, la recuperación significativa puede volver a tomar años
• Las partes del rol de QA que ya estaban rotas originalmente siguen sin resolverse
• La división del trabajo no ocurrió, y los desarrolladores no aceptan con gusto el trabajo de QA sin compensación, reconocimiento ni una estructura de incentivos adicional
• Algunas personas que trabajaron con equipos de QA de alto desempeño pueden imitar parte de ese comportamiento, pero para ingenieros y managers más nuevos es difícil saber qué falta
• El principio central es que el aseguramiento de calidad es trabajo
  • Como cualquier otro trabajo, fracasa si se asume que “alguien” lo hará
  • Dejarlo como trabajo invisible también lleva al fracaso

Trabajo necesario para gestionar la calidad de software

• Seguimiento de defectos

  • Se necesita una forma para que los usuarios puedan enviar información sobre bugs y para que los desarrolladores puedan registrarlos
  • Un bug es un ticket individual que describe qué salió mal y qué tan grave es
  • No describe el trabajo de corrección en sí
  • Debe incluir el defecto, cómo reproducirlo y su impacto
  • La mayoría de los equipos de desarrollo con los que se trabajó recientemente no rastreaban este tipo de defectos
  • Razones como “igual no lo vamos a arreglar”, “no es mi trabajo” o “me recompensan por nuevas funciones” no justifican resultados de baja calidad
  • Gestionar una lista de bugs es, en sí mismo, trabajo

• Clasificación y priorización

  • La clasificación de bugs es el proceso de asignar, priorizar, ordenar, clasificar y eliminar duplicados entre los bugs entrantes
  • Mantener criterios consistentes para severidad alta, media y baja ayuda a la organización
  • En el pasado se le llamaba “higiene de bugs”
  • Decidir qué equipo debe hacerse cargo de cada bug también es trabajo
  • Las organizaciones que funcionan bien pueden responder mejor ante presiones externas o reestructuraciones
  • Incluso cuando hay despidos, gestionan gradualmente la degradación de la calidad
  • En una reorganización, transfieren ciertas categorías de bugs a un nuevo equipo
  • Descarten en bloque los bugs de funciones discontinuadas
  • Decir que un equipo sin estrés externo ni reorganizaciones puede ignorar el proceso de clasificación es casi una broma

• Investigación de defectos

  • La reproducción es una parte importante de la gestión de bugs
  • Alguien debe convertir un reporte como “intenté comprar boletos de cine y no pude” en algo como “un problema de codificación de caracteres rompió el flujo de compra para clientes con caracteres no ingleses en el nombre”
  • Preguntas como “¿cuántas veces ocurrió este problema?” o “¿cuál es el impacto en los usuarios?” requieren que personas reales dediquen tiempo a responderlas
  • La investigación de defectos consiste en aplicar rigurosidad de ingeniería al backlog de bugs

• Roles enfocados en la calidad

  • Tener dentro de la empresa a alguien enfocado en la calidad del producto final tiene valor real
  • La calidad puede ser responsabilidad de todos, pero al mismo tiempo debe ser responsabilidad de alguien
  • La tensión entre calidad y velocidad necesita a una persona que defienda la calidad
  • Las herramientas de prueba, la calidad de las pruebas y los planes de prueba necesitan una parte interesada con opinión que quiera hacerlos lo mejor posible

• Pruebas end-to-end

  • Uno de los problemas más grandes y comunes en muchas organizaciones de ingeniería es la propiedad del sistema
  • El aumento de la complejidad arquitectónica surgió con el objetivo de mantener pequeños a los equipos y las aplicaciones, y puede ser una estrategia razonable
  • Pero el resultado es que aparece un vacío en las partes más importantes de la aplicación
  • El equipo promedio ya no usa ni valida el producto a nivel end-to-end, porque es demasiado difícil
  • Antes de lanzar un producto, hay que asegurarse de que alguien dentro de la organización lo esté usando realmente

Problemas organizacionales al ignorar el trabajo de calidad

• Puede aparecer la reacción de “somos ágiles, lean y dinámicos, así que no necesitamos hacer estas cosas”
• Al mirar con detalle, es muy probable que este trabajo ya esté ocurriendo dentro de la organización, pero se esté haciendo muy mal
• Escuchar en otros ámbitos, como autos, bancos o médicos, “no hacemos aseguramiento de calidad” no es una buena experiencia
• No reconocer ni organizar las actividades de calidad conduce a situaciones muy malas
• Los empleados más concienzudos terminan siendo los más resentidos
  • Ven problemas de calidad y suelen resolverlos
  • No reciben reconocimiento por ello
  • Cuando plantean preocupaciones de calidad, se les trata como personas que quieren frenar la velocidad
  • Ven cómo quienes “se mueven rápido y rompen cosas” son recompensados repetidamente
  • Sienten que están limpiando con enojo el desastre de otros
• En este tipo de organización, el solo hecho de preocuparse se convierte en una desventaja para la carrera

[GN⁺]

Opiniones de Hacker News

• Al inicio de mi carrera, a fines de los años 70, trabajé en Product Assurance, es decir, la organización de QA de IBM Hursley Park. Para probar el sistema de procesamiento de texto que era nuestro producto, creábamos código y hardware, y ejecutábamos casos de prueba sobre el sistema bajo prueba.
  Los problemas que encontrábamos se comunicaban al equipo de desarrollo solo con una descripción general, con el objetivo de que arreglaran los bugs en lugar de hacer que pasaran los casos de prueba. Como resultado, si encontrábamos 3 bugs en saltos de línea con palabras con guion y borrado con retroceso, el equipo de desarrollo terminaba arreglando 4 bugs en esa área, pero solo 2 de los que realmente habíamos encontrado; así podíamos estimar estadísticamente cuántos bugs reales quedaban.
  En organizaciones sin equipo de QA, introduje el concepto de prueba de olfato. Normalmente era una sesión de más o menos una hora en la que cualquiera de la empresa o del departamento probaba a fondo una nueva función; aunque la función supuestamente estuviera terminada, las condiciones límite casi siempre estaban rotas. Si ponías "" en todos los campos y enviabas, navegabas la UI solo con el teclado o probabas condiciones simples como una fuente grande o el navegador al 110% de zoom, los problemas aparecían con frecuencia, y a estas alturas ya ni sorprende.

  • En nuestra empresa a eso lo llamamos bug bash, y normalmente también es muy productivo en términos de la cantidad de defectos encontrados.
    Durante el desarrollo de funcionalidades pequeñas, normalmente solo las prueban los programadores, y esto es especialmente útil porque esa forma de probar puede diferir de cómo las usarán los usuarios finales reales.
  • Es interesante la estrategia de ocultarles a los desarrolladores el origen de las pruebas automatizadas. Parece que puede hacer que se concentren en resolver los problemas reales, en vez de desactivar pruebas o ajustar el código solo para pasar la prueba.
  • En el Microsoft de antes lo llamaban bug bash, y mi startup también heredó esa idea. Se animaba a toda la empresa a reservar la tarde para participar, y también se daban premios a los bugs de mayor impacto o a los más interesantes.
  • Me pregunto para quién es realmente útil crear 100 tickets de bugs en una hora. Si hay muchos duplicados, con solo 10 bugs distintos ya queda suficientemente claro que la función está seriamente mal, y después de eso se siente como seguir golpeando los escombros.
  • La idea de tener casos de prueba de QA precisos y darles a los desarrolladores solo descripciones vagas es bastante ingeniosa. Es la primera vez que veo ese enfoque, y también me impresiona que permita estimar la cantidad de bugs restantes.

• Hace 15 o 20 años trabajé en dos empresas que invirtieron en equipos de QA de primer nivel, y esos equipos realmente valían lo que costaban. QA encontraba muy bien bugs que los desarrolladores no veían porque estaban demasiado cerca del problema, y los productos también llegaron a ser de clase mundial.
  En ambas empresas, la clave era que desde arriba se había establecido que el equipo de QA tenía la autoridad final sobre si se hacía un release o no.
  Hoy las empresas creen que es mejor que los desarrolladores usen pruebas automatizadas y se obsesionen demasiado con la cobertura de código, pero he visto demasiados productos que, aun con 100% de cobertura de código, objetivamente no funcionaban. No quiero decir que las pruebas automatizadas sean malas, sino que el problema es eliminar a los testers humanos de QA.

  • Las buenas organizaciones de QA/QE eran parecidas. La cadena de mando que decidía si certificar un release a producción era distinta de la de desarrollo, y la estructura de incentivos también era distinta.
    El equipo de QE de una empresa donde trabajé recientemente escribía una cantidad enorme de código para ejecutar pruebas; tenía más líneas de código que el módulo que se estaba probando y certificando.
  • La cobertura de código no encuentra los bugs que surgen del código que no escribiste, pero deberías haber escrito. La cobertura es solo una métrica entre varias, y tratarla como si fuera el único criterio es una tontería.
    Aun así, una vez escuché al gerente de pruebas de una gran empresa de software que todos conocen declarar que, como habían alcanzado 100% de cobertura, el equipo de pruebas ya había terminado.
  • No basta con una directiva que diga que QA tiene la decisión final; tiene que existir una cultura de QA.
    Incluso con esa autoridad, en empresas donde la mayoría de QA eran contratistas mal pagados que solo hacían lo que se les indicaba, todo seguía siendo un desastre.
  • He visto desarrolladores escribir pruebas sin assertions, o pruebas que solo tenían assertTrue(true). Siempre estaban en verde y la cobertura era 100%.
    Esas mismas personas solían preguntar por qué tenían que escribir pruebas si podían crear nuevas funcionalidades, hasta que llegaba un QA senior y rompía todo. Una vez encontró que, si se presionaba F5 50 veces durante 1 minuto, el backend se moría con outOfMemory mientras procesaba solicitudes a la base de datos.
  • Me encantan los QA meticulosos. Como desarrollador, depender demasiado de ellos esperando que detecten lo que yo pasé por alto es un antipatrón, pero ellos disfrutan cuando yo tengo miedo incluso de ejecutar mi código durante 1 minuto.
    Se enorgullecen de encontrar condiciones límite que van mucho más allá de la especificación, y ese valor es suficiente. Así como un buen sistema de tipos te da confianza ante los cambios, un gran QA también les da confianza a los desarrolladores. En especial en apps con mucha interacción, como los juegos, es difícil cubrir todo el espacio de parámetros solo con pruebas unitarias e integraciones.

• Es una verdad dolorosa que los empleados más concienzudos de una organización terminen siendo los más amargados. Ven problemas de calidad, a menudo los resuelven ellos mismos, pero no reciben reconocimiento; y cuando plantean preocupaciones de calidad, los tratan como personas que quieren frenar el ritmo.
  El lado de “muévete rápido y rompe cosas” sigue siendo recompensado, mientras que quienes sí se preocupan se encargan de limpiar el desastre y van acumulando enojo. Para ellos, el simple hecho de preocuparse se siente como un gran perjuicio para su carrera, porque en la práctica lo es.
  Los DBA y las organizaciones de infraestructura están en la misma situación que QA, y espero que el péndulo vuelva pronto.

  • Simplemente hay que saltar del barco y dejar que esa empresa se hunda. Es mejor que se hunda más rápido, y las cosas buenas se vuelven posibles cuando no sostienes a la fuerza a una mala empresa.
  • La forma en que creo que volverá el péndulo es si lo construiste, lo operas. Si no quieres que suene el pager de guardia, entonces no hagas que suene.
  • Al final depende del cliente. La cuestión es si se irá por los bugs y las caídas, o si se quedará por las nuevas funcionalidades brillantes.
  • QA y las pruebas son importantes, pero no sé si se podrá convencer a quienes solo miran las ganancias. Como la distribución por internet se volvió demasiado fácil, creo que el enfoque de “lanzar rápido y parchar después” seguirá existiendo.
    El cálculo es que, si los usuarios pueden reportar bugs y recibir actualizaciones por internet, no hace falta gastar tanto dinero ni tiempo. Desde que los juegos y el software pasaron de medios físicos a estar centrados en descargas, parchar parece salir más barato. Claro que eso lleva a problemas de seguridad terribles y a una mala experiencia de usuario, pero mientras la gente de arriba maximice las ganancias, no les importa demasiado.
  • Un ingeniero concienzudo no siempre tiene razón; hacen falta contexto y equilibrio. A veces tiene razón, pero su forma de comunicar está rota; otras veces simplemente está en el lugar equivocado.
    Si estás creando un producto SaaS de POC, no necesitas calidad al nivel de un microcontrolador de aviónica. Todo compromiso implica riesgos y costos, y un buen ingeniero debe saber distinguir la diferencia.

• El problema central de los equipos de QA es el mismo que el de los equipos de IT o las organizaciones administrativas: si hacen bien su trabajo, parece que no hacen nada.
  Por eso a menudo se ven en la situación de tener que “justificar” su trabajo, y eso suele venir de depender demasiado de las métricas. Como en la ley de Goodhart, no se entiende de qué es sustituto una métrica ni cuál es el verdadero propósito de ese trabajo.
  Un mal equipo de QA se pone demasiado quisquilloso para parecer que tiene algo que decir; un buen equipo de QA verifica la calidad y, al mismo tiempo, entrena al personal para que produzca con mayor calidad.
  Siento que hay una falta de entrenamiento generalizada en el personal. El artículo que llegó hace poco a la portada, “estar en el percentil 95 tampoco es gran cosa” (https://news.ycombinator.com/item?id=38560345), también decía que, como la mayoría de quienes ejecutan una tarea no entrenan activamente ni reciben feedback, llegar al 5% superior en cualquier campo es fácil.
  Me parece que las empresas deberían entrenar continuamente como equipos profesionales, no como equipos deportivos amateur. La contratación también debería mirar menos “¿ya es una persona de alto desempeño?” y más “¿podemos convertir a esta persona en alguien de alto desempeño?”. El hecho de que haya tenido éxito en un entorno anterior significa menos de lo que uno cree si el nuevo entorno es muy distinto.

  • Aunque el percentil 95 puede ser más bien el resultado de reducir errores innecesarios que de un esfuerzo enorme, está muy extendido el meme cultural de tratarlo como algo tremendamente difícil.
    En cada artículo sobre calidad de software hay muchos comentarios que dan por sentada la indiferencia generalizada de los ingenieros. Depende de la situación, pero la gente parece bastante dispuesta a simplemente adaptarse al óptimo local de su organización y renunciar a tomar la iniciativa. No es enteramente culpa de ellos, pero tampoco son inocentes.
  • En equipos de DevOps veo todo el tiempo el patrón de “tener que justificar el trabajo”. Normalmente, la persona de operaciones mejor pagada o más senior pasa mucho tiempo apagando incendios causados por su propia incompetencia o errores, y por eso parece que está haciendo algo.
    Si eliminas las tareas repetitivas con automatización, el puesto de esa persona desaparece; pero si lo haces bien, el gerente piensa que estás sentado todo el día sin hacer nada, así que hay pocos incentivos para hacerlo correctamente.
  • Cuando trabajas con desarrolladores nuevos, puedes hacer que tropiecen con frecuencia solo con pruebas básicas como doble clic, espacios iniciales o el botón Atrás de Android. Después de que les rechazan algunos tickets, aprenden esas cosas y luego ya casi no aparecen los mismos problemas.
    Como no me evalúan por la cantidad de bugs encontrados, tampoco hay presión para forzar la búsqueda de bugs tontos solo para subir el número.
  • En casi todas las empresas escuché: “si los entrenas así, se irán a otro lugar por más dinero”. La capacitación significativa siempre fue una batalla cuesta arriba.
    Para un buen entrenamiento se necesita suficiente amplitud y buena gente dentro de los roles técnicos. No hace falta conocer todas las tecnologías más recientes, pero sí poder detectar y señalar tonterías. FAANG no es la excepción.

• Como también se menciona en este texto, el punto realmente clave es que QA casi siempre es visto por las unidades de negocio y la alta gerencia como un departamento de costos.
  Tengo la hipótesis de que es mejor no trabajar en organizaciones que se ven como departamentos de costos. Los bonos, el reconocimiento y el respeto siempre van hacia quienes generan dinero; los departamentos de costos terminan cargando más trabajo con menos gente, se les culpa por los fracasos y son los primeros en ser recortados cuando la empresa reduce su tamaño. Lo mismo pasa con IT.
  Por este círculo vicioso, una carrera en QA siempre será más difícil que convertirse en desarrollador con habilidades similares. La gente excelente se agota y sale de ahí lo antes posible, y esa estructura se refuerza a sí misma.

  • Aunque seas desarrollador de apps móviles, siento que hay que tener cuidado de no asumir trabajo propio de un departamento de costos.
    Accesibilidad, observabilidad, buen logging, mejoras en la infraestructura de pruebas, ajustes de CI/CD, estabilidad, mejor linting y problemas de analizadores son cosas importantes, pero la recompensa llega cuando lanzas funcionalidades rápido.
    Este año pasé demasiado tiempo en ese tipo de trabajo porque pensé que el equipo y la app lo necesitaban, y me preocupa la evaluación de desempeño de fin de año. Ahora entiendo por qué otros evitaban estas tareas, y el próximo año pienso enfocarme más en lanzar funcionalidades visibles. Lo siento por los bugs de la app, pero necesito el trabajo para pagar la hipoteca.
  • Estoy de acuerdo con la sensación de ser un departamento de costos, pero por experiencia hay un poco más de matiz.
    Algunas organizaciones valoran de verdad lo que aporta QA/QC. Lo vi más claramente en manufactura que en software, probablemente porque el software es por naturaleza más abstracto y es más difícil rastrear el desperdicio.
    Una persona realmente buena en QA no es alguien que busca el camino fácil, sino alguien que cree en la misión de QA. Al final, lo que crea valor es si la organización y las personas adoptan sinceramente el espíritu de QA; en muchos lugares solo lo hacen de manera formal.
  • Trabajo en un equipo de plataforma frontend haciendo mejoras de rendimiento, diseño de CI e ingeniería de procesos, pero es mucho más difícil recibir reconocimiento y ascensos que para quienes lanzan funcionalidades que se traducen directamente en dinero en la cuenta bancaria.
    Aun así, no me molesta. Disfruto hacer que las cosas sean mejores y más sólidas, y eso me deja tranquilo. Les dejo romper cosas a los cínicos.
  • He trabajado casi toda mi vida en departamentos que eran, básicamente, de costos, pero no lo cambiaría por otra cosa.
    Está bien si los bonos y demás van a otros grupos. Ya me pagan bastante bien como técnico, y muchos de esos puestos que generan dinero me habrían hecho realmente infeliz, incluso si en la práctica se me hubieran dado bien.
  • Por eso no trabajo en el departamento de IT de una empresa tradicional.

• La calidad del software, la mantenibilidad del código y el buen diseño solo importan si planeas trabajar mucho tiempo en esa empresa.
  Si piensas irte a otra empresa después de unos años, el camino óptimo es hacer trabajo muy visible, ascender rápido y usar ese historial para conseguir un empleo con mejor sueldo. Si unos años después ese proyecto se rompe o se vuelve imposible de mantener, no importa, porque ya no estarás ahí.
  Las startups funcionan de la misma manera. El growth mindset grabado por todas partes es justamente este patrón. Aunque el producto sea imposible de mantener dentro de 5 años, para entonces quizá ya hicieron el exit y cobraron.
  No culpo exactamente a esas personas. Son prácticas que las propias empresas usan, y la gente solo juega según esas reglas. No me gusta y realmente lo detesto, pero lo entiendo.
  La parte divertida es ver a gerentes y ejecutivos quejarse de la rotación, la falta de compromiso con la empresa y el quiet quitting. Es como si probaran su propio veneno.

  • Puede ser una actitud razonable que una startup asuma que su producto quizá sea imposible de mantener en 5 años. La mayoría de las startups no sobrevive 5 años y fracasa.
    Si dentro de 5 años siguen vivos con deuda técnica, para muchas startups eso en realidad es un buen problema. Porque significa que, de todos modos, sobrevivieron 5 años.

• Los ingenieros de QA suelen ser muy buenos depurando. Meten mano en pipelines, código fuente y directorios de pruebas, y abarcan casi todos los aspectos del desarrollo y despliegue de aplicaciones.
  Cuando fui líder de QA, veía con frecuencia a ingenieros de software que se quejaban todos los días en Slack sin querer leer los mensajes de error del pipeline. Incluso al optimizar pipelines, ignoraban el problema de raíz y pasaban días intentando resolver con suposiciones los síntomas derivados de ese problema, como si fueran algo mágico e incomprensible.
  El desprecio hacia los ingenieros de QA que aparece en este texto no es una exageración. Incluso las empresas con organizaciones de QA muchas veces no tienen procesos de entrevista tan rigurosos como los de ingeniería, así que a los ingenieros de QA se los valora menos.
  Los únicos SWE que respetaban a QA eran quienes habían trabajado en QA. El desprecio estaba tan extendido que al final volví a una organización de ingeniería y traté de cambiarlo usando mi seniority como principal engineer o mi rol de manager, pero fracasé. Ingeniería no podía ver más allá de su propia arrogancia y el liderazgo tampoco ayudó.
  El nuevo CTO de la empresa donde trabajaba antes de que me despidieran decía que la necesidad de QA podía eliminarse con automatización, pero no tenía ni un solo ejemplo de qué quería decir. Ese era el nivel de respeto que venía desde arriba por el trabajo de hacer buen software.

• Microsoft parece ser el caso donde este problema se nota más. Después de eliminar el equipo de QA, aumentaron de forma visible los bugs en las actualizaciones de Windows y de sus productos de nube.

  • Como los ingresos siguen entrando, supongo que desde el punto de vista del negocio fue una decisión correcta… suspiro.
    Uso mucho software y servicios de Microsoft en el trabajo, y me gustaría que pagaran de alguna forma por la caída en la calidad.

• Puede que sea solo mi experiencia personal, pero nunca vi un equipo de QA que realmente escribiera pruebas para ingeniería.
  Los equipos de QA que conocí escribían planes de prueba y los ejecutaban manualmente o, rara vez, mediante pruebas automatizadas de navegador o dispositivos. Esas pruebas también tienen valor, pero creo que menos que las pruebas unitarias o de integración.
  En este modelo, en la práctica el equipo de ingeniería terminaba siendo el equipo de QA, y el equipo de QA separado solía generar ruido al encontrar como bugs cosas que no lo eran, creando más costo que valor.
  Me gustaría aprender cómo es un modelo de equipo de QA que funcione bien. Las pruebas manuales son excelentes, pero en mi experiencia tienen límites. No intento menospreciar a la gente de QA, sino compartir mi experiencia.

  • El valor de QA que he visto está en la familiaridad con el producto. Un buen QA sabe mejor que nadie cómo se comporta realmente el producto.
    Conoce de forma integral todo el sistema visible para el usuario, incluso mejor que PM, ventas o la mayoría de los equipos de desarrollo, y puede decir con precisión qué pasará al presionar cierto botón. Un mal QA sí es una fuente de ruido, pero lo mismo pasa con malos desarrolladores, administradores de sistemas o soporte de nivel 1/2.
  • Un buen QA cumple para un desarrollador de software el mismo rol que un buen editor cumple para un escritor. Mira con frialdad el resultado en el que uno trabajó tanto y lo critica sin piedad.
    Mientras te pasa, es realmente molesto, pero la calidad del resultado mejora muchísimo.
    Antes, QA normalmente no escribía pruebas; probaba el código manualmente e intentaba todo tipo de comportamientos extraños que uno espera que los usuarios no hagan. Encontraba problemas y bugs difíciles de capturar de forma general con pruebas.
    Ahora le pasamos QA al usuario. Al trabajar con desarrolladores jóvenes, siento que el concepto mismo de QA se vuelve cada vez más ajeno. Cuando un bug llega a producción y pregunto “¿cómo se veía cuando lo probaste localmente?”, muchas veces me miran raro. La actitud es como: si pasó el type checker, ¿por qué no lanzarlo?
    Hoy la eficiencia de los programadores se mide en PR por minuto, así que introducir bugs no es un problema; incluso es algo bueno. Si alguien lo encuentra en producción, unos días después puedes mandar otro PR para arreglarlo. Si hubiera QA, habría arruinado ese flujo.
  • Yo soy QA y escribo pruebas para ingeniería; mi cargo exacto es SDET. No solo trabajo con planes de prueba, sino también con frameworks de prueba, infraestructura y la automatización de esos planes de prueba.
    Cada empresa implementa la función de QA de manera distinta. Puede dejársela a los clientes, o a desarrolladores, soporte al cliente, QA manual o SDET. Al final depende de cuánto valore la calidad el liderazgo y de cómo perciba a QA.
    Si hay un equipo de QA, creo que tiene más probabilidades de éxito cuando participa desde etapas tempranas del proceso. Un buen equipo de QA debería encontrar bugs antes de que se escriba el código. Mientras más tarde participe, más tarde se encuentran los bugs y más squeezed queda entre “código completo” y el release. El equipo de QA necesita capacidad de automatización para poder dedicar tiempo a nuevos casos de prueba en vez de repetir pruebas manuales.
    Este texto me pega bastante fuerte. A veces QA es tratado como ciudadano de segunda y queda fuera de discusiones donde podría obtener el contexto necesario para hacer bien su trabajo. Cuando la gente buena se va a desarrollo o product management, la situación empeora, y esa espiral descendente existe de verdad.
  • No existe una forma formal de operar una organización de QA, así que muchas veces contratan a la gente y luego le dicen “arréglenselas”. Entonces las demás organizaciones no entienden las necesidades de QA y las ignoran.
    Lo que estás describiendo ahora es un problema de liderazgo, no un problema de utilidad de QA.
  • En el modelo clásico, la mayoría de las organizaciones de QA funcionaban como un apéndice inútil. Era algo estructural, y también influía mucho que, cuando desarrollo se retrasaba, QA quedaba desplazado.
    QA pasaba tiempo creando infraestructura de pruebas y planes de prueba sin poder integrarse desde el inicio, y al final recibía un bloque de código y un plazo de aprobación de 48 horas, teniendo que firmar bajo una presión extrema.
    Pero de vez en cuando uno podía encontrarse con una organización de QA que entendía profundamente el dominio del problema y realmente guiaba el desarrollo. Se movía junto con desarrollo de principio a fin, y no solo elevaba la calidad, sino que también ahorraba tiempo a todos.

• Al crear FoundationDB, se enfocaron en la calidad y las pruebas casi al punto de la obsesión. Por eso incluso crearon un lenguaje llamado Flow, para simular de forma determinista clústeres de FDB de cualquier escala, someterlos a condiciones extremas, señalar violaciones de propiedades del sistema y reproducir perfectamente la ejecución de la prueba que provocó esa violación.
  Llegaron al punto en que, cada noche, se ejecutaban decenas de miles de pruebas y, si no había código nuevo, básicamente todas daban luz verde. Las pruebas que salían en rojo casi siempre se debían a una incorporación reciente de código, por lo que eran fáciles de identificar y corregir.
  Gracias a eso, el equipo podía desarrollar sabiendo que los bugs recién introducidos se detectarían rápido, y eso se tradujo en una velocidad que les permitió asumir con confianza proyectos audaces como una reescritura del sistema de procesamiento de transacciones después del lanzamiento. Como resultado, también obtuvieron una mejora de velocidad de 10 veces.
  Al final, el enfoque en la calidad llevó a más velocidad, y ambas cosas no estaban en conflicto en absoluto. No creo que esto sea un fenómeno aislado, y por eso derivó en un nuevo proyecto, pero esa es otra historia.

  • ¿Ese lenguaje es este Flow? https://github.com/apple/foundationdb/blob/main/flow/README....