La realidad de no aprender a desarrollar software de alta calidad
(florianbellmann.com)- Muchos proyectos postergan las medidas de QA y terminan dependiendo de un gran sprint de QA justo antes del lanzamiento, repitiendo el mismo caos en el siguiente ciclo
- La formación en ciencias de la computación dedica tiempo a algoritmos, lenguajes y gestión de proyectos, pero a menudo no trata el aseguramiento de la calidad del software a un nivel práctico
- En las empresas, cuando falta presupuesto, se retrasa el desarrollo o aumenta el alcance, QA suele ser lo primero que se recorta, y se termina desplegando software frágil tras apenas pruebas mínimas y poco estructuradas
- Para convencer sobre QA, en vez de usar expresiones abstractas como “más estable”, hay que hablar del costo de no hacerlo, por ejemplo en términos de aumento del costo de desarrollo o de la duración de la estabilización de releases
- En lugar de crear todo un sistema de calidad de una sola vez, es más realista proteger primero las funcionalidades clave directamente ligadas al valor para el cliente, y escribir las pruebas junto con cada funcionalidad nueva al momento de implementarla
QA postergado hasta justo antes del release
- En muchos proyectos, el desarrollo avanza sin medidas importantes de aseguramiento de la calidad
- Aunque se reconozca su necesidad, en la práctica suele concentrarse todo en un gran sprint de QA justo antes del release
- Este enfoque aumenta el estrés y apenas logra que el software funcione de forma mínima
- En el siguiente ciclo de release se repite el mismo caos, y es difícil que derive en mejoras estructurales
La brecha de calidad entre la educación y la práctica
- Los programas de ciencias de la computación se concentran principalmente en algoritmos, principios de funcionamiento de las computadoras, y la historia y conceptos de los lenguajes
- Puede haber un semestre dedicado a metodologías de gestión de proyectos o a Scrum, pero QA a veces queda completamente fuera
- Dado que más del 90% de los egresados trabajará en un contexto empresarial, necesitan la capacidad de entregar software sin errores dentro de plazos definidos
- Tratar QA como algo secundario en la educación no coincide con las exigencias del trabajo real
La estructura que hace que QA sea lo primero en recortarse en las empresas
- Cuando aparecen problemas de presupuesto en un proyecto, los estándares y medidas de QA suelen ser lo primero que se excluye
- Como QA muchas veces se ubica al final del proyecto, si el desarrollo se extiende o aumenta el alcance, queda poco tiempo para asegurar la calidad
- Como resultado, se despliega software con una estructura frágil después de realizar solo pruebas mínimas y poco estructuradas
- Algunos equipos tienen estándares de QA, pero por lo general toman la forma de un miembro senior del equipo imponiéndolos al resto
- Incluso con estándares, si el equipo escribe pruebas solo para cumplir indicadores de gestión del proyecto, es difícil que eso derive en un aseguramiento de calidad suficiente
El primer paso para cortar los problemas de calidad recurrentes
- Señalar que faltan medidas de QA requiere experiencia y confianza
- El crunch previo al release, los sistemas de producción que fallan y el monitoreo ausente terminan siendo una carga para todo el equipo
- Al igual que el refactoring, las mejoras que no son directamente visibles para los managers son difíciles de justificar; y QA puede sentirse todavía más abrumador si no se ha hecho bien antes
- Hay que mencionar el problema repetidamente y volver a abrir la discusión para poder dar el primer paso
Explicar QA en el lenguaje del dinero
- Decir que “el software será más estable” o que “será más fácil de mantener” puede no resultar concreto para quienes no trabajan en el codebase
- Los desarrolladores deben hablar del costo de no hacer QA
- Algunos ejemplos de formulación son:
- Si no lo hacemos ahora, en 4 meses el esfuerzo y el costo de desarrollo aumentarán un 15%
- Si no agregamos pruebas unitarias a todas las funcionalidades, la etapa de estabilización del release será más larga cada vez
- A medida que se agreguen nuevas funcionalidades, habrá que probar manualmente los efectos secundarios cada vez, y el avance disminuirá en cada release
- Este enfoque usa un lenguaje más fácil de transmitir al negocio y a los managers
- En última instancia, las medidas de QA pueden mejorar la vida tanto de desarrolladores como de managers
Empezar con una dosis mínima efectiva
- Si QA se diseña de forma excesiva como una gran inversión inicial, puede bloquear el avance del proyecto y dificultar el acuerdo de los stakeholders
- Un punto de partida realista es identificar la parte más importante de la aplicación
- Por lo general hay un caso de uso, funcionalidad o comportamiento central del que depende toda la aplicación
- Hay que empezar probando las funcionalidades clave que deben funcionar correctamente para aportar valor al cliente
- La dosis mínima efectiva (MED) significa la menor dosis capaz de producir el resultado deseado
- En QA, una MED puede ser una de las siguientes cosas:
- Un plan de pruebas manuales
- Pruebas automatizadas en el pipeline
- Otras medidas que garanticen comportamientos clave
- Después de asegurar las funcionalidades clave, se puede ampliar gradualmente la estabilidad
- Hay que agregar pruebas unitarias con cada nueva funcionalidad y validar también la información que no se puede controlar, como APIs externas o entradas de usuario
- QA también debe mejorarse de forma iterativa y gradual
Preguntas de QA para revisar en un proyecto nuevo
- Al iniciar un proyecto nuevo o sumarse a uno, hay que comprobar si existe algún concepto de QA, aunque sea pequeño
- El equipo debe hacerse estas preguntas:
- Qué estamos desplegando
- Qué debe funcionar sí o sí
- Cómo garantizamos eso
- Qué medidas decidimos no tomar de forma intencional, y por qué
- Documentar esto y sumar un plan de pruebas crea una buena base para que el software pueda avanzar
- Conviene revisar el enfoque elegido periódicamente, por ejemplo cada trimestre
Escribir las pruebas junto con la implementación
- Aunque no se use TDD, se recomienda escribir pruebas mientras se escribe el software
- El momento de implementar una funcionalidad es un buen momento para escribir pruebas
- Escribir las pruebas al mismo tiempo que la implementación obliga a que el código tenga una estructura realmente testeable
- Cuando se agregan pruebas más tarde a software existente, muchas veces queda en evidencia que el código es demasiado interdependiente o que viola el principio de responsabilidad única
- Las pruebas sirven como una explicación de que se entendió el comportamiento deseado y se verificó que funciona como se espera; también funcionan como una forma de documentación del código
Efectos para el proyecto y para cada persona
- Abrir la discusión sobre la calidad y proponer posibles soluciones comunica al entorno que a uno le importa el proyecto
- La discusión sobre calidad puede ampliar el alcance de influencia como desarrollador
- También puede mejorar la calidad de vida de desarrolladores y managers
- Con medidas de QA, el proyecto puede crecer a un ritmo saludable
- No todos tienen que convertirse en embajadores de QA, pero se puede empezar con una pequeña MED y mostrar dentro del equipo una mejor forma de trabajar
1 comentarios
Comentarios de Hacker News
Sí se enseña este tipo de cosas. Solo que no está en las materias troncales de ciencias de la computación, sino más bien en optativas como ingeniería de software
En CMU también hay maestría y doctorado en ingeniería de software, y cubren lo que dice la entrada del blog y más. Hay una gran desconexión entre CS y SE, pero no al grado de que “nadie enseña cómo hacer software de calidad”
Irónicamente, cuando era estudiante era la materia de ingeniería de software que más odiaba. Las clases de patrones de diseño con UML estricto me parecían anticuadas, y la materia de QA donde enseñaban TDD y herramientas del ecosistema Java también me aburría. Años después, cuando me uní a un equipo que construía flujos de trabajo y herramientas de pruebas para software con altos requisitos de seguridad, mis colegas se sorprendieron de que yo ya supiera qué había que hacer
Incluso cuando lo enseñan, normalmente está anticuado o demasiado sesgado hacia cosas muy literales como escribir aplicaciones web. Si hubiera existido una clase enfocada en implementación, trabajo en equipo y construcción de sistemas complejos, de verdad la habría querido tomar
Esto no debería quedar como optativa ni como programa de maestría; hacen falta programas de ingeniería de software a nivel licenciatura, y el 90% de los estudiantes de CS debería pasarse para allá
La base de código era un servicio simple que ofrecía escaneo de virus/malware, y estaba diseñada para que siempre hubiera trabajo adicional por hacer, incluyendo escáneres y firmas. Era una idea de hace más de 15 años, pero da lástima que no haya logrado convencer al departamento, porque pudo haber sido una gran clase continua
Tal vez no fue la clase que definió toda mi licenciatura, pero estuvo muy cerca, y el hecho de que la mayoría de quienes diseñan sistemas no sepan esto me provoca a la vez enojo y terror existencial
Es más fácil trabajar con gente que tiene título en CS porque hace menos falta convencerlos de la necesidad de buenos algoritmos o de que no deberían implementar por su cuenta parsers ni criptografía
En cambio, del lado de ingeniería de software no existe una credencial en la que puedas confiar para asumir que la ingenuidad sobre calidad, trabajo en equipo y colaboración con otros equipos ya fue pulida de forma similar. Aparecen personas entrenadas por la experiencia de escribir rápido código horrible y no validado, e irse antes de que todo explote; a la gerencia le gusta esa gente y desprecia a quienes se quedan después recogiendo los escombros
Los protocolos basados en cadenas con delimitadores claros normalmente son muy fáciles de parsear, y según el caso de uso quizá solo necesites manejar una parte. Claro, hay que considerar las pruebas y los requisitos funcionales. Si estás creando un lenguaje, el consejo podría ser distinto
Los principiantes los hacen a mano, los desarrolladores intermedios y los proyectos de tamaño medio usan generadores de parsers, y quienes mantienen los parsers más sofisticados también suelen preferir escribirlos a mano. GCC antes usaba un parser de bison, pero lo cambió por un parser recursivo descendente escrito a mano para tener mejores mensajes de error, y Clang también usa descenso recursivo
La única excepción que conozco personalmente es jq, y por eso en la implementación de jq es difícil producir mensajes útiles de errores de sintaxis
Escribir un parser puede ser tan simple que cabe en una sola tarea, y el código de un parser hecho a mano al final se parece mucho a una gramática LL. El parsing es la parte más fácil al escribir compiladores o herramientas de lenguaje, así que si un parser hecho a mano es un estándar demasiado alto para tu equipo, entonces quizá todo el proyecto sea cuestionable. No digo que nunca deban usarse generadores de parsers, pero preferiría trabajar en un proyecto con un parser hecho a mano y bien probado que en uno donde el build se complica con herramientas adicionales o donde se usan herramientas viejas como Bison o ANTLR
Aun así, el nivel general parece más alto que hace 20 años. Por ejemplo, control de código fuente, pruebas unitarias y CI/CD ya no son temas polémicos
La premisa de que “hay que entregar software sin errores y a tiempo” es un punto de partida bastante malo para empezar a hablar de software de calidad
Si crees que puedes desplegar código sin errores, es hora de cambiar de profesión
Aunque hagas pruebas unitarias, pruebas de integración y pruebas de aceptación de usuarios, un solo cambio de código ya implica la posibilidad de un bug nuevo. Cuando un desarrollador dice “yo nunca despliego código con bugs”, dan ganas de preguntar más a fondo qué quiere decir
Cuando pasas de “escribí una función”, “probé una función” y “hasta probé una función llamada a través de la red”, terminas dándote cuenta de que, por bien que cubras los casos límite y por muy rigurosa que sea la QA, siempre queda algún comportamiento indefinido 0-day en cierta configuración, cierto hardware o cierto kernel. Solo puedes decir que el software pasó pruebas, revisión humana y code review, así que probablemente tiene muy pocos bugs, y al final no queda más que cruzar los dedos
Si toma una semana arreglarlo, pero solo afecta a unos pocos usuarios en una situación muy rara, puede que no valga la pena corregirlo
Existen programas de ciencias de la computación, y hay universidades que enfatizan pasantías y práctica. Pero muchos departamentos de CS en las universidades vienen de matemáticas y están centrados en la teoría
Así como química no es lo mismo que ingeniería química, eso también me parece bien. La universidad no es solo una escuela vocacional, y la intención de casi cualquier título es entrenar la capacidad de pensar y demostrar que puedes dominar contenidos complejos
Una educación universitaria puramente académica, sin considerar si sirve en la práctica, le hace daño a la enseñanza; pero una educación puramente vocacional que solo enseña métodos sin comprensión tampoco resulta útil. Aun así, las escuelas vocacionales reales tampoco son completamente así: aunque se salten las partes difíciles, suelen dar una comprensión profunda de lo importante
Aun así, sirve para asomarse al mundo profesional del software
Esto se aprende en una buena organización de desarrollo. Hace unos 10 o 15 años, eso era más o menos FAANG; hoy, un ejemplo sería TailScale
Es posible evitar los microservicios inútiles y las capas y capas de Docker, las capas de serialización/deserialización JSON y montones de pruebas unitarias hechas solo para cobertura mientras se ignoran QuickCheck, Hypothesis y el fuzzing. Se puede trabajar con conjuntos de cambios apilados, rotación on-call del equipo que escribe el código, minimizar el enlace dinámico y los errores por dependencias no forzadas, diseñar de acuerdo con el runtime de lenguajes administrados, e incluso exigir como “legibilidad” la sintaxis verbal y fácil de leer del lenguaje. Aunque se ignore una y otra vez, cómo entregar software de calidad es conocimiento público
Puede que tenga ideas sobre software de calidad, pero este comentario es difícil de entender
Quisiera saber qué observar y si hay libros o cursos recomendables
Es difícil llegar a métricas lo bastante válidas como para respaldar afirmaciones del tipo “si no lo hacemos ahora, dentro de 4 meses el esfuerzo y costo de desarrollo aumentarán 15%”
En una startup, dos fundadores me dijeron una vez que “no escribiera pruebas unitarias”. No discutí, y entendí que lo que realmente querían decir era que íbamos demasiado lento y había que desplegar lo más rápido posible. Desplegué rápido, mantuve la calidad y también escribí pruebas unitarias. Ellos no necesitaban saberlo; solo necesitaban resultados. El punto oculto en esta discusión es que la mayoría de las organizaciones de software no saben cómo desplegar rápido y con calidad al mismo tiempo. No existe una fórmula mágica: se necesita oficio individual, y también es un deporte de equipo. Cada contexto es distinto, así que algunos procesos ligeros pueden funcionar en cierta medida, pero su efecto es limitado. Al final, hacen falta buenos equipos con experiencia, valores correctos y la sabiduría de enfocarse en entregar valor
La idea de que la universidad enseña a hacer software para la industria es una afirmación bastante atrevida
Además, este texto parece escrito en los 90, cuando el software se distribuía en CD o disquetes. Hoy en día, los pipelines de despliegue continuo muchas veces difuminan el concepto mismo de “release”, y eso se considera una buena práctica. En ese contexto, la idea de que un departamento de QA garantice manualmente que una release no tiene bugs suena bastante anticuada
También hay gente que hace código que se envía en dispositivos donde actualizar no es tan fácil
Si necesitas la aprobación de alguien, tienes que explicarle por qué es una buena idea
Decir “es más estable” o “será más fácil de mantener” no le dice mucho a alguien que no trabaja directamente en el codebase. Los desarrolladores tienen que hablar en términos del costo de no hacer QA, es decir, en el lenguaje del dinero. Aunque “¡pero esta es la manera correcta de hacerlo!” se sienta como un argumento irrefutable, puede que a la persona que aprueba no le importe esa corrección. Este principio aplica no solo a arreglar software correctamente, sino a casi todo en el trabajo
Si tienes que explicar por qué la calidad importa, entonces están al menos tan desinformados como uno, o quizá más. Ese tipo de organizaciones debería aceptar su propio destino. En cambio, en una empresa madura te recompensan más y más rápido, y también desarrollas antes un sentido de cómo debería funcionar un negocio. Claro, tú mismo tienes que demostrar que el tiempo invertido realmente produce mejoras, y que no se trata de un impulso quijotesco de aficionado
De forma aproximada, solo puedes tener tres de estas cuatro cosas: calidad, poco tiempo, baja complejidad de comunicación y poco dinero; aquí el tiempo está más cerca de ser una variable dependiente
La gente intenta aplicar a un trabajo en equipo y de ingeniería como el software procesos y estructuras de tipo fábrica. Así como no se enseña ni se forma a un equipo de básquet dividiendo el ataque en procedimientos por etapas y casillas de verificación, hay que minimizar la comunicación y hacer que el equipo se mueva como una sola unidad. Esto no se trata de construir procesos, sino de formar equipos e individuos. Hay que hacer planes, pero como decía Moltke, no existe un plan de operaciones que siga intacto después del primer contacto con el enemigo. Sin embargo, la mentalidad empresarial cree que, si el plan no salió como se esperaba, hay que agregar más procesos, y así en el siguiente fracaso el gerente puede culpar a individuos. Los procesos tienen su lugar para hacer que el trabajo ocurra dentro de marcos legales y morales, y para reducir escenarios extremos como apostar por error todo el capital de un hedge fund durante las pruebas. Pero en la mayoría de startups y empresas se usan de una manera que no pone al equipo en el centro
A un arquitecto tradicional no se le grita preguntándole cuándo va a terminar. Normalmente termina cuando el cliente queda satisfecho o toma una decisión. Mucho del desarrollo también se parece a eso
Me pregunto si existe alguna actividad humana que enseñe con éxito ese atributo llamado calidad
Por experiencia, la capacidad de producir algo de calidad solo se obtiene con práctica, práctica y práctica
En cambio, el título solo quiere decir que programar no es una práctica industrial. Debería ser evidente para quien lo haya observado con atención, pero algunos se niegan a verlo hasta el final
Basta ver la escritura: mucha gente aprende a mejorar la calidad. Se les orienta sobre qué escribir y, más importante aún, sobre cómo revisar y mejorar la calidad de lo que acaban de escribir
La práctica siempre ayuda, pero la calidad también es algo que mucha gente aprende y desarrolla
Cuando aprendes a volar, aprendes los estándares, pero con el tiempo te enseñan a estrechar los márgenes permitidos. Por ejemplo, si en un viraje pronunciado el criterio de altitud es ±100 pies, eso es el mínimo; se apunta a 50 pies, 20 pies, y luego a que la aguja ni se mueva. La meta es “mejor, siempre mejor, ¿qué puedo hacer mejor?”, y en vuelo no se aprueba por promedio general, sino cumpliendo en todos los rubros. Culturalmente, “satisfactorio” no es el final, sino el punto de partida
Siento que esta actitud crea un modelo mucho más colaborativo. En aviación, todos quieren sinceramente que todos tengan éxito, y si alguien falla, uno mismo también tiene parte de responsabilidad. Si alguien cometía un error, la cultura era buscar cómo reducir la posibilidad de errores futuros, y en las aerolíneas también jugaba un papel importante la garantía de calidad de operaciones de vuelo (FOQA). En organizaciones pequeñas que operaban en zonas remotas era más informal, pero en la mayoría de los casos se acercaba a una cultura de “sin culpa”, y la clave era “¿cómo lo hacemos mejor?”
La calidad, la toma de decisiones y “hacer lo correcto” eran el núcleo de la cultura de la aviación. En un operador con buena reputación, concluir que el clima es demasiado malo para hacerlo con seguridad lleva directamente a cancelar la operación, y no a salir forzando las cosas para terminar el trabajo. La industria tecnológica a la que entré después se siente como lo contrario. El mero concepto de producto mínimo viable ya muestra el problema. No debería ser “mínimo viable”, sino “producto con la calidad mínima aceptable como punto de partida”. No hay que apuntar al mínimo; el mínimo es solo el comienzo
Si solo practicas hacer basura, lo único que lograrás es volverte hábil haciendo basura. De hecho hay personas a las que no les importa la calidad, y en esos casos todas las premisas se vienen abajo