Gestion des tests et de la qualité

Les tests unitaires

Les tests unitaires constituent la charnière entre l’équipe de développement et l’équipe de test. Leur fonction est de vérifier le fonctionnement de chaque élément d’une fonction selon sa description dans les spécifications détaillées. Pour que le développeur puisse communiquer son code à l’équipe de test, il faut qu’il fonctionne raisonnablement bien. C’est avec les tests unitaires que l’on garantit que les rôles sont effectivement respectés entre les équipes de test et de développement. Le développeur accompagne ses productions jusqu’à un point où leur fonctionnement est correct à ses yeux. Pour y parvenir, il doit vérifier lui-même par des tests unitaires que sa réalisation respecte les spécifications détaillées. Il est inutile que les livrables soient échangés plusieurs fois entre les équipes de développement et de test avant de parvenir à couvrir les fonctionnements de base décrits dans les cas d’utilisation. Ces échanges répétés entraînent une perte importante de productivité et des tensions entre les équipes de développement et de test. Les plannings dérapent, et les équipes de développement voient leur production renvoyée pour correction un grand nombre de fois. Ces échanges créent de surcroît des tensions entre les collaborateurs, qui voient leurs plannings glisser et réalisent qu’ils ne pourront tenir leurs engagements. L’équipe de développement doit effectuer elle-même les tests unitaires visant à vérifier que le produit qui sera livré aux équipes de test correspond aux fonctionnalités attendues. Pour ce faire, elle dispose de cahiers de test unitaire comportant des jeux de données stables et adaptés, précisant la nature des tests qui doivent être réalisés. Le développeur ne considère sa production livrable aux tests que si elle a passé avec succès les tests unitaires. Le fait de les réaliser lui-même lui permet de corriger rapidement les dysfonctionnements. L’équipe de test qui reçoit un livrable s’attend à un niveau de qualité assez élevé. Il faut que le développeur soit réellement motivé pour livrer la meilleure qualité qu’il peut Livre Offshore.book Page 270 Lundi, 21. février 2005 7:44 19 Chapitre 13 – Gestion des tests et de la qualité 271 atteindre. Certaines équipes en offshore donnent des bonus aux développeurs selon le faible nombre d’anomalies détectées par l’équipe de test afin de favoriser une qualité optimale entre les tests et les développements. Le développeur reçoit une prime pour la qualité de sa livraison, et le testeur pour sa capacité à trouver les anomalies. Le résultat des tests est consigné dans un tableau indiquant quels tests ont été exécutés et leurs résultats. La première tâche du testeur est d’exécuter les tests unitaires sur sa plate-forme de test afin de vérifier que le développeur a atteint le niveau de qualité minimal permettant de commencer les tests. Si le client choisit de ne pas monter une équipe de test chez le prestataire et d’assurer luimême les tests localement, la formalisation des tests unitaires qui était déjà fortement souhaitable, devient incontournable. EN RÉSUMÉ Tests unitaires et productivité Les tests unitaires vérifient le comportement d’une fonction. Pour assurer une meilleure efficacité des équipes de test et de leurs échanges avec les équipes de développement, il faut convenir d’un niveau de qualité minimal des éléments livrés par les développeurs aux testeurs. Les développeurs assurent la réalisation des tests unitaires avant de transmettre leur production aux équipes de test. Les tests unitaires sont décrits formellement par des cas de test préparés par les équipes de test ou par les chefs de produit et sont accompagnés d’un jeu de test représentatif de tous les cas à tester. On garantit ainsi que le niveau minimal de qualité attendu par les testeurs est assuré par les équipes de développement.

Les tests fonctionnels

Les tests fonctionnels ne peuvent être correctement réalisés que si l’on dispose de spécifications détaillées, complètes et à jour. Les modifications des spécifications et les ajouts doivent faire l’objet d’une mise à jour immédiate des documents de référence. L’IHM est également construite à partir des documents de référence, souvent à l’aide d’une boîte à outils permettant d’appliquer une normalisation. Les tests sont construits sous forme de plans de test que l’on peut demander aux équipes en offshore d’élaborer en s’appuyant sur les spécifications ou les règles de l’IHM. On essaie ainsi de couvrir toutes les actions et de vérifier le comportement du produit, d’abord avec des tests positifs (le produit assure-t-il le service qu’il est censé rendre ?) puis avec des tests négatifs (le produit gère-t-il toutes les erreurs qui peuvent se produire ?). Les tests sont naturellement placés sous la supervision du chef de produit, qui en apprécie la qualité et l’exhaustivité. À chaque itération, un point complet est effectué sur les livraisons. L’état d’avancement du produit est entièrement testé afin d’évaluer sa qualité. On peut aussi essayer de viser une intégration continue avec un build quotidien, bihebdomadaire ou hebdomadaire. L’équipe de test s’inquiète en permanence du niveau de qualité du produit. À chaque build, le testeur cherche à savoir quel est l’état de qualité de chaque fonction, puisqu’elle est potentiellement modifiée.  Si les développeurs n’ont pas modifié le code source de la fonction depuis qu’elle a été testée, on peut supposer que les résultats antérieurs sont toujours valides, sans toutefois pouvoir en être certain. Il se peut que cette fonction fasse appel à d’autres services, qui ont eux été modifiés ou qui contiennent depuis peu des anomalies. On peut aussi avoir fait une correction mineure, théoriquement bénigne et parfaitement circonscrite, qui engendre des anomalies majeures inattendues dans d’autres parties du produit. Il se peut encore que la fonction ait subi des régressions sans que les causes en soient évidentes. On ne peut vraiment connaître l’état de qualité d’une fonction qu’en la testant entièrement. Plus les tests sont anciens, et moins les résultats obtenus lors de ces tests sont fiables quant au dernier build. Le test d’une fonction est long et répétitif, et il est pratiquement impossible de réaliser manuellement tous les tests à chaque intégration, surtout si celles-ci ont lieu très fréquemment. Il faut recourir aux tests automatisés pour qualifier les builds quotidiens ou bihebdomadaires. Les tests minimaux, ou MAT Il est recommandé de séparer les tests fonctionnels en deux niveaux de test, les tests profonds, qui correspondent à des tests complets de toutes les fonctionnalités, et les tests rapides, ou MAT (Minimal Acceptance Test), qui couvrent succinctement une série de fonctions essentielles. Il faut généralement plusieurs jours à l’équipe de test pour réaliser les tests complets, alors que les MAT sont davantage limités dans le temps. L’idéal est de les exécuter en deux heures. S’ils sont automatisés, on peut aller plus loin dans leur exécution que s’ils sont réalisés manuellement. Les MAT n’étant pas exhaustifs, ils ne peuvent garantir pleinement le fonctionnement du produit. Ils se concentrent sur les scénarios d’utilisation les plus importants et les plus utilisés par les clients. Ces tests légers peuvent être réalisés rapidement lorsqu’on souhaite s’assurer d’un niveau de qualité minimal ou qu’il n’y a pas de régression majeure évidente. Un MAT est construit de façon à couvrir l’effet d’une action au minimum sur tous les modules et tous les aspects techniques de l’application. Au moins une utilisation de tous les composants est testée, ainsi qu’au moins un accès à tous les outils de middleware, de façon à détecter, par exemple, l’absence de déploiement d’un fichier. Le MAT est utilisé chaque fois que l’on doit vérifier rapidement que le produit fonctionne correctement et qu’on n’a pas le temps de le tester totalement. On utilise le MAT pour valider que le livrable reçu par l’équipe de test fonctionne, par exemple quand on doit livrer un patch ou des Hot Fix. Il permet en outre de vérifier qu’un déploiement est correct, puisqu’il est censé utiliser au moins une fois tous les aspects techniques du produit, et donc tous les fichiers, tous les éléments du middleware et tous les types d’interactions avec l’extérieur. Les MAT sont une série de tests très importants, que l’on a tout intérêt à automatiser afin d’en augmenter l’étendue. Ils doivent être exécutés le plus souvent possible, parfois sur une même version mais sur des plates-formes différentes. Ils peuvent alors faire office de tests de validation de déploiement et servir de référence tout au long du travail avec l’équipe distante. Livre Offshore.book Page 272 Lundi, 21. février 2005 7:44 19 Chapitre 13 – Gestion des tests et de la qualité 273 EN RÉSUMÉ Tests profonds et tests minimaux Les tests profonds permettent de juger de l’état de qualité d’un produit dans son intégralité selon un plan de test complet. Ces tests très longs ne peuvent être effectués sur tous les builds. Ils ne conviennent donc pas lorsqu’on doit livrer une version rapidement. Les tests minimaux, ou MAT (Minimal Acceptance Test), couvrent succinctement tout le produit, en tentant de se concentrer sur les scénarios les plus importants. Les MAT sont généralement automatisés. Utilisés pour toutes les recettes rapides visant à estimer l’état de qualité du produit ou à détecter les régressions majeures, ils peuvent également servir à valider le déploiement sur une plate-forme.

Les tests fonctionnels transversaux

Les procédures décrites précédemment cloisonnent fortement les tests par fonction et par module, toute l’organisation étant structurée par composant. De son côté, l’utilisateur s’intéresse avant tout à des tests métier, qui sont transversaux et suivent son cheminement à travers des séries d’actions faisant appel aux différents modules de l’application. Il se peut que deux modules soient communément utilisés ensemble, par exemple, la mise à jour d’une information doit être reprise dans un tableau synthétique faisant partie d’un autre module. Le cloisonnement par module peut faire que l’on ne teste jamais ces croisements de mises à jour. Les tests transversaux visent à combler ces défaillances. Ils sont souvent organisés sous forme de scénarios métier, dans lesquels on accompagne les actions d’un utilisateur final à travers un cheminement sur plusieurs modules. Si nous insistons ici sur un sujet qui peut paraître évident c’est qu’il est une source récurrente de problèmes avec l’offshore lorsqu’on met en place une méthodologie industrielle pour la première fois. On a alors tendance à se concentrer sur des tests très structurés, et l’on en oublie la vision d’ensemble. Lorsqu’on met un produit testé par fonction entre les mains d’un utilisateur final, des anomalies majeures sont souvent trouvées dès les premières minutes d’utilisation, qu’il était impossible de détecter lors des tests de fonction. La confiance s’effondre alors rapidement, surtout si l’on a affirmé que le produit était bien testé, fort des nombreux tests cloisonnés effectués. Comme les tests par module et par fonction, les tests transversaux doivent être assurés et renseignés dans des Acceptance Sheets. Les scénarios sont beaucoup plus difficiles à réaliser, car ils peuvent être très nombreux. Les chefs de produit sont particulièrement Livre Offshore.book Page 274 Lundi, 21. février 2005 7:44 19 Chapitre 13 – Gestion des tests et de la qualité 275 sollicités pour donner une réalité métier à ces tests. Lorsque les utilisateurs fi nals rencontrent de nouvelles anomalies, ces cas de test sont ajoutés aux tests transversaux. Les tests transversaux sont structurés et documentés. Ils sont en outre reproductibles.

 Les tests intuitifs 

Les tests intuitifs sont des tests qui ne sont pas formalisés. On y fait ce que l’on veut pour détecter des anomalies selon son intuition ou son expérience. Les tests formalisés ne peuvent en effet tout prévoir. Par exemple, il est possible que l’on ne prévoie pas de tester formellement la couleur du fond d’écran, bien qu’elle soit définie dans la charte graphique du projet. Une erreur sur la couleur de l’écran est pourtant immédiatement visible de tout utilisateur. C’est un des défauts que l’on attribue très souvent aux équipes en offshore. On dit qu’elles suivent les procédures à la lettre mais ratent les erreurs les plus flagrantes, sous prétexte qu’elles ne sont pas détectées dans les scénarios de test. Le testeur qui connaît les développeurs et leurs erreurs peut anticiper les domaines où ils créent le plus souvent des anomalies et peut les rechercher directement. Bien sûr, ces tests ne sont pas reproductibles et ne sont pas documentés, mais ils sont d’une remarquable efficacité. Il est recommandé d’allouer un certain temps sur chaque itération pour ces tests intuitifs.