Repasando un ppoco las charlas de este año de la EclipseCon 2007 (ya ha llovido) me he encontrado con una bastante interesante de Sonia Dimitrov y Kim Moir donde hablaron sobre todo el proceso de QA que se sigue en Eclipse.

Se extraen varias cosas interesantes:
- Tienen el rol de build engineer para proteger a los desarrolladores del proceso de build (este rol merece un post en si mismo).
- 176.000 tests en 33.000 JUnit tests ejecutándose en cinco build machines con máquinas virtuales 1.4, 1.5 y 1.6.
- 469 tests de rendimiento con 2345 tests que se ejecutan en cinco máquinas diferentes. Se ejecutan sólo unos cuantos días debido a que lleva unas 10 horas ejecutar los tests y procesar los resultados.
- Para asegurarse la validez de los tests de rendimiento utilizan imágenes ghost que instalan justo antes de lanzar los tests.
- Tienen un conjunto de tests de limpieza. Chequean que todo esté correcto: javadocs, licencias, políticas de código, etc.
- Los desarrolladores escriben test unitarios, pero el código de los tests se mantiene separado en un CVS propio.
- Los resultados de los tests de rendimiento se almacenan en una base de datos dedicada.
- Para detectar fallos tienen un parser que analiza la salida de los tests y en caso de errores genera reportes y los envia a una lista de correo.
- La mayor parte de los errores que obtienen no se deben en realidad a errores en el código sino a problemas con las máquinas, poco espacio en disco, actualizaciones de software, antivirus, etc.
No sé que os parece, pero a mi me ha sorprendido especialmente toda la infraestructura dedicada al testing, incluido el dedicar un CVS específicamente para el almacenar el código de los tests. Está claro que toda esta infraestructura y este proceso tan elaborado debe tener algo que ver con la capacidad para estar lanzando versiones sin retraso durante cinco años.