Menu

7 Principes des tests logiciels: clustering de défauts et principe de Pareto

  • Principal
  • Autre
  • 7 Principes des tests logiciels: clustering de défauts et principe de Pareto

7 principles software testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Sept principes de test de logiciels: y compris plus de détails sur la classification des défauts, le principe de Pareto et le paradoxe des pesticides.

Je suis sûr que tout le monde est conscient du ' Sept principes de test logiciel ».

Ces principes de test fondamentaux aident les équipes de test à utiliser leur temps et leurs efforts pour rendre le processus de test efficace. Dans cet article, nous apprendrons en détail deux principes à savoir Regroupement des défauts, principe de Pareto et paradoxe des pesticides .

7 principes de test logiciel

Ce que vous apprendrez:

Sept principes de test logiciel

Avant d'approfondir ces deux principes, comprenons brièvement les sept principes du test logiciel.

Explorons!!

# 1) Les tests montrent la présence de défauts

Chaque application ou produit est mis en production après une quantité suffisante de tests par différentes équipes ou passe par différentes phases telles que les tests d'intégration de système, les tests d'acceptation des utilisateurs et les tests bêta, etc.

Alors avez-vous déjà vu ou entendu de l'une des équipes de test qu'elle a testé le logiciel complètement et qu'il n'y a aucun défaut dans le logiciel ? Au lieu de cela, chaque équipe de test confirme que le logiciel répond à toutes les exigences de l'entreprise et qu'il fonctionne selon les besoins de l'utilisateur final.

Dans l'industrie des tests de logiciels, personne ne dira qu'il y a aucun défaut dans le logiciel, ce qui est tout à fait vrai car les tests ne peuvent pas prouver que le logiciel est sans erreur ou sans défaut.

Cependant, l'objectif des tests est de trouver de plus en plus de défauts cachés en utilisant différentes techniques et méthodes. Les tests peuvent révéler des défauts non découverts et si aucun défaut n'est détecté, cela ne signifie pas que le logiciel est exempt de défauts.

Exemple 1 :

Considérons une application bancaire, cette application est minutieusement testée et subit différentes phases de tests comme SIT, UAT etc. et actuellement aucun défaut n'est identifié dans le système.

Cependant, il peut y avoir une possibilité que dans l'environnement de production, le client réel essaie une fonctionnalité qui est rarement utilisée dans le système bancaire et les testeurs ont négligé cette fonctionnalité, donc aucun défaut n'a été trouvé jusqu'à ce jour ou le code n'a jamais été touché par les développeurs. .

Exemple 2:

Nous avons vu plusieurs publicités pour des savons, du dentifrice, du lavage des mains ou des sprays désinfectants, etc. à la télévision.

Considérez une publicité sur le lavage des mains qui dit à la télévision que 99% des germes peuvent être éliminés si ce lavage des mains spécifique est utilisé. Cela prouve clairement que le produit n'est pas à 100% exempt de germes. Ainsi, dans notre concept de test, nous pouvons dire qu'aucun logiciel n'est exempt de défauts.

# 2) Test précoce

Les testeurs doivent s'impliquer à un stade précoce du cycle de vie du développement logiciel (SDLC). Ainsi, les défauts lors de la phase d'analyse des besoins ou d'éventuels défauts de documentation peuvent être identifiés. Le coût impliqué dans la correction de tels défauts est très inférieur par rapport à ceux qui sont constatés au cours des étapes ultérieures des tests.

Considérez l'image ci-dessous qui montre comment le coût de la correction des défauts augmente à mesure que les tests se déplacent vers la production en direct.

test précoce - coût de réparation des défauts

(image la source )

L'image ci-dessus montre que le coût requis pour réparer un défaut détecté lors de l'analyse des exigences est moindre et qu'il continue d'augmenter à mesure que nous nous dirigeons vers la phase de test ou de maintenance.

Maintenant la question est à quelle heure le test doit-il commencer ?

Une fois les exigences finalisées, les testeurs doivent participer aux tests. Les tests doivent être effectués sur les documents d'exigences, les spécifications ou tout autre type de document afin que, si les exigences sont mal définies, elles puissent être corrigées immédiatement plutôt que de les corriger dans la phase de développement.

# 3) Des tests exhaustifs ne sont pas possibles

Il n'est pas possible de tester toutes les fonctionnalités avec toutes les combinaisons valides et non valides de données d'entrée pendant le test réel. Au lieu de cette approche, le test de quelques combinaisons est envisagé en fonction de la priorité en utilisant différentes techniques.

Des tests exhaustifs nécessiteront des efforts illimités et la plupart de ces efforts sont inefficaces. De plus, les échéanciers du projet ne permettront pas de tester autant de combinaisons. Par conséquent, il est recommandé de tester les données d'entrée en utilisant différentes méthodes telles que le partitionnement d'équivalence et l'analyse des valeurs limites.

Par exemple ,Supposons que nous ayons un champ de saisie qui n'accepte que les alphabets, les caractères spéciaux et les nombres de 0 à 1000. Imaginez le nombre de combinaisons apparaissant pour les tests, il n'est pas possible de tester toutes les combinaisons pour chaque type d'entrée.

Les efforts de test requis pour tester seront énormes et auront également un impact sur le calendrier et le coût du projet. Par conséquent, on dit toujours que des tests exhaustifs ne sont pratiquement pas possibles.

# 4) Les tests dépendent du contexte

Il existe plusieurs domaines disponibles sur le marché comme la banque, l'assurance, le médical, les voyages, la publicité, etc. et chaque domaine a un certain nombre d'applications. Également pour chaque domaine, leurs applications ont des exigences, des fonctions, des objectifs de test différents, des risques, des techniques, etc.

Différents domaines sont testés différemment, les tests sont donc purement basés sur le contexte du domaine ou de l'application.

Par exemple ,tester une application bancaire est différent de tester une application de commerce électronique ou de publicité. Le risque associé à chaque type d'application est différent, il n'est donc pas efficace d'utiliser la même méthode, technique et type de test pour tester tous les types d'application.

# 5) Regroupement des défauts

Lors des tests, il se peut que la plupart des défauts détectés soient liés à un petit nombre de modules. Il peut y avoir plusieurs raisons à cela, comme les modules peuvent être complexes, le codage lié à ces modules peut être compliqué, etc.

C'est le principe de Pareto des tests logiciels où 80% des problèmes se trouvent dans 20% des modules. Nous en apprendrons plus sur le clustering des défauts et le principe de Pareto plus loin dans cet article.

# 6) Paradoxe des pesticides

Le principe de Pesticide Paradox dit que si le même ensemble de cas de test est exécuté encore et encore au cours de la période de temps, alors cet ensemble de tests n'est pas suffisamment capable d'identifier de nouveaux défauts dans le système.

Afin de surmonter ce «paradoxe des pesticides», l'ensemble des cas de test doit être régulièrement revu et révisé. Si nécessaire, un nouvel ensemble de cas de test peut être ajouté et les cas de test existants peuvent être supprimés s'ils ne peuvent plus trouver de défauts dans le système.

# 7) Absence d'erreur

Si le logiciel est entièrement testé et si aucun défaut n'est détecté avant sa sortie, nous pouvons dire que le logiciel est exempt de défauts à 99%. Mais que faire si ce logiciel est testé contre de mauvaises exigences? Dans de tels cas, même trouver des défauts et les corriger à temps ne serait pas utile car les tests sont effectués sur des exigences erronées qui ne correspondent pas aux besoins de l'utilisateur final.

Par exemple, Supposons que l'application soit liée à un site de commerce électronique et aux exigences relatives à la fonctionnalité «Panier ou Panier» qui est mal interprétée et testée. Ici, même trouver plus de défauts n'aide pas à faire passer l'application dans la phase suivante ou dans l'environnement de production.

Ce sont les sept principes du test logiciel.

Voyons maintenant Regroupement des défauts, principe de Pareto et paradoxe des pesticides détail .

Regroupement de défauts

Lors du test d'un logiciel, les testeurs rencontrent principalement une situation dans laquelle la plupart des défauts trouvés sont liés à certaines fonctionnalités spécifiques et le reste des fonctionnalités aura un nombre inférieur de défauts.

Le regroupement de défauts signifie un petit nombre de modules contenant la plupart des défauts. Fondamentalement, les défauts ne sont pas répartis uniformément sur l'ensemble de l'application, mais les défauts sont concentrés ou centralisés sur deux ou trois fonctionnalités.

Parfois, cela est possible en raison de la complexité de l'application, le codage peut être complexe ou délicat, un développeur peut faire une erreur qui pourrait affecter une fonctionnalité ou un module spécifique uniquement.

Le clustering de défauts est basé sur ' Principe de Pareto », Également connu sous le nom de Règle 80-20 . Cela signifie que 80% des défauts constatés sont dus à 20% des modules de l'application. Le concept de principe de Pareto a été initialement défini par un économiste italien - Vilfrodo Pareto .

Si les testeurs examinent 100 défauts, alors il ne sera pas clair s'il y a une signification sous-jacente à ces 100 défauts. Mais si ces 100 défauts sont classés en fonction de certains critères spécifiques, il se peut que les testeurs comprennent qu'un grand nombre de défauts n'appartiennent qu'à quelques modules spécifiques.

Par exemple ,Prenons l'image ci-dessous qui est testée pour l'une des applications bancaires et montre que la plupart des défauts sont liés à la fonctionnalité 'Découvert'. Les autres fonctionnalités telles que le résumé de compte, le transfert de fonds, l'instruction permanente, etc., présentent un nombre limité de défauts.

Regroupement de défauts

(image la source )

L'image ci-dessus indique qu'il y a 18 défauts autour de la fonctionnalité Découvert sur un total de 32 défauts, ce qui signifie que 60% des défauts se trouvent dans le module «Découvert».

Par conséquent, les testeurs se concentrent principalement sur ce domaine lors de l'exécution pour trouver de plus en plus de défauts. Il est recommandé que les testeurs se concentrent également sur les autres modules pendant les tests.

Lorsqu'un même code ou module est testé, encore et encore, en utilisant un ensemble de cas de test que lors des itérations initiales, alors le nombre de défauts est élevé, cependant, après une certaine itération, le nombre de défauts sera considérablement réduit. Le regroupement des défauts indique que la zone sujette aux défauts doit être testée de manière approfondie pendant les tests de régression.

Paradoxe des pesticides

Lorsque l'un des modules présente plus de défauts, les testeurs déploient des efforts supplémentaires pour tester ce module.

Après quelques itérations de test, la qualité du code s'améliore et le nombre de défauts commence à baisser car la plupart des défauts sont corrigés par l'équipe de développement, car les développeurs sont également prudents lors du codage d'un module particulier où les testeurs ont trouvé plus de défauts.

Par conséquent, à un moment donné, la plupart des défauts sont découverts et corrigés afin qu'aucun nouveau défaut ne soit trouvé dans ce module.

Cependant, il peut parfois arriver que tout en étant extrêmement prudent lors du codage sur un module particulier (ici dans notre cas, le ' Découvert ”), Le développeur peut négliger les autres modules pour le coder correctement ou les modifications apportées à ce module particulier peuvent avoir un impact négatif sur les autres fonctionnalités telles que le résumé de compte, le transfert de fonds et les instructions permanentes.

Lorsque les testeurs utilisent le même ensemble de cas de test pour exécuter le module où la plupart des défauts sont trouvés (module de découvert), après avoir corrigé ces défauts par les développeurs, ces cas de test ne sont pas très efficaces pour trouver de nouveaux défauts. En tant que flux de bout en bout du découvert, le module est testé minutieusement et les développeurs ont également écrit le code de ce module avec prudence.

Il est nécessaire de réviser et de mettre à jour ces cas de test. C'est également une bonne idée d'ajouter de nouveaux cas de test afin que de nouveaux et plus de défauts puissent être trouvés dans différents domaines du logiciel ou de l'application.

Méthodes préventives du paradoxe des pesticides

Il existe deux options par lesquelles nous pouvons empêcher Pesticide Paradox, comme indiqué ci-dessous:

à) Écrivez un nouvel ensemble de cas de test qui se concentrera sur différents domaines ou modules (autres que le module précédent sujet aux défauts - Exemple: «Découvert») du logiciel.

b) Préparez de nouveaux cas de test et ajoutez-les aux cas de test existants.

Dans le ' méthode A », Les testeurs peuvent trouver plus de défauts dans les autres modules sur lesquels ils n'étaient pas concentrés lors des tests précédents ou les développeurs n'étaient pas très prudents lors du codage.

Dans notre exemple ci-dessus, les testeurs peuvent trouver plus de défauts dans les modules Résumé de compte, Transfert de fonds ou Instructions permanentes à l'aide du nouvel ensemble de scénarios de test.

Mais il peut arriver que les testeurs négligent le module précédent ( Exemple: «Découvert») où la plupart des défauts ont été trouvés dans l'itération précédente et cela pourrait être un risque car ce module (Découvert) aurait pu être injecté avec les nouveaux défauts après codage des autres modules.

Dans le ' méthode B », De nouveaux cas de test sont préparés afin que de nouveaux défauts potentiels puissent être trouvés dans le reste des modules.

Ici, dans notre exemple, les scénarios de test nouvellement créés pourront aider à identifier les défauts dans les modules tels que le résumé de compte, le transfert de fonds et l'instruction permanente. Cependant, les testeurs ne peuvent pas ignorer les anciens modules sujets aux défauts ( Exemple: «Découvert») car ces nouveaux cas de test sont fusionnés avec les cas de test existants.

Les cas de test existants étaient davantage axés sur le module «Découvert» et les nouveaux cas de test étaient axés sur les autres modules. Par conséquent, tous les jeux de cas de test sont exécutés au moins une fois même un changement de code se produit sur n'importe quel module. Cela garantira que la régression appropriée est exécutée et que le défaut peut être identifié en raison de ce changement de code.

En utilisant la deuxième approche, le nombre total de cas de test est considérablement élevé et entraîne plus d'efforts et de temps requis pour l'exécution. Cela aura évidemment un impact sur les délais du projet et, surtout, sur le budget du projet.

Par conséquent, pour surmonter ce problème, les cas de test redondants peuvent être examinés puis supprimés. Il existe de nombreux cas de test qui deviennent inutiles après l'ajout de nouveaux cas de test et la modification des cas de test existants.

Il est nécessaire de vérifier quels cas de test ont échoué afin d'identifier les défauts des 5 dernières itérations (supposons 5 itérations) et quels cas de test ne sont pas très importants. Il se peut également que le flux unique couvert dans quelques cas de test puisse être couvert dans un autre cas de test de bout en bout et que les cas de test ayant un flux unique puissent être supprimés.

Ceci, à son tour, réduira le nombre total de cas de test.

Par exemple ,nous avons 50 cas de test pour couvrir un module particulier et nous avons vu que sur ces 50 cas de test, 20 cas de test n'ont pas réussi à détecter un nouveau défaut au cours des dernières itérations de test (supposons 5 itérations). Donc, ces 20 cas de test doivent être examinés en profondeur et nous devons vérifier l'importance de ces cas de test et une décision peut être prise en conséquence, soit de conserver les 20 cas de test ou de les supprimer.

Avant de supprimer un cas de test, vérifiez que le flux de fonctionnalités couvert dans ces cas de test est couvert dans un autre cas de test. Ce processus doit être suivi dans tous les modules afin que le nombre total de cas de test soit considérablement réduit. Cela garantira que le nombre total de cas de test est réduit, mais il y a toujours une couverture des exigences à 100%.

Cela signifie que tous les cas de test restants couvrent toutes les exigences de l'entreprise, il n'y a donc aucun compromis sur la qualité.

Conclusion

Le test logiciel est une étape essentielle du SDLC car il vérifie si le logiciel fonctionne ou non selon les besoins de l'utilisateur final.

Les tests identifient autant de défauts que possible. Par conséquent, pour effectuer des tests de manière efficace et efficiente, tout le monde doit être conscient et comprendre clairement les sept principes du test logiciel et ils sont connus comme les piliers des tests.

La plupart des testeurs ont mis en œuvre et expérimenté ces principes lors des tests réels.

Questions et réponses d'entrevue avec un administrateur Salesforce

En général, le terme principe désigne les règles ou les lois qui doivent être suivies. Par conséquent, tout le monde dans l'industrie des tests de logiciels doit suivre ces sept principes, et si quelqu'un ignore l'un de ces principes, cela peut coûter très cher au projet.

Bonne lecture!!

lecture recommandée

^