Un résumé de l'ouvrage "How Google Tests Software" aux éditions Addison Wesley, par James Whittaker, Jason Arbon, Jeff Carollo.
James Wesley a été responsable des tests pour Chrome, Google Desktop et Chrome OS. Il sait ce qu'une campagne de test signifie. Voilà comment il présente la problématique du test chez Google:
"Tester à l'échelle de Google: Des centaines de millions de lignes de code, distribuées au travers de milliards de fichiers. Des millions de fonctionnalités contrôlées par des millions de tests lancés quotidiennement. Des applications en évolution continue. En vérité, on aura du mal à trouver plus complexe !"
Chez ogYs, nous travaillons au quotidien aves les outils Google App et Chrome. Ces deux logiciels ont des points communs:
* Ils sont utilisés chaque jour par des centaines de millions d'utilisateurs
* Ils sont en évolution permanente
Comment fait Google pour assurer une qualité de service constante dans ce contexte global, confronté à d'innombrables contraintes ? L'ouvrage "How Gooogle Test Software" nous apporte un éclairage sur la maniière dont Google teste ses futures versions.
L'ouvrage comporte plusieurs parties:
* Présentation de la problématique* Présentation de l'organisation et des méthodes mise en place pour les tests
* Interview de quelques testeurs Google
Problématique
Le test d'une application "globale" comme Google Apps nécessite parfois une réflexion pousée et une certaine imagination. Par exemple l'auteur cite un testeur ayant pour charge de tester aux limites une fonction qui compte le nombre de mots comportant un caractère "a". Cette personne à eu l'idée de tester la fonction sur l'index Google: Si le résultat est correct il doit être d'un ordre de grandeur similaire à celui du nombre de mots. La fonction a donc pu être testée sur un index de plusieurs centaines de milliards de mots !Organisation et méthodes
L'auteur décrit longuement les 2 profils clé agissant en qualité de testeur au sein de Google:1/ Le "SET" pour Software Engineer in Test
2/ Le "TE" pour Test Engineer
1/ Le SET a un profil de développeur. Il passe plus de la moitié de son temps en développement. Il intervient en support aux "Software Engineer" (ceux qui développent les nouvelles fonctionnalités) pour leur apporter les outils leur permettant d'automatiser les tests. Parfois c'est le SET lui même qui développe les tests automatisés. D'une manière générale, comme il y a peu de "SET", il ne peuvent pas tout développer eux même, c'est donc le rôle du développeur de prendre sur son temps pour automatiser les tests nécessaires au contrôle des fonctions qu'il développe.
2/ Le "Test Engineer" intervient en fin de cycle. Il ne fait presque pas de programmation, son rôle est de se mettre à a place de l'utilisateur final pour vérifier que le comportement du logiciel reste compréhensible quel que soit le scénario d'utilisation. Dans le cas d'intégration des fonctions (par exemple intégration de Google + à GMail), les scénarions peuvent être très variés et demandent une certaine imagination.
Déroulement des tests
Google maintient des environnements de test représentatifs de la réalité des données. Sur ces environnements de test, les futures version sont livrées en continu par les développeurs, via un système automatisé de livraison et de gestion des version. Les tests, automatisés, passent en permanance, jour et nuit, sur ces environnements. Si un test automatisé abouti à une erreur, un mail est envoyé automatiquement au développeur (Software Engineer) ayant la charge de cette fonctionnalité. Autrement dit la recette automatisée, les tests aux limites, sont déroulés 24h/24 sur les infrastructures de test Google.Synthèse
Pour assurer le meilleur niveau de qualité à ses logiciels, Google met en application les principes suivants:* La qualité doit d'abord être celle du développeur. La qualité d'un logiciel doit être intrinsèque, prise en compte au plus bas niveau, jusque dans le moindre détail. Au développeur de concevoir et de réaliser des développements en prenant en compte les cas aux limites. A lui d'assurer une livraison de qualité pour ne pas faire perdre beaucoup de temps à beaucoup de monde par la suite.
* Le Software Engineer in Test (SET) est là pour aider le développeur à automatiser les tests. Il lui donne des outils, réalise certains programmes lui même, développe de nouveaux outils qui seront utiles aux développeurs pour automatiser d'autres tests.
* Le Test Engineer (TE) intervient uniquement sur les scénarios fonctionnels, ceux qui ne peuvent pas être automatisés de part leur variété.
* La pénurie de main d'oeuvre est organisée, pour ne jamais avoir une armée de testeurs dédiés à un projet. La période d'intervention des testeurs doit être gérée avec finesse : Trop tôt ou trop tard, la valeur ajoutée sera beaucoup moins importante.
D'une manière générale, la consigne pour les testeurs (SET et TE) est d'apporter leur valeur ajoutée au projet, et ne surtout pas se comporter en simple organe de contrôle qualité.
La lecture des interviews en fin d'ouvrage est assez réjouissante, on y découvre des salariés heureux de leur métier. Ceci est d'autant plus appréciable et intéressant que l'activité de testeur n'est pas toujours la plus valorisée.
