Hay un interesante y largo artículo en Ars Technica donde al hilo de los últimos problemas en la actualización periódica de Windows 10 se abordan cuestiones muy interesantes.
En él se explica qué Microsoft plantea que Windows 10 sea la última gran versión de Windows, a la que ir añadiendo funcionalidad en un par de nuevas releases al año. De esta forma, en lugar de sacar una versión del sistema cada tres años, los usuarios reciben mejoras incrementales y nueva funcionalidad dos veces al año.
Hasta aquí nada que deba sorprendernos por aquí, ya que es el sistema usado por Canonical con Ubuntu desde 2004. Es un paso adelante en la entrega ágil de funcionalidad, y eso nos encanta en este blog. 100% de acuerdo con este enfoque.
Volviendo al artículo, aunque todo él es interesante (recomiendo leerlo), me llama hoy la atención sobre todo la sección donde se habla de las pruebas de integración del nuevo código:
A reasonable expectation is that Microsoft would have a set of tests around this new code to verify that it works correctly: (…) in any kind of respectable agile development process, there will be tests to verify all the operations work as expected, and make sure that the API does what it’s supposed to do.
Moreover, one would expect any code change that broke those tests to be rejected and not integrated. The code should be fixed, and it should pass its tests, before it’s ever merged into the main Windows code—much less shipped to beta testers.
Y, sin embargo, eso es precisamente lo que sucedió: el código llegó a los usuarios con bugs realmente graves que han provocado pérdida irreversible de datos en multitud de sistemas. Solo hay dos opciones: o no se está probando bien el código o se está integrando código que no pasa los tests por el motivo que sea (¿quizá el equipo de desarrollo no considera ciertos fallos como suficientemente graves?). Ninguna de las dos suena muy razonable dada la envergadura de la metedura de pata mencionada en este mismo párrafo, con sistemas borrando datos sin remedio.
Esta situación no es achacable al uso (bueno o malo, está por ver) de metodologías ágiles para desarrollar Windows, ya que en el viejo esquema de una actualización cada tres años era habitual esperar a los Service Pack para que el sistema fuera realmente sólido. Sin embargo, en un mundo sin service packs y con releases semestrales, la mayor parte del tiempo los usuarios conviven con un sistema inestable, a menos que pulas mucho tu proceso.
Acerca de los procesos de I&V, continúan en Ars Technica:
Many of these testers [who were working in Windows] were laid off or reassigned in 2014, with the idea that more of the testing burden be shifted to the developers creating the features in the first place. The Windows Insider program also provides a large amount of informal testing—with many millions of members, it’s much bigger than any of the Windows beta programs ever were.
It’s not certain that the old approach would have necessarily caught the data loss bug; perhaps the dedicated testers wouldn’t have tested the particular scenario needed to cause data to be deleted. But it is clear that Microsoft is struggling to handle the bug reports made by the non-expert testers in the Insider program.
Y llegamos al meollo del asunto: el debilitamiento de la función de I&V dentro del proyecto y la externalización de las pruebas en el usuario final. Tampoco es algo que no nos suene, al fin y al cabo, ¿quién no ha pasado una etapa de su vida viviendo al límite con una estación de trabajo en Debian Sid? :)
El problema es que Microsoft es un producto comercial, cuya base de usuarios es generalista. No creo que el software pueda ser testeado mayoritariamente por usuarios finales, pero si hay un software que no pueda delegar la realización exhaustiva de pruebas en sus usuarios es precisamente software de uso general como Windows.
Si Microsoft está teniendo problemas seguramente deba introducir mucha más automatización en sus sistemas de integración y verificación. En realidad, algo que debería haber sido condición previa a esa reasignación de testers en otras funciones.
Tener feedback de usuarios, informes de error y uso general del software, es importante y valioso. Sin duda es algo que permite mejorar el software que se entrega, pero el grueso del testeo no puede recaer sobre estos usuarios. Si recae sobre ellos, aunque lo llamemos beta, o incluso release, les estamos entregando una alfa.
Se puede hablar mucho más de este tema y de este caso concreto, pero creo que por ahora yo me quedo aquí: no puedes delegar el testeo en el usuario final y si no te está dando tiempo a testear adecuadamente la solución no es huir hacia adelante (mergear sin probar) sino buscar formas de automatizar más y mejor los procesos de integración y verificación.
