Ce didacticiel présente les sept principes de base du test logiciel que chaque testeur logiciel et professionnel de l'assurance qualité doit connaître.
7 Principes des tests logiciels
- Les tests montrent la présence de défauts
- Des tests exhaustifs ne sont pas possibles
- Test précoce
- Regroupement des défauts
- Paradoxe des pesticides
- Les tests dépendent du contexte
- Absence d'erreurs fallacieuses
Apprenons les principes de test avec l'exemple vidéo suivant-
Cliquez ici si la vidéo n'est pas accessible
Fond
Il est important que vous obteniez des résultats de test optimaux tout en effectuant des tests logiciels sans vous écarter de l'objectif. Mais comment déterminez-vous que vous suivez la bonne stratégie de test? Pour cela, vous devez vous en tenir à certains principes de test de base. Voici les sept principes de test courants qui sont largement pratiqués dans l'industrie du logiciel.
Pour comprendre cela, envisagez un scénario dans lequel vous déplacez un fichier du dossier A vers le dossier B.
Pensez à toutes les façons possibles de tester cela.
Outre les scénarios habituels, vous pouvez également tester les conditions suivantes
- Tentative de déplacement du fichier lorsqu'il est ouvert
- Vous ne disposez pas des droits de sécurité pour coller le fichier dans le dossier B
- Le dossier B se trouve sur un lecteur partagé et la capacité de stockage est pleine.
- Le dossier B a déjà un fichier avec le même nom, en fait, la liste est sans fin
- Ou supposons que vous ayez 15 champs d'entrée à tester, chacun ayant 5 valeurs possibles, le nombre de combinaisons à tester serait de 5 15
Si vous deviez tester l'ensemble des combinaisons possibles, le temps d'exécution et les coûts du projet augmenteraient de façon exponentielle. Nous avons besoin de certains principes et stratégies pour optimiser l'effort de test
Voici les 7 principes:
1) Un test exhaustif n'est pas possible
Oui! Des tests exhaustifs ne sont pas possibles. Au lieu de cela, nous avons besoin de la quantité optimale de tests basée sur l'évaluation des risques de l'application.
Et la question à un million de dollars est: comment déterminez-vous ce risque?
Pour répondre à cela, faisons un exercice
À votre avis, quelle opération est la plus susceptible de provoquer l'échec de votre système d'exploitation?
Je suis sûr que la plupart d'entre vous l'auraient deviné, ouvrir 10 applications différentes en même temps.
Donc, si vous testiez ce système d'exploitation, vous vous rendriez compte que des défauts sont susceptibles d'être trouvés dans une activité multitâche et doivent être testés de manière approfondie, ce qui nous amène à notre prochain principe de clustering des défauts.
2) Regroupement des défauts
Clustering de défauts qui indique qu'un petit nombre de modules contiennent la plupart des défauts détectés. C'est l'application du principe de Pareto aux tests logiciels: environ 80% des problèmes se retrouvent dans 20% des modules.
Par expérience, vous pouvez identifier ces modules à risque. Mais cette approche a ses propres problèmes
Si les mêmes tests sont répétés encore et encore, les mêmes cas de test ne trouveront plus de nouveaux bogues.
3) Paradoxe des pesticides
L'utilisation répétée du même mélange de pesticides pour éradiquer les insectes pendant l'élevage conduira avec le temps les insectes à développer une résistance au pesticide, ce qui rendra inefficace les pesticides sur les insectes. Il en va de même pour les tests de logiciels. Si le même ensemble de tests répétitifs est effectué, la méthode sera inutile pour découvrir de nouveaux défauts.
Pour surmonter cela, les cas de test doivent être régulièrement revus et révisés, en ajoutant de nouveaux et différents cas de test pour aider à trouver plus de défauts.
Les testeurs ne peuvent pas simplement dépendre des techniques de test existantes. Il doit constamment chercher à améliorer les méthodes existantes pour rendre les tests plus efficaces. Mais même après toute cette sueur et ce travail acharné lors des tests, vous ne pouvez jamais prétendre que votre produit est exempt de bogues. Pour ramener à la maison ce point, voyons cette vidéo du lancement public de Windows 98
Vous pensez qu'une entreprise comme MICROSOFT n'aurait pas testé son OS à fond et risquerait sa réputation juste pour voir son OS planter lors de son lancement public!
4) Les tests montrent une présence de défauts
Par conséquent, le principe du test stipule que - Le test parle de la présence de défauts et ne parle pas de l'absence de défauts. c'est-à-dire que les tests de logiciels réduisent la probabilité que des défauts non découverts restent dans le logiciel, mais même si aucun défaut n'est détecté, ce n'est pas une preuve d'exactitude.
Mais que se passe-t-il si vous travaillez très dur, en prenant toutes les précautions nécessaires et que votre logiciel est à 99% exempt de bogues. Et le logiciel ne répond pas aux besoins et aux exigences des clients.
Cela nous amène à notre prochain principe, qui stipule que - Absence d'erreur
5) Absence d'erreur - erreur
Il est possible qu'un logiciel exempt de bogues à 99% soit toujours inutilisable. Cela peut être le cas si le système est testé de manière approfondie pour la mauvaise exigence. Les tests de logiciels ne consistent pas simplement à trouver des défauts, mais également à vérifier que les logiciels répondent aux besoins de l'entreprise. L'absence d'erreur est une erreur, c'est-à-dire que la recherche et la correction des défauts n'aide pas si la construction du système est inutilisable et ne répond pas aux besoins et exigences de l'utilisateur.
Pour résoudre ce problème, le prochain principe de test stipule que les premiers tests
6) Test précoce
Test précoce - Les tests doivent commencer le plus tôt possible dans le cycle de vie du développement logiciel. Pour que tout défaut dans les exigences ou la phase de conception soit détecté dès les premiers stades. Il est beaucoup moins coûteux de réparer un défaut dans les premiers stades du test. Mais à quelle heure faut-il commencer les tests? Il est recommandé de commencer à trouver le bogue au moment où les exigences sont définies. Plus d'informations sur ce principe dans un didacticiel de formation ultérieur.
7) Les tests dépendent du contexte
Les tests dépendent du contexte, ce qui signifie essentiellement que la façon dont vous testez un site de commerce électronique sera différente de la façon dont vous testez une application commerciale prête à l'emploi. Tous les logiciels développés ne sont pas identiques. Vous pouvez utiliser une approche, des méthodologies, des techniques et des types de test différents en fonction du type d'application. Par exemple, les tests, tout système de point de vente dans un magasin de détail sera différent du test d'un guichet automatique.
Mythe: "Les principes sont juste pour référence. Je ne les utiliserai pas dans la pratique."
C'est tellement faux. Les principes de test vous aideront à créer une stratégie de test efficace et à rédiger des cas de test de détection d'erreurs.
Mais apprendre les principes des tests, c'est comme apprendre à conduire pour la première fois.
Au départ, pendant que vous apprenez à conduire, vous faites attention à tout comme les changements de vitesse, la vitesse, la tenue de route de l'embrayage, etc. De telle sorte que vous avez même des conversations avec d'autres passagers de la voiture.
Il en va de même pour les principes de test. Les testeurs expérimentés ont intériorisé ces principes à un niveau où ils les appliquent même sans réfléchir. D'où le mythe selon lequel les principes ne sont pas utilisés dans la pratique n'est tout simplement pas vrai.