Su navegador no soporta JavaScript. Google Automation of my QA Strategy - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS
En mis propias empresas y en las empresas de Openview Venture Partners a las que asesoro, he comprobado sistemáticamente que la implementación cuidadosamente priorizada de pruebas de aceptación produce una mayor calidad más rápidamente que cualquier otra cosa que haya visto.Una Open-E en Polonia implementó la integración continua e inmediatamente aumentó la velocidad de más de 50 desarrolladores en 20%. El siguiente paso fue mejorar la calidad de su software de servidor de almacenamiento de red de código abierto para que pudiera ser lanzado más rápido con menos problemas de soporte. El software tenía que funcionar en 80 plataformas de hardware diferentes y necesitaba pruebas de aceptación exhaustivas por parte de un equipo de control de calidad después de que el desarrollo hubiera completado una versión. Esta fase de pruebas de aceptación llevaba entre 4 y 6 semanas por versión.

Les dije que proritizaran los problemas encontrados por el equipo de control de calidad e implementaran pruebas en el proceso de compilación para evitar que estos problemas volvieran a aparecer. Después de tres semanas de trabajo de un desarrollador, se ejecutaron 130 pruebas en el proceso de compilación. En el siguiente ciclo de lanzamiento, el control de calidad se redujo a 2 semanas y las llamadas de asistencia sobre el terreno se redujeron en 50%, lo que supuso un ahorro de millones de euros en tiempo de desarrollo y un aumento de las ventas de millones de euros. No he visto nada que funcione mejor que esto.

Google ha desarrollado una brillante estrategia automatizada llamada "Predicción de fallos" que hace esencialmente lo mismo. Parece que todos los equipos deberían hacer algo así.

Predicción de errores en Google

¿Cuál es el problema?

En Google, miles de ingenieros trabajan a diario en nuestra base de código. De hecho, como anteriormente señalado50% de la base de código de Google cambia cada mes. Eso es mucho código y mucha gente. Con el fin de garantizar que nuestra base de código se mantiene saludable, Google emplea principalmente pruebas unitarias y revisión de código para todas las nuevas entradas. Cuando un fragmento de código está listo para su presentación, no sólo deben pasar todas las pruebas actuales, sino que también deben escribirse nuevas pruebas para cualquier funcionalidad nueva. Una vez que las pruebas están en verde, el revisor de código se abalanza para asegurarse de que el código está haciendo lo que se supone que debe hacer, y estampa el legendario "LGTM" (Looks Good To Me) en la presentación, y el código puede ser registrado.

Sin embargo, los Googlers trabajan cada día en problemas cada vez más complejos, proporcionando las funciones y la disponibilidad de las que dependen nuestros usuarios. Algunos de estos problemas son necesariamente difíciles de abordar, lo que da lugar a un código inevitablemente difícil. A veces, ese código funciona muy bien y se despliega sin incidentes. Otras veces, el código crea problemas una y otra vez, a medida que los desarrolladores intentan resolverlos. Por el bien de este artículo, llamaremos a esta segunda clase de código "puntos calientes". Tal vez un punto caliente es resistente a las pruebas unitarias, o tal vez un conjunto muy específico de condiciones puede hacer que el código falle. Por lo general, nuestros diligentes, experimentados e intrépidos revisores de código son capaces de detectar cualquier problema y resolverlo. Dicho esto, todos somos humanos, y los errores furtivos todavía son capaces de colarse. Nos hemos dado cuenta de que puede ser difícil darse cuenta de cuándo alguien está cambiando un punto conflictivo frente a un código generalmente inofensivo. Además, a medida que aumenta el tamaño de la base de código y de los equipos de Google, es más improbable que el remitente y el revisor sean conscientes de que están modificando un punto conflictivo.

Para ayudar a identificar estos puntos conflictivos y advertir a los desarrolladores, nos fijamos en la predicción de fallos. La predicción de fallos utiliza el aprendizaje automático y el análisis estadístico para tratar de adivinar si un fragmento de código es potencialmente defectuoso o no, normalmente dentro de un cierto margen de confianza. Las métricas basadas en el código fuente que podrían utilizarse para la predicción son cuántas líneas de código, cuántas dependencias son necesarias y si esas dependencias son cíclicas. Pueden funcionar bien, pero estas métricas van a marcar nuestro código necesariamente difícil, pero por lo demás inocuo, así como nuestros puntos calientes. Sólo nos preocupan nuestros puntos calientes, así que ¿cómo los encontramos? Bueno, en realidad tenemos un gran registro fidedigno de dónde ha estado el código que requiere correcciones: ¡nuestro rastreador de errores y nuestro registro de commits de control de código fuente! La investigación (por ejemplo, FixCache) indica que la predicción de errores a partir del historial de fuentes funciona muy bien, por lo que decidimos implantarlo en Google.

Para más información, pulse aquí ...

es_ARSpanish
Acciones