Test de logiciels - Mythes

Voici quelques-uns des mythes les plus courants sur les tests de logiciels.

Mythe 1: les tests sont trop coûteux

Reality- Il y a un dicton, payez moins pour les tests pendant le développement logiciel ou payez plus pour la maintenance ou la correction plus tard. Les tests précoces permettent d'économiser du temps et des coûts dans de nombreux aspects, mais la réduction du coût sans test peut entraîner une conception incorrecte d'une application logicielle rendant le produit inutile.

Mythe 2: Les tests prennent du temps

Reality- Pendant les phases SDLC, les tests ne sont jamais un processus chronophage. Cependant, diagnostiquer et corriger les erreurs identifiées lors de tests appropriés est une activité longue mais productive.

Mythe 3: seuls les produits entièrement développés sont testés

Reality- Il ne fait aucun doute que les tests dépendent du code source, mais l'examen des exigences et le développement des cas de test sont indépendants du code développé. Cependant, une approche itérative ou incrémentale en tant que modèle de cycle de vie de développement peut réduire la dépendance des tests sur le logiciel entièrement développé.

Mythe 4: Un test complet est possible

Reality- Cela devient un problème lorsqu'un client ou un testeur pense qu'un test complet est possible. Il est possible que tous les chemins aient été testés par l'équipe mais la réalisation de tests complets n'est jamais possible. Il peut y avoir des scénarios qui ne sont jamais exécutés par l'équipe de test ou le client pendant le cycle de vie du développement logiciel et peuvent être exécutés une fois le projet déployé.

Mythe 5: Un logiciel testé est sans bogue

Reality - C'est un mythe très courant auquel les clients, les chefs de projet et l'équipe de direction croient. Personne ne peut affirmer avec une certitude absolue qu'une application logicielle est 100% sans bogue, même si un testeur doté de superbes compétences en test a testé l'application .

Mythe 6: les défauts manqués sont dus aux testeurs

Reality- Ce n'est pas une approche correcte pour blâmer les testeurs pour les bogues qui restent dans l'application même après que les tests ont été effectués. Ce mythe concerne les contraintes de changement de temps, de coût et d'exigences. Cependant, la stratégie de test peut également entraîner des bogues manqués par l'équipe de test.

Mythe 7: Les testeurs sont responsables de la qualité du produit

Reality- C'est une interprétation erronée très courante que seuls les testeurs ou l'équipe de test devraient être responsables de la qualité du produit. Les responsabilités des testeurs incluent l'identification des bogues aux parties prenantes, puis c'est à eux de décider s'ils vont corriger le bogue ou publier le logiciel. La sortie du logiciel à l'époque met plus de pression sur les testeurs, car ils seront blâmés pour toute erreur.

Mythe 8: l'automatisation des tests doit être utilisée dans la mesure du possible pour réduire le temps

Reality- Oui, il est vrai que l'automatisation des tests réduit le temps de test, mais il n'est pas possible de démarrer l'automatisation des tests à tout moment pendant le développement logiciel. L'automate de test doit être démarré lorsque le logiciel a été testé manuellement et est stable dans une certaine mesure. De plus, l'automatisation des tests ne peut jamais être utilisée si les exigences changent constamment.

Mythe 9: Tout le monde peut tester une application logicielle

Reality- Les personnes extérieures à l'industrie informatique pensent et même croient que n'importe qui peut tester un logiciel et tester n'est pas un travail créatif. Cependant, les testeurs savent très bien qu'il s'agit d'un mythe. Penser à des scénarios alternatifs, essayer de planter un logiciel avec l'intention d'explorer des bogues potentiels n'est pas possible pour la personne qui l'a développé.

Mythe 10: La seule tâche d'un testeur est de trouver des bogues

Reality- La recherche de bogues dans un logiciel est la tâche des testeurs, mais en même temps, ce sont des experts du domaine du logiciel en question. Les développeurs ne sont responsables que du composant ou du domaine spécifique qui leur est assigné, mais les testeurs comprennent le fonctionnement général du logiciel, quelles sont les dépendances et les impacts d'un module sur un autre module.