Méthodologies de test de logiciels : modèles d'assurance qualité
Thomas Hamilton
⚡ Résumé intelligent
La méthodologie des tests logiciels définit les stratégies et les types de tests utilisés pour garantir qu'une application répond aux attentes du client. Les approches en cascade, itératives, agiles et de programmation extrême déterminent chacune le moment où les tests débutent et la manière dont les retours sont obtenus.
Qu’est-ce que la méthodologie de test logiciel ?
La méthodologie de test de logiciels est définie comme des stratégies et des types de tests utilisés pour certifier que l'application testée répond aux attentes du client. Les méthodologies de test incluent des tests fonctionnels et non fonctionnels pour valider l'AUT. Des exemples de méthodologies de test sont Tests unitaires, Test d'intégration, Test du système, Test de performance etc. Chaque méthodologie de test a un objectif de test défini, une stratégie de test et des livrables.
Note: Étant donné que les tests de logiciels font partie intégrante de toute méthodologie de développement, de nombreuses entreprises utilisent familièrement le terme méthodologies de développement et méthodologies de test. Par conséquent, les méthodologies de test pourraient également faire référence aux modèles Waterfall, Agile et autres modèles d'assurance qualité, par opposition à la définition ci-dessus des méthodologies de test. La discussion sur les différents types de tests n’ajoute aucune valeur aux lecteurs. Nous discuterons donc des différents modèles de développement.
Méthodologie de test vs Type de test vs Stratégie de test
La remarque ci-dessus révèle une réelle ambiguïté au sein du secteur. Trois termes sont utilisés indifféremment à l'oral, mais ont des significations différentes dans un document de projet ; les confondre aboutit à des plans de test qui répondent à la mauvaise question.
| Long | Question à laquelle il répond | Décidé par | Exemples |
|---|---|---|---|
| Méthodologie de test | Quand et comment les tests s'intègrent-ils au cycle de développement ? | Le modèle de développement en vigueur | En cascade, itératif, agile, programmation extrême |
| Type de test | Quel aspect du produit est vérifié ? | Couverture des risques et des exigences | Unité, intégration, système, performance, sécurité |
| Niveau de test | À quelle profondeur le logiciel est-il examiné ? | Position dans la hiérarchie de construction | Composant, intégration, système, acceptation |
| Stratégie de test | Quelle est notre approche organisationnelle en matière de qualité ? | Le leadership en assurance qualité s'applique à tous les projets. | Approche fondée sur les risques, priorité à l'automatisation, décalage vers la gauche |
| Plan de test | Que testera exactement ce projet, quand et par qui ? | Responsable des tests, spécifique au projet | Portée, calendrier, ressources, critères d'entrée et de sortie |
Une règle empirique utile : la méthodologie définit le rythme, le type définit la cible, et le plan de test Cet engagement est consigné dans les documents. Les sections ci-dessous examinent les méthodologies.
Modèle de cascade
Qu’est-ce que c’est?
Dans l' modèle de cascade, le développement de logiciels progresse à travers différentes phases telles que l'analyse des exigences, la conception, etc. – séquentiellement.
Dans ce modèle, la phase suivante ne commence que lorsque la phase précédente est terminée.
Quelle est l’approche de test ?
La première phase du modèle en cascade est la phase des exigences au cours de laquelle toutes les exigences du projet sont complètement définies avant de commencer les tests. Au cours de cette phase, l'équipe de test réfléchit à la portée des tests, à la stratégie de test et rédige un plan de test détaillé.
Ce n'est qu'une fois la conception du logiciel terminée que l'équipe passera à l'exécution des cas de tests pour s'assurer que le logiciel développé se comporte comme prévu.
Dans cette méthodologie, l'équipe de test passe à la phase suivante uniquement lorsque la phase précédente est terminée.
| Avantages | Désavantages |
|---|---|
| Ce modèle de génie logiciel est très simple à planifier et à gérer. Ainsi, les projets dont les exigences sont clairement définies et énoncées à l’avance peuvent être facilement testés à l’aide d’un modèle en cascade. | Dans le modèle en cascade, vous ne pouvez commencer la phase suivante qu’une fois la phase précédente terminée. Par conséquent, ce modèle ne peut pas tenir compte des événements imprévus et de l’incertitude. |
| Cette méthodologie ne convient pas aux projets où les exigences changent fréquemment. |
Développement itératif
Qu’est-ce que c’est?
Dans ce modèle, un projet de grande envergure est divisé en petites parties, chacune étant soumise à plusieurs itérations du modèle en cascade. À la fin de chaque itération, un nouveau module est développé ou un module existant est amélioré. Ce module est ensuite intégré à l'architecture logicielle et le système dans son ensemble est testé.
Quelle est l’approche de test ?
Dès que l'itération est terminée, l'ensemble du système est soumis à des tests. Les commentaires issus des tests sont immédiatement disponibles et intégrés au cycle suivant. Le temps de test requis lors des itérations successives peut être réduit en fonction de l'expérience acquise lors des itérations précédentes.
| Avantages | Désavantages |
|---|---|
| Le principal avantage du développement itératif est que le retour d’expérience des tests est immédiatement disponible à la fin de chaque cycle. | Ce modèle augmente considérablement les frais de communication puisque, à la fin de chaque cycle, un feedback sur les livrables, les efforts, etc. doit être donné. |
Méthodologie agile
Qu’est-ce que c’est?
Les méthodologies traditionnelles de développement de logiciels partent du principe que les exigences logicielles restent constantes tout au long du projet. Mais avec une complexité croissante, les exigences subissent de nombreux changements et évoluent continuellement. Parfois, le client lui-même n’est pas sûr de ce qu’il veut. Bien que le modèle itératif résolve ce problème, il reste basé sur le modèle en cascade.
Dans la méthodologie Agile, les logiciels sont développés par cycles incrémentiels et rapides. Les interactions entre les clients, les développeurs et le client sont mises en valeur plutôt que les processus et les outils. La méthodologie agile se concentre sur la réponse au changement plutôt que sur une planification approfondie.
Quelle est l’approche de test ?
Les tests incrémentiels sont utilisés dans les méthodes de développement agiles et par conséquent, chaque version du projet est testée de manière approfondie. Cela garantit que tous les bogues du système sont corrigés avant la prochaine version.
| Avantages | Désavantages |
|---|---|
| Il est possible d'apporter des modifications au projet à tout moment pour se conformer aux exigences. | Une interaction constante avec le client signifie une pression de temps supplémentaire sur toutes les parties prenantes, y compris le client lui-même, les équipes de développement de logiciels et de test. |
| Ces tests progressifs minimisent les risques. |
Programmation extrême
Qu’est-ce que c’est?
La programmation extrême est un type de méthodologie agile qui privilégie les cycles de développement courts. Un projet est divisé en tâches d'ingénierie simples. Les programmeurs codent un logiciel simple et contactent le client pour obtenir ses commentaires. RevLes points de vue du client sont intégrés et les développeurs passent à la tâche suivante.
Dans la programmation extrême, les développeurs travaillent généralement en binôme.
Programmation extrême est utilisé dans des endroits où les exigences des clients évoluent constamment.
Quelle est l’approche de test ?
La programmation extrême suit un développement piloté par les tests qui est décrit comme suit :
- Ajouter un Cas de test à la suite de tests pour vérifier la nouvelle fonctionnalité qui reste à développer
- Exécutez tous les tests et évidemment le nouveau scénario de test ajouté doit échouer puisque la fonctionnalité n'est pas encore codée
- Écrivez du code pour implémenter la fonctionnalité/fonctionnalité
- Exécutez à nouveau la suite de tests. Cette fois, le nouveau scénario de test devrait réussir puisque la fonctionnalité a été codée
| Avantages | Désavantages |
|---|---|
| Les clients ayant une idée vague de la conception du logiciel pourraient utiliser la programmation extrême | Les réunions entre l'équipe de développement logiciel et les clients augmentent les exigences de temps. |
| Des tests continus et l'intégration continue de petites versions garantissent que le code logiciel fourni est de haute qualité. |
Modèle en V et modèle en spirale
Deux autres modèles apparaissent dans la plupart des projets et complètent le tableau, car chacun répond d'une manière différente à une faiblesse de l'approche en cascade.
Modèle en V. Souvent appelé vérification et validation, le modèle en V associe chaque phase de développement à une phase de test correspondante, représentée par les deux branches d'un V. Les exigences sont associées aux tests d'acceptation, la conception générale aux tests système, la conception détaillée aux tests d'intégration et le codage aux tests unitaires. L'avantage est que la conception des tests commence en même temps que chaque phase de développement, et non après le codage. Ainsi, les exigences ambiguës sont détectées par le rédacteur des tests d'acceptation plusieurs mois avant qu'un défaut ne soit reproduit. Son point faible, hérité du modèle en cascade, est qu'il suppose toujours la stabilité des exigences.
Modèle en spirale. L'itération en spirale s'articule autour d'une analyse de risques explicite. Chaque boucle comprend quatre activités : définir les objectifs, identifier et résoudre les risques, développer et tester, puis planifier l'itération suivante. Les tests se concentrent ainsi là où le risque est le plus élevé, au lieu d'être répartis uniformément. Cette approche convient aux programmes vastes, coûteux et de longue durée, tels que les systèmes centraux aérospatiaux ou bancaires, où le coût d'une découverte tardive est considérable. Pour un petit projet web, le surcoût lié à une analyse de risques formelle à chaque boucle est rarement justifié.
Ces deux modèles se situent entre la rigueur du modèle en cascade et la réactivité agile. Lorsque la fréquence des mises en production prime sur l'un ou l'autre, un DevOps Le pipeline intègre les tests dans l'intégration continue afin que chaque commit soit vérifié automatiquement.
Quelle méthodologie logicielle choisir ?
Il existe des tonnes de méthodologies disponibles pour le développement de logiciels et les tests correspondants. Chaque technique et méthodologie de test est conçue dans un but spécifique et a ses avantages et ses inconvénients relatifs.
La sélection d'une méthodologie particulière dépend de nombreux facteurs tels que la nature d'un projet, les exigences du client, le calendrier du projet, etc.
Du point de vue des tests, certaines méthodologies incitent à tester les entrées dès le début du cycle de vie du développement, tandis que d'autres attendent qu'un modèle fonctionnel du système soit prêt.
Comment mettre en place des méthodologies de tests logiciels ?
Les méthodologies de test de logiciels ne doivent pas être mises en place uniquement dans le seul but de tester le code d’un logiciel. Il convient de considérer la situation dans son ensemble et l'objectif principal du projet doit être satisfait à la méthodologie de test. Référez-vous à cette liste de sociétés réputées fournisseurs de services de test de logiciels qui peut vous aider à établir des stratégies de tests efficaces adaptées aux objectifs de votre projet.
Planification
Un calendrier réaliste est la clé de la mise en œuvre d’une méthodologie de test réussie et le calendrier doit répondre aux besoins de chaque membre de l’équipe.
Livrables définis
Afin de garder tous les membres de l’équipe sur la même longueur d’onde, des livrables bien définis doivent être fournis. Les livrables doivent contenir un contenu direct sans aucune ambiguïté.
Approche de test
Une fois la planification terminée et les livrables définis mis à disposition, l’équipe de test devrait être en mesure de formuler la bonne approche de test. Les documents de définition et les réunions de développeurs doivent indiquer à l'équipe la meilleure approche de test pouvant être utilisée pour le projet.
Reporting
Il est très difficile d'obtenir un reporting transparent, mais cette étape détermine l'efficacité de l'approche de test utilisée dans le projet.
