Tests logiciels en livraison continue

Les tests logiciels permettront à l'organisation de gagner du temps et d'économiser de l'argent en réduisant les coûts de développement et de maintenance des logiciels. Ils ajoutent des garanties de stabilité dans le développement de nouvelles fonctionnalités. Ils garantissent qu'une fonctionnalité se comporte comme prévu et que les utilisateurs ne rencontrent pas de bugs.

Le développement de nouvelles fonctionnalités peut être accéléré en spécifiant un ensemble de scénarios de test que la nouvelle fonctionnalité doit réussir pour être considérée comme complète et livrable. Les développeurs disposent alors d'un objectif fixe, ce qui permet d'estimer le calendrier de manière plus précise et de réduire l'introduction de nouveaux bugs. Une fois ces scénarios de test en place, les coûts de maintenance globaux diminuent. Les tests peuvent être exécutés sur une fonctionnalité déjà livrée pour s'assurer qu'elle se comporte toujours comme prévu.

Il existe plusieurs niveaux fondamentaux dans les tests logiciels, chacun examinant la fonctionnalité du logiciel d'un point de vue unique dans le processus de développement. Jetons un coup d'œil aux différents types de test et examinons leur utilisation pratique.

Le test unitaire constitue le niveau fondamental des tests logiciels. Cette pratique consiste à instrumenter les vérifications de l'exactitude des entrées et des sorties pour des unités de code individuelles. L'unité de mesure, dans ce cas, se compose de fonctions ou de méthodes de code autonomes.

Pendant les tests unitaires, les fonctions de code de production sont exécutées dans un environnement de test avec entrée simulée. La sortie de la fonction est ensuite comparée à la sortie attendue pour cette entrée. Si elle correspond au résultat attendu, le test réussit. Dans le cas contraire, il échoue. Les tests unitaires sont un excellent moyen de valider les fonctions de données dérivées.

Une user story de test unitaire hypothétique pourrait ressembler à ceci : « fonction 2VAL, étant donné 2 valeurs x et y, renvoie toujours x+y ». Le test unitaire exécuterait ensuite 2VAL avec deux valeurs et confirmerait que la sortie correspond à x+y. Les tests unitaires sont parfaits pour confirmer l'exactitude du code qui fonctionne sur les valeurs monétaires.

Lorsqu'un scénario de test logiciel couvre plusieurs unités, il est considéré comme un test d'intégration. Lors du développement d'un scénario de test logiciel, les lignes entre les tests unitaires peuvent rapidement évoluer en tests d'intégration. Souvent, un test unitaire peut être développé pour être exécuté sur une dépendance de code tierce. La dépendance elle-même n'aura pas besoin d'être testée, et son intégration sera simulée.

Les scénarios de test qui simulent une expérience utilisateur complète sont appelés tests fonctionnels ou tests de bout en bout. Les tests de bout en bout utilisent des outils qui simulent le comportement réel de l'utilisateur. Étapes courantes durant un test de bout en bout :

• Cliquer sur ce bouton
• Lire ce texte
• Envoyer ce formulaire

En raison du contexte complet d'exécution de l'expérience, les tests de bout en bout vérifient l'exactitude sur toutes les couches d'une stack logicielle.

Les tests exploratoires sont un exercice dans lequel les testeurs se voient assigner une tâche librement définie à l'aide du logiciel testé. Ainsi, vous apprenez beaucoup de choses sur la manière dont les gens utilisent vos produits sur le terrain. Les sessions de tests exploratoires donnent même la possibilité de motiver les utilisateurs en leur offrant des récompenses pour le plus grand nombre de problèmes trouvés, la plus grande défaillance détectée ou l'utilisation la plus inattendue du produit.

Les tests logiciels exploratoires ont pour avantage que tout le monde peut y contribuer : il suffit d'explorer le produit de manière libre. Si les tests exploratoires ne sont pas aléatoires, ils ne sont pas pour autant scriptés comme les tests manuels.

La livraison continue exploite toutes les stratégies de tests mentionnées plus haut pour créer un pipeline transparent, qui livre automatiquement les tâches de code terminées. Une configuration optimale permet à un développeur de pusher le code récemment terminé dans le pipeline de livraison continue à des fins d'évaluation. Le pipeline exécute alors les différents niveaux de test sur le code pushé. Si ce dernier passe le test, il est automatiquement mergé et déployé en production. Toutefois, s'il échoue au test, il est rejeté, et le développeur est automatiquement informé des étapes à suivre pour le corriger.

Les écosystèmes populaires de développement dans les langages de programmation établis ont leurs propres écosystèmes de tests de sous-ensemble. De nombreux outils fournissent des utilitaires pour aider à l'instrumentation et au développement de suites de tests. Ces outils sont généralement installés via un gestionnaire de packages spécifique au langage de programmation utilisé dans le projet.

En plus des instruments de test, des outils d'exécution et de développement de tests sont également disponibles. Différents outils d'exécution de test peuvent être installés pour fournir des données de sortie à partir d'une suite de tests. Une pratique courante consiste à mesurer la « couverture de test » tout au long d'un projet. Un outil de couverture de code peut être utilisé pour indiquer la proportion d'une base de code correctement couverte.

Une fois qu'une suite de tests a été développée et fonctionne correctement sur un projet local, il est généralement facile de l'intégrer dans un pipeline de CD. La plupart des systèmes de CD/CI hébergés proposeront des guides sur l'intégration d'une suite de tests dans le pipeline.

Un véritable pipeline de CD à valeur ajoutée se construit autour d'une base de tests solide. Cette base de test commence par des scénarios de test manuels qui évoluent vers des solutions automatisées.

Tout le monde (développeurs, testeurs, etc.) est responsable de la relation qualité avec le client. Chaque ligne de code améliore ou empire l'expérience client. La suite de tests d'un pipeline de CD est un outil polyvalent pour développer un code correct et de haute qualité. Pendant la phase de conception du produit, la suite de tests peut être utilisée comme référence pour des considérations préventives sur le développement d'une fonctionnalité. La suite de tests est principalement utilisée pour simplifier le processus de développement, mais peut également être exécutée dans des environnements de staging et de production afin d'y garantir la qualité.

Selon la méthodologie traditionnelle de test, les tests sont un processus distinct sans rapport avec le développeur. L'absence du développeur lors de l'étape d'assurance qualité (QA) encourage un manque d'empathie de l'équipe de développement envers les clients. En outre, en raison du manque d'implication des développeurs dans le QA, les problèmes perdurent plus longtemps dans la base de code, ce qui augmente le coût de leur résolution. Cette méthodologie entraîne également des coûts salariaux organisationnels élevés, car elle encourage l'embauche d'une équipe de QA distincte à cette fin.

La livraison continue favorise la sensibilisation des développeurs et l'empathie à l'égard de l'expérience utilisateur final. Les développeurs sont chargés de fournir une couverture de test pour les fonctionnalités qu'ils produisent et de les superviser des environnements de développement aux environnements de production. Ils sont ainsi responsables et peuvent prouver la qualité d'une fonctionnalité.

La livraison continue permet un déploiement et des mises à jour rapides d'un projet logiciel. Elle permet d'intégrer immédiatement le feedback des clients dans une prochaine version. En cas de problème signalé par l'utilisateur, la suite de tests du pipeline de CD peut être consultée afin de mieux définir la portée des vecteurs potentiels du problème. Les équipes de développement et de test qui réagissent rapidement au feedback des clients sont plus efficaces.

Vous souhaitez créer votre propre environnement de livraison continue ? Nous vous aiderons à vous lancer.

Lors de l'élaboration d'une stratégie de test logiciel, il est préférable de garder à l'esprit les stratégies globales du produit, de l'utilisateur et de l'entreprise. Il faudra tenir compte de l'objet des tests et privilégier une couverture offrant le plus de valeur.

Dans le meilleur des mondes, un projet de développement chercherait à obtenir une couverture de test de 100 % garantissant que le code est exempt de bugs et fonctionne comme prévu. Malheureusement, dans le monde réel des affaires qui se caractérise par des délais et des contraintes budgétaires, cela n'est pas vraiment réalisable.

Différentes stratégies de test devraient être envisagées en fonction du type de logiciel livrable. Si le logiciel est une application basée sur une interface graphique, des tests de bout en bout de haut niveau se révéleront très utiles. Les projets de logiciels libres Headless UI accordent une grande valeur aux tests unitaires au détriment des tests de bout en bout.

Voici une stratégie générale pour les applications utilisateur basées sur une interface graphique.

1. Tests de bout en bout d'instruments sur tous les flux d'utilisateurs principaux (connexion, inscription, paiement, etc.)
2. Tests unitaires d'instruments sur toutes les fonctions de code sensibles aux données, comme les outils de transaction monétaire
3. Tests d'intégration d'instruments pour tous les points d'intégration tierce afin de s'assurer que les données transitent vers le tiers et que les erreurs sont propagées correctement

La quête d'un workflow de livraison continue présente de nombreux avantages métier. Les coûts organisationnels liés à l'embauche et à la gestion d'équipes distinctes pour les rôles de QA, de gestion des versions et d'ingénierie de test peuvent être considérablement réduits en mettant en place un workflow de CD.

La livraison continue favorise un niveau global de qualité des produits supérieur à celui des workflows traditionnels de test de QA. Les tests de CD encouragent les développeurs à s'approprier l'expérience utilisateur final et la qualité des fonctionnalités qu'ils ajoutent, et à s'y impliquer. La CD établit un framework qui facilite la focalisation sur la qualité des versions et la discussion à ce sujet à l'échelle de l'entreprise.

La livraison continue repose sur l'implémentation d'une stratégie de test logiciel robuste, et l'automatisation est la clé d'un pipeline de livraison continue efficace.

Êtes-vous prêt à renforcer vos tests logiciels ? Découvrez-en plus sur les tests dans un environnement de CD. Vous pouvez également découvrir comment Atlassian et des outils tiers peuvent intégrer les tests à votre workflow grâce à nos tutoriels de tests DevOps.