Votre navigateur ne supporte pas JavaScript ! Google Automation of my QA Strategy - Scrum Inc.
  • LinkedIn
  • YouTube
  • RSS
J'ai toujours constaté, dans mes propres entreprises et dans celles d'Openview Venture Partners que j'encadre, qu'une mise en œuvre soigneusement hiérarchisée des tests d'acceptation produit une qualité supérieure plus rapidement que tout ce que j'ai pu voir. L'étape suivante consistait à améliorer la qualité de leur logiciel de serveur de stockage en réseau open source afin qu'il puisse être publié plus rapidement avec moins de problèmes d'assistance. Le logiciel devait fonctionner sur 80 plates-formes matérielles différentes et nécessitait des tests d'acceptation approfondis par une équipe d'assurance qualité après la fin du développement d'une version. Cette phase de test d'acceptation prenait de 4 à 6 semaines par version.

Je leur ai demandé de classer par ordre de priorité les problèmes rencontrés par l'équipe d'assurance qualité et de mettre en œuvre des tests dans le processus de construction afin d'éviter que ces problèmes ne se reproduisent. Après trois semaines de travail d'un développeur, 130 tests ont été effectués dans le processus de construction. Le cycle de publication suivant a réduit l'assurance qualité à 2 semaines et les appels d'assistance sur le terrain ont diminué de 50%, ce qui a permis d'économiser des millions d'euros en temps de développement et de générer des millions d'euros d'augmentation des ventes. Je n'ai jamais rien vu qui fonctionne mieux que cela.

Google a développé une brillante stratégie automatisée appelée "Bug Prediction" qui fait essentiellement la même chose. Il semble que chaque équipe devrait faire quelque chose comme ça.

La prédiction des bogues chez Google

Quel est le problème ?

Chez Google, des milliers d'ingénieurs travaillent chaque jour sur notre base de code. En fait, en tant que noté précédemmentChaque mois, 50% de la base de code de Google sont modifiés. Cela représente beaucoup de code et beaucoup de personnes. Afin de s'assurer que sa base de code reste saine, Google utilise principalement des tests unitaires et une révision du code pour tous les nouveaux check-ins. Lorsqu'un morceau de code est prêt à être soumis, il faut non seulement que tous les tests en cours soient réussis, mais aussi que de nouveaux tests soient rédigés pour toute nouvelle fonctionnalité. Une fois que les tests sont au vert, l'examinateur du code s'assure que le code fait ce qu'il est censé faire et appose le légendaire "LGTM" (Looks Good To Me) sur la soumission, et le code peut être enregistré.

Cependant, les Googlers travaillent chaque jour sur des problèmes de plus en plus complexes, fournissant les fonctionnalités et la disponibilité dont dépendent nos utilisateurs. Certains de ces problèmes sont nécessairement difficiles à appréhender, ce qui conduit à un code inévitablement difficile. Parfois, ce code fonctionne très bien et est déployé sans incident. D'autres fois, le code crée des problèmes encore et encore, à mesure que les développeurs tentent de résoudre le problème. Pour les besoins de cet article, nous appellerons cette deuxième catégorie de code "points chauds". Il se peut qu'un point chaud résiste aux tests unitaires, ou qu'un ensemble de conditions très spécifiques conduise le code à l'échec. En général, nos réviseurs de code diligents, expérimentés et intrépides sont en mesure de repérer les problèmes et de les résoudre. Cela dit, nous sommes tous humains et des bogues sournois peuvent toujours se glisser dans le code. Nous avons constaté qu'il peut être difficile de savoir si quelqu'un modifie un point sensible ou un code généralement inoffensif. En outre, à mesure que la base de code et les équipes de Google augmentent en taille, il devient de plus en plus improbable que l'auteur et le réviseur soient conscients qu'ils modifient un point sensible.

Afin d'identifier ces points chauds et d'avertir les développeurs, nous avons étudié la prédiction des bogues. La prédiction de bogues utilise l'apprentissage automatique et l'analyse statistique pour essayer de deviner si un morceau de code est potentiellement bogué ou non, généralement dans un certain intervalle de confiance. Les mesures basées sur la source qui pourraient être utilisées pour la prédiction sont le nombre de lignes de code, le nombre de dépendances nécessaires et le caractère cyclique de ces dépendances. Ces mesures peuvent donner de bons résultats, mais elles vont signaler notre code nécessairement difficile, mais par ailleurs inoffensif, ainsi que nos points chauds. Nous ne nous préoccupons que de nos points chauds, alors comment les trouver ? En fait, nous disposons d'un excellent registre faisant autorité sur les endroits où le code a nécessité des corrections : notre système de suivi des bogues et notre journal de validation du contrôle du code source ! La recherche (par exemple, FixCache) indique que la prédiction des bogues à partir de l'historique des sources fonctionne très bien, nous avons donc décidé de le déployer chez Google.

Pour plus de détails, cliquez ici ...

fr_FRFrench
Actions