Commençons par les bases. Découvrez les deux modes de test généraux et les trois types d'automatisation de test courants.
Cela nous est tous déjà arrivé: quel est le mème récurrent de codage qui se produit trop souvent dans la vraie vie ?
Ce meme résume bien la situation: chaque tiroir fonctionne parfaitement individuellement, mais lorsqu'ils sont combinés, ils se bloquent mutuellement et ne fonctionnent pas. Vous voulez que les deux tiroirs fonctionnent bien ensemble et soient utilisables en même temps.
Appliquez ce principe au développement Web: vous avez écrit des tests, peut-être même obtenu une couverture de test de 100 %, mais votre application doit toujours fonctionner une fois que les autres éléments sont en place. Les unités peuvent fonctionner correctement individuellement, mais pas les unes par rapport aux autres. Écrire des tests est crucial, mais ce n'est qu'une partie de la configuration de test idéale pour votre projet. La première étape consiste à déterminer les aspects de la qualité de l'application que vous devez garantir et comment vous pouvez y parvenir.
En d'autres termes, vous avez besoin d'un plan avant de commencer à écrire le code de test. Pour aborder le sujet de la manière pratique de tester, commençons par une page blanche et répondons à deux questions de base:
- Comment voulez-vous effectuer le test ?
- Que voulez-vous tester ?
Cet article se concentre sur les informations générales que vous devez connaître pour répondre à la première question. Pour partir d'un point commun, commençons par découvrir les modes de test existants, puis nous concentrerons sur les types de tests courants. Dans des articles ultérieurs, nous répondrons à la deuxième question, combinerons les réponses et trouverons la stratégie de test la plus adaptée à votre projet. C'est parti ! 🙌
Commencez par les bases: modes de test généraux
Pour répondre à la question de savoir comment effectuer des tests, le premier point à clarifier est très abstrait. Faut-il effectuer le test manuellement ou laisser un ordinateur s'en charger ? Il est toutefois important de ne pas tomber dans une logique binaire.
Tests manuels par rapport aux tests automatisés
Si vous demandez à des ingénieurs d'assurance qualité de définir les tests, ils commenceront probablement par les diviser en deux "modes" :
- Tests manuels Il s'agit d'une méthode de test typique menée par des personnes réelles. Un ingénieur en assurance qualité clique sur l'application, vérifie si elle fonctionne et, en même temps, essaie de la faire planter. La méthode la plus courante est le test exploratoire, où l'ingénieur examine l'application en utilisant ses connaissances à son sujet en fonction d'un chemin ou d'une checklist prédéfinis.
- Tests automatisés Il s'agit d'un type de test effectué par un ordinateur. Les ingénieurs en assurance qualité l'implémentent pour automatiser les tests répétitifs et monotones.
Cette série de guides se concentrera principalement sur les tests automatisés. Toutefois, vous ne devez pas vous concentrer sur un seul type de test. Même si l'automatisation permet de gagner beaucoup de temps et d'efforts, les humains et les tests manuels joueront toujours un rôle essentiel. L'automatisation des tests doit plutôt permettre aux équipes de se concentrer sur les tests exploratoires et la résolution créative des problèmes. (par exemple, en veillant à la qualité des expériences utilisateur ou en protégeant la logique métier à haut risque). En d'autres termes, l'automatisation est là pour vous aider. ❤️
Boîte opaque par rapport à la boîte transparente
Vous avez donc défini les modes de test généraux. Toutefois, ce n'est pas encore suffisant. Pour planifier la stratégie de test, vous devez répondre à une autre question: devez-vous connaître le fonctionnement interne de votre application ou est-il préférable de la tester sans cette connaissance ? Selon la réponse, vous avez le choix entre deux procédures pour déduire et sélectionner des scénarios de test:
- Test en boîte opaque (ou test en boîte noire) Il repose sur l'analyse des exigences fonctionnelles ou non fonctionnelles (spécifications) d'un composant ou d'un système, sans tenir compte de sa structure interne.
- Le test en boîte claire (ou test en boîte blanche) est une procédure qui prend en compte la structure interne de la boîte. Autrement dit, le fonctionnement interne de votre application.
Ces deux procédures peuvent être appliquées aux tests manuels et automatisés. Toutefois, certains aspects des modes de test généraux peuvent se concentrer davantage sur l'un des deux. Nous y reviendrons plus tard. Pour l'instant, examinons plus en détail les différents types d'automatisation des tests.
Types d'automatisation des tests: comment voulez-vous effectuer les tests ?
Vous vous rapprochez de la réponse à la question "comment", et vous avez déjà décidé de procéder à des tests manuels. Toutefois, le choix et l'application des types d'automatisation des tests sont un peu plus difficiles. Les types de tests d'automatisation sont étroitement liés aux métriques que vous souhaitez créer dans vos projets. Voyons donc les plus importantes.
Comme illustré dans le meme mentionné précédemment, vous en avez déjà rencontré deux: les tests unitaires et les tests d'intégration. Les tests de bout en bout constituent le troisième élément important à prendre en compte. Mais ce n'est pas tout. Voyons cela de plus près.
Tests unitaires
Les tests unitaires sont un type de test dans lequel les parties ou unités testables mineures d'une application sont testées individuellement et indépendamment pour vérifier leur bon fonctionnement. La portée de ces unités peut varier de fonctions, classes ou interfaces à des services ou des composants complets. Leurs principaux attributs sont la vitesse d'exécution, l'isolation et la facilité de maintenance. Pour en savoir plus sur les tests unitaires, consultez ce guide sur les tests unitaires.
Tests d'intégration
Les tests d'intégration se concentrent sur les interactions entre les composants ou les systèmes. Autrement dit, sur la façon dont ils fonctionnent ensemble. Les tests d'API ou de composants sont des exemples typiques de tests d'intégration.
Test de bout en bout
Ces tests sont souvent appelés tests d'interface utilisateur, et ce nom explique encore mieux leur fonction. Ces tests interagissent avec l'interface utilisateur de votre application, y compris la pile d'application complète, et testent votre application de bout en bout.
Ils ressemblent à un test système si vous vous référez à la théorie de l'assurance qualité. Ces tests simulent un utilisateur réel et ses interactions. Les tests de bout en bout prennent plus de temps d'exécution, car ils impliquent l'ensemble du système. Plus le temps d'exécution est long, plus la puissance de calcul requise est importante. Par conséquent, cet effort supplémentaire entraîne des coûts de maintenance plus élevés.
Test visuel de l'interface utilisateur
Les tests visuels constituent une sous-catégorie intéressante des tests d'interface utilisateur. Il s'agit de tests étendus de bout en bout qui permettent de vérifier la sortie visible d'une application. Ce test consiste à prendre une capture d'écran après une modification et une autre contenant l'état actuel (ou fichier d'or), puis à fournir ces résultats à un examinateur humain pour qu'il les inspecte et les vérifie. En d'autres termes, il permet de trouver des "bugs visuels" dans l'apparence d'une page, au-delà des bugs purement fonctionnels et qui ne sont pas explicitement consignés dans des assertions.
Analyse statique
Nous allons maintenant introduire un autre concept: l'analyse statique. Il ne s'agit pas d'un type de test au sens strict. Toutefois, il s'agit d'un aspect essentiel des stratégies d'assurance qualité ultérieures. Vous pouvez l'imaginer fonctionner comme une fonction de vérification orthographique: il analyse votre code à la recherche de défauts et d'erreurs de syntaxe plus importants sans exécuter le programme, ce qui permet de détecter les problèmes de style de code. Cette mesure simple peut éviter de nombreux bugs. C'est un bon moment pour en savoir plus sur l'analyse statique si vous souhaitez vous y familiariser.
Tests de toutes sortes: comment tout cela fonctionne-t-il ensemble ?
En cherchant des réponses à toutes ces questions, vous pouvez trouver une solution possible dans certaines analogies. Dans les communautés Web et de test en particulier, les développeurs ont tendance à utiliser ces analogies pour vous donner une idée du nombre de tests que vous devez utiliser et de leur type.
Les cinq stratégies illustrées dans cette image sont les plus courantes:
- Pyramide de test
- Diamant de test
- Test du cornet de glace (également appelé "test pizza")
- Test de la structure alvéolée
- Trophée de test
C'est vraiment beaucoup d'informations à traiter. Sur la base de tout cela, comment choisir une stratégie de test de correspondance ? Ne vous inquiétez pas, nous avons ce qu'il vous faut. Dans l'article suivant, nous aborderons ces différentes stratégies plus en détail et vous expliquerons comment choisir celle qui convient le mieux à votre projet. Tenez-vous informé ! 🔥