STLC - Principes fondamentaux du test

L'objectif commun des tests est de trouver les bogues le plus tôt possible. Et, une fois les bogues corrigés, assurez-vous qu'il fonctionne comme prévu et qu'il ne rompt aucune autre fonctionnalité.

Pour atteindre ces objectifs, sept principes de base sont donnés pour les tests logiciels -

Que montre les tests?

Les tests peuvent montrer que des défauts sont présents mais il n'y a aucun moyen de prouver qu'il n'y a pas de défaut dans le produit. Les phases de test garantissent que l'application testée fonctionne en fonction de l'exigence donnée et contribuent à réduire la probabilité de défauts non découverts dans l'application. Mais, même si aucun défaut n'est trouvé, cela ne signifie pas qu'il est absolument correct. Nous pouvons supposer qu'AUT correspond à nos critères de sortie et maintient les exigences selon SRD.

Des tests exhaustifs sont-ils possibles?

Une couverture à 100% ou des tests de toutes les combinaisons d'entrées et de combinaisons possibles ne sont pas possibles, sauf dans des cas triviaux. Au lieu de tests exhaustifs, l'analyse des risques et les priorités sont utilisées pour définir la portée des tests. Ici, la plupart des scénarios en temps réel peuvent également envisager d'inclure le scénario négatif le plus probable. Cela nous aidera à suivre l'échec.

Test précoce

Les activités de test doivent commencer dès que possible et se concentrer sur les objectifs définis dans la stratégie de test et les résultats attendus. Le stade précoce des tests permet d'identifier les défauts d'exigence ou les écarts au niveau de la conception. Si ces types de bogues sont capturés au stade initial, cela nous permet de gagner du temps et est également rentable. La réponse à la question de savoir pourquoi les tests doivent commencer à un stade précoce est très simple: dès que le SRD est reçu, les testeurs peuvent analyser l'exigence du point de vue du test et peuvent remarquer une divergence d'exigence.

Regroupement de défauts

Sur la base d'une analyse précédente des défauts du produit, on peut dire que la plupart des défauts sont identifiés à partir d'un petit ensemble de modules qui sont essentiels pour l'application. Ces modules peuvent être identifiés en fonction de la complexité, des différentes interactions du système ou de la dépendance vis-à-vis de différents autres modules. Si les testeurs peuvent identifier ces modules cruciaux, ils peuvent se concentrer davantage sur ces modules pour identifier tous les bogues possibles. Dans une étude, on constate que 8 défauts sur 10 sont identifiés à partir de 20% de fonctionnalité de AUT.

Paradoxe des pesticides

Qu'est-ce que le paradoxe des pesticides - si les pesticides sont fréquemment utilisés sur les cultures, il arrive que les insectes développent une certaine résistance et progressivement les pesticides ainsi pulvérisés semblent inefficaces sur les insectes.

Le même concept s'applique également aux tests. Ici, les insectes sont des insectes tandis que les pesticides sont des cas de test qui sont utilisés pour fonctionner encore et encore. Si les mêmes ensembles de cas de test sont exécutés encore et encore, ces cas de test deviennent inefficaces après un certain laps de temps et les testeurs ne pourront pas identifier de nouveau défaut.

Pour surmonter ces conditions, les cas de test doivent être révisés et revus de temps en temps et des cas de test nouveaux et différents peuvent être ajoutés. Cela aidera à identifier les nouveaux défauts.

Le test dépend du contexte

Ce principe stipule que deux types d'application différents ne peuvent pas être testés en utilisant la même approche tant que les deux applications ne sont pas de même nature. Par exemple, si un testeur utilise la même approche pour une application Web et une application mobile, c'est complètement faux et il y a un risque élevé de mauvaise qualité de la publication du produit. Les testeurs doivent utiliser différentes approches, méthodologies, techniques et couvertures pour différents types et nature d'applications.

Absence d'erreur - erreur

Ce principe stipule de trouver les défauts et de les corriger jusqu'à ce que l'application ou le système soit stable, prend du temps et consomme également des ressources. Même après avoir corrigé 99% des défauts, il existe un risque élevé d'application instable. La première chose essentielle est de vérifier la stabilité de l'application et les prérequis de l'environnement. Si ces deux conditions sont remplies, alors seulement nous pouvons commencer par les tests détaillés.