Méthodologies de test : des exigences au déploiement

Découvrez les différentes méthodologies de test, à quel moment les implémenter et ce que chaque méthodologie teste.

Avant de pouvoir déployer votre application, vous devez prouver qu'elle fonctionne comme prévu et qu'elle est exempte de défauts. Cette preuve nécessitera un plan de test qui intègre plusieurs méthodologies de test et exploite une variété de tests, dont chacun prouve qu'un aspect de votre application est prêt pour le déploiement. Si vous recherchez des outils de test, vous aurez besoin d'un outil (comme Test Studio) qui prend en charge autant de ces méthodologies de test.

Le cycle de vie des tests

Vous pouvez diviser les tests en plusieurs Huit étapes/méthodologies de test :

Définition

1. Examen des exigences : prouve que vos exigences sont prêtes à être utilisées

2. Tests d'utilisabilité : Prouvez que les utilisateurs peuvent atteindre leurs objectifs avec l'application

Création[19659009]Tests unitaires : prouver que chaque composant fonctionne comme prévu

Déploiement

6. Tests d'acceptation utilisateur (UAT) : Prouvez que les utilisateurs peuvent effectuer des tâches métier ; signaler que l'application est prête à être déployée

7. Smoke test (également appelé sanity check) : prouve que l'application démarre après le déploiement

En plus de ces phases de test avec leurs méthodologies de test, vous ont également #8. Tests de régressionqui prouvent que les tests plus anciens réussissent toujours après que des modifications aient été apportées. Les tests de régression sont spéciaux car non seulement ils prouvent que votre application fonctionne toujours comme vous le pensiez, mais vos tests aussi (vos tests ne génèrent pas de « faux positifs » en échouant là où il n'y a pas de problème, par exemple) .

Les tests de régression commencent par la phase des exigences, se poursuivent tant que vous apportez des modifications et impliquent à la fois les développeurs et le contrôle qualité (mais pas les utilisateurs). Les tests de régression sont votre meilleure protection contre les pannes logicielles mais, généralement, ne sont économiquement possibles que si vos tests sont automatisés (l'automatisation des tests garantit également la cohérence, ce qui est essentiel car cela garantit que vous exécutez le même test que vous avez exécuté à l'origine).

Comme vous le verrez, cette liste est personnalisable. Toutes les équipes, par exemple, n'incluront pas l'UAT pour chaque déploiement. Certaines équipes utiliseront l'UAT à des stades antérieurs pour faire en sorte que les utilisateurs approuvent le travail ultérieur. De nombreuses équipes incluront des tests de fumée dans les étapes d'intégration, E2E et UAT en plus du déploiement. Il est important que vous utilisiez les méthodologies de test les mieux adaptées à votre application au moment approprié. définition de fait. Certains processus de collecte d'exigences incluent même la « testabilité » dans la définition d'une exigence (les user stories, par exemple).

Les exigences peuvent être testées via une revue des exigences (également appelée validation de vos exigences). L'objectif est de prouver que les exigences sont cohérentes, complètes et comprises par toutes les parties de la même manière. Cela implique au moins les utilisateurs et les développeurs, et fait souvent apparaître des hypothèses implicites que ces deux groupes ont. L'inclusion de l'assurance qualité (AQ) à ce stade précoce facilite les tests aux stades ultérieurs. Cette étape est plus courte avec les équipes Agile car, en travaillant ensemble sur un produit au fil du temps, les équipes Agile finissent effectivement par pratiquer une « validation continue ». peut définir ces interactions grâce à des tests d'utilisabilité à l'aide de maquettes, de storyboards papier ou de tableaux blancs. Les tests d'utilisabilité aident également à affiner les exigences des utilisateurs en exprimant les exigences sous une forme logique pour les utilisateurs : l'interface utilisateur de l'application.

Définition : exigences fonctionnelles et non fonctionnelles

Toutes les exigences ne proviennent pas des utilisateurs de l'application. De nombreuses exigences, telles que la fiabilité, les temps de réponse et l'accessibilité, s'appliquent à plusieurs applications (bien que ces exigences puissent également être définies ou modifiées au niveau du projet).

À mesure que le nombre d'exigences augmente, il peut être judicieux de les diviser en deux. groupes : exigences fonctionnelles et non fonctionnelles. Une exigence fonctionnelle est une exigence qui spécifie la fonctionnalité métier de l'application (« Lorsqu'un identifiant d'employé est saisi, la feuille de temps de cet employé sera affichée »). Une exigence non fonctionnelle spécifie dans quelle mesure l'application répond aux exigences fonctionnelles (« Le temps de réponse moyen sera inférieur à trois secondes »).

La frontière entre deux catégories a évolué au fil du temps : de nos jours, les exigences en matière de sécurité et de confidentialité sont plus probables. à classer comme exigences fonctionnelles plutôt que non fonctionnelles, par exemple. Par conséquent, certaines équipes classeront une exigence telle que « Un employé ne pourra pas afficher la feuille de temps d'un autre employé » comme une exigence non fonctionnelle tandis que d'autres équipes la listeront comme une exigence fonctionnelle. Mais, quelle que soit la façon dont une exigence est classée, elle doit être traitée lors des tests.

La plupart des exigences non fonctionnelles sont testées aux étapes d'intégration, E2E et UAT. Cependant, déplacer n'importe quel test plus tôt dans le processus – pensée de conception décalée à gauche – permettra de découvrir des problèmes lorsqu'ils sont moins chers à résoudre. Par exemple, plutôt que d'attendre les tests d'intégration, vous pouvez demander aux développeurs de prouver lors de la phase de test unitaire que les entrées suspectes seront rejetées ou que l'utilisateur ne sera autorisé qu'à effectuer des activités autorisées.

Des tests non fonctionnels peuvent également être inclus. après UAT dans le test de fumée. Les tests de fumée prouvent généralement qu'au moins un utilisateur peut se connecter (ce qui prouve que l'authentification fonctionne), par exemple, et vérifient souvent les temps de réponse excessifs. sur les plus petits composants testables, travailler de manière isolée (des outils comme JustMock) vous permettent d'isoler des composants individuels de votre application pour les tests). Les étapes de test ultérieures (intégration, E2E et UAT) impliquent davantage de composants travaillant ensemble et, à mesure que le nombre de composants augmente, la variété des tests pouvant être inclus augmente également :

• Tests de stress : prouver qu'une application fonctionnera sous les charges attendues

• Tests API : prouve qu'une application peut interagir avec d'autres applications

• Tests de sécurité : prouve que seuls les utilisateurs authentifiés et autorisés peuvent accéder aux fonctionnalités du système (et uniquement si leurs actions ne le font pas semble suspect)

Des tests exploratoires peuvent également être effectués après les étapes d'intégration, E2E et UAT. Les tests exploratoires encouragent les testeurs individuels (qui peuvent être des développeurs, des utilisateurs ou un AQ) à enquêter sur une application pour découvrir des défauts non ciblés dans le plan de test (du moins, pas encore). Les tests exploratoires sont un processus de conception et d'exécution simultanées de tests pour potentiellement découvrir des défauts.

Vous devrez déterminer de quels types de tests vous avez besoin et à quel moment vous les utiliserez. Les tests d'API, par exemple, sont souvent effectués au stade de l'intégration pour prouver que deux services peuvent communiquer entre eux via des appels Web, des files d'attente ou des événements. Cependant, les tests d'API peuvent également être effectués dès l'étape des tests unitaires pour permettre aux développeurs de créer une application avec l'assurance que les interfaces avec d'autres services ont fait leurs preuves. 19659004] Au stade des tests unitaires, seul le développeur est généralement impliqué. Au fur et à mesure que les tests progressent, les utilisateurs finaux s'impliquent davantage dans la validation des tests (reprenant complètement le contrôle à l'UAT). L'utilisation d'outils tels que les enregistreurs de tests et les tests de mots-clés permet aux utilisateurs de s'impliquer encore plus dans les étapes d'intégration, E2E et UAT. Les tests deviennent également généralement plus complexes au cours de ces étapes, de sorte que le rôle de l'AQ, en tant que gestionnaires dédiés du processus de test, augmente.

Les tests unitaires, car ils sont généralement construits par le développeur pour son propre code, prennent généralement un la perspective des tests boîte blanchequi tire parti des connaissances du développeur sur le fonctionnement interne des composants pour piloter la conception des tests. L'objectif des tests en boîte blanche au stade des tests unitaires est de prouver que le composant fait ce qu'il faut de la manière dont il était censé fonctionner. -box testingqui ignore comment le code fait son travail pour se concentrer sur la conformité du composant aux exigences. Vous avez besoin des deux types de tests. S'appuyer uniquement sur les tests de la boîte noire, par exemple, peut signifier que vous pouvez avoir du code qui s'exécute d'une manière que vous ne comprenez pas. Ce code va inévitablement exploser (et d'une manière surprenante) lorsque les conditions changent. . Les composants choisis pour un test d'intégration sont choisis parce qu'ils sont connus pour fonctionner ensemble d'une manière spécifique, par exemple, qui est une perspective de boîte blanche. Cependant, dans les tests d'intégration, la validation a tendance à se concentrer sur « Avons-nous obtenu le bon résultat ? » (l'hypothèse étant qu'il n'était possible d'obtenir la bonne réponse que si les composants fonctionnaient ensemble « comme prévu ») – une approche boîte noire.

Les tests E2E, UAT et les tests de fumée ont tendance à avoir un approche box, de sorte que l'objectif de ces étapes est de prouver que l'application répond aux exigences (à la fois fonctionnelles et non fonctionnelles). L'implication de l'assurance qualité dans les revues des exigences est ici payante, car elle permet à l'assurance qualité de mieux comprendre ce qui compte comme un test réussi à ces étapes. L'application. Le but ici est de prouver que l'acteur ultime est à l'aise avec les changements qui vont être déployés. L'assurance qualité et les développeurs sont impliqués, mais principalement dans la configuration de l'environnement de test et l'enregistrement de tous les problèmes découverts. , le déploiement peut être automatiquement annulé. Dans le cadre d'un test de fumée, cependant, certaines équipes ont un utilisateur qui se connecte à l'application, avec une personne QA ou un développeur à portée de main pour signaler tout problème. D'autres équipes utilisent des tests exploratoires pendant le test de fumée pour vérifier les défauts post-déploiement.

Gestion des tests

Si vous pensez que c'est beaucoup des méthodologies de test, et plus que vous n'avez de temps ou de budget pour… eh bien, vous avez probablement raison. Vous devrez personnaliser ce processus pour votre application. Vous ne voudrez appliquer des tests que lorsque le risque le justifie, et vous omettrez les tests lorsque le risque d'échec est faible (ou lorsque les échecs possibles peuvent être facilement atténués). Vous en savez peut-être suffisamment sur la demande de votre application et de votre infrastructure informatique pour que les tests de résistance n'aient aucun sens, par exemple.

Si, toutefois, vous devez effectuer plus de tests que vos ressources ne le permettent (ou si vous souhaitez simplement libérer tester des ressources pour travailler sur l'ajout de fonctionnalités), votre première étape consiste à rechercher une redondance parmi vos tests (en vous assurant que vous n'avez pas deux tests qui prouvent la même chose). Le réordonnancement de l'ordre des tests peut parfois réduire la durée d'un test en s'exécutant sur des surfaces plus petites. Par exemple, un test qui n'implique qu'une seule API peut-il être déplacé des tests d'intégration vers des tests unitaires ? Travailler dans des sprints aide également en réduisant la surface à tester.

Vous devriez également rechercher des outils et des techniques qui réduiront votre effort de test (sans réduire son efficacité) ou amélioreront l'efficacité du test (sans augmenter l'effort de test). L'automatisation de tests fréquents et répétitifs (à l'aide d'outils tels que Test Studio) permet non seulement des tests de régression, mais vous permet également de tester dans davantage d'environnements, ce qui rend vos tests plus efficaces.

Les techniques qui répartissent la charge de travail sont vaut aussi la peine d'être regardé. Par exemple, l'intégration des outils qui permettent aux utilisateurs d'écrire des tests E2E non seulement automatise davantage de tests et répartit la charge de travail, mais améliore également l'efficacité des tests.

Et voici un dernier conseil (et un dernier élément de terminologie) : à moins que vous n'essayiez de réduire votre base de code en supprimant du code non pertinent, ne vous inquiétez pas du nombre de lignes de code exécutées pendant les tests (coverage). Si votre code a réussi tous vos tests, alors votre code a réussi tous vos tests – vous avez prouvé tout ce que vous vouliez prouver à propos de votre application. Il est prêt à être déployé.