Menu

Tests ad hoc: comment trouver des défauts sans processus de test formel

ad hoc testing how find defects without formal testing process

Essayez Notre Instrument Pour Éliminer Les Problèmes

Le terme même ad hoc implique le manque de structure ou quelque chose qui n'est pas méthodique. Quand tu parles de tests ad hoc , cela signifie que c'est une forme de boîte noire ou des tests de comportement effectués sans aucun processus formel en place.

Le processus formel ici signifie avoir une documentation telle que des documents d'exigence, des plans de test, des cas de test et une planification de test appropriée en termes de calendrier et d'ordre des tests effectués. En outre, les actions effectuées pendant les tests ne sont généralement pas documentées.

Tests ad hoc

Ceci est principalement fait dans le but d'essayer de découvrir des défauts ou des failles qui ne peuvent pas être capturés par des processus traditionnels ou formels suivis pendant le cycle de test.

Comme nous l'avons déjà compris, l'essence de ces tests réside dans l'absence de méthode de test formelle ou structurée. Lorsqu'un tel type de techniques de tests aléatoires est effectué, il est évident que les testeurs effectuent cela sans aucun cas d'utilisation particulier à l'esprit dans le but de casser le système.

Par conséquent, il est encore plus évident qu'une telle méthodologie de test intuitive ou créative nécessite le testeur doit être extrêmement qualifié, capable et avoir une connaissance approfondie du système. Les tests ad hoc garantissent que les tests effectués sont complets et sont particulièrement très utiles pour déterminer l'efficacité du bucket de test.

Lecture recommandée=> Tests exploratoires - Comment penser au-delà des limites des tests traditionnels?

Ce que vous apprendrez:

Commençons par un exemple de test ad hoc

Voici un exemple de la façon dont nous pouvons effectuer ces tests en ce qui concerne l'assistant d'interface utilisateur.

Supposons que vous deviez créer un plan ou un modèle pour un type de tâche à effectuer à l'aide de cet assistant d'interface utilisateur. L'assistant est une série de volets contenant des entrées utilisateur telles que le nom, la description, etc.

Au fur et à mesure de la progression de l'assistant: disons sur l'un des volets, les données utilisateur doivent être saisies, ce qui implique que l'assistant d'interface utilisateur lance une boîte de dialogue contextuelle qui ajoute les données associées pour terminer l'assistant et déployer / activer l'assistant.

Pour tester ce testeur fait ses tests réguliers tels que:

questions d'entretien de sélénium pour 8 ans d'expérience
  • Terminez l'assistant avec toutes les données valides et créez le plan.
  • Annulez l'assistant à mi-chemin.
  • Modifiez un plan créé via l'assistant.
  • Supprimez le plan créé et voyez qu'il n'y en a aucun résidu.
  • Entrez une valeur négative dans l'assistant et voyez les messages d'erreur appropriés sont affichés.

Maintenant, pour l'exemple ci-dessus voici quelques cas de test pour les tests ad hoc qui pourrait être effectué pour découvrir autant de défauts que possible:

  • Lorsque vous essayez d'ajouter des données négatives, ajoutez certains caractères spéciaux qui ne sont pas limités pour voir s'ils sont gérés correctement. Par exemple, Parfois, les assistants ne limitent pas {ou (accolades, mais dans certaines situations, cela peut entrer en conflit avec le code basé sur la langue dans laquelle il est écrit et entraîner un comportement très peu fiable.
  • Un autre test concerne spécifiquement les fenêtres contextuelles. Un utilisateur peut provoquer le lancement de la fenêtre contextuelle, puis essayer d'appuyer sur le bouton de retour arrière du clavier. Plusieurs fois, j'ai observé que cela faisait disparaître complètement l'assistant d'arrière-plan et toutes les données utilisateur entrées jusqu'au moment où la fenêtre contextuelle était lancée sont perdues!

Caractéristiques des tests ad hoc:

Si vous notez les scénarios ci-dessus, vous verrez des caractéristiques très distinctes de ce type de test.

Elles sont:

  • Ils sont toujours en ligne avec l'objectif du test. Cependant, ce sont certains tests drastiques effectués dans le but de briser le système.
  • Le testeur doit avoir une connaissance et une connaissance complètes du système testé. Le résultat de ces tests trouve des bogues qui tentent de mettre en évidence les lacunes du processus de test.
  • En regardant également les deux tests ci-dessus, la réaction naturelle à cela serait que - ce type de test ne peut être effectué qu'une seule fois car il n'est pas faisable pour un nouveau test à moins qu'un défaut ne soit associé.

Quand faisons-nous des tests ad hoc?

Une question à un million de dollars en effet!

La plupart du temps, les équipes de test sont toujours surchargées de fonctionnalités à tester dans des délais limités. Dans ce laps de temps limité, de nombreuses activités de test dérivées du processus formel doivent également être exécutées. Dans de telles situations, les tests ad hoc trouvent leur place dans les tests sont minces.

Cependant, d'après mon expérience, une série de tests ad hoc peut faire des merveilles pour la qualité du produit et soulever de nombreuses questions de conception.

Étant donné que les tests ad hoc sont davantage une technique de test «enfant sauvage» qui n'a pas besoin d'être structurée, la recommandation générale est qu'elle doit être effectuée après l'exécution du bucket de test actuel. Un autre point de vue est que cela pourrait être fait lorsque des tests détaillés ne peuvent pas être effectués en raison de moins de temps.

À mon avis, je dirais que Les tests ad hoc peuvent être effectués presque à tout moment - au début, vers le milieu et vers la fin! Il trouve juste sa place à tout moment. Cependant, lorsque des tests ad hoc doivent être effectués pour obtenir une valeur maximale, il est préférable de le juger par un testeur expérimenté qui possède une connaissance approfondie du système testé.

Quand ne pas exécuter?

Si la question précédente valait un million de dollars, cela devrait en valoir un milliard!

Bien que nous ayons établi à quel point les tests ad hoc peuvent être efficaces et fructueux, en tant que testeur qualifié et compétent, nous devons également déchiffrer quand ne pas investir dans ce type de test. Bien que ce soit à la discrétion du testeur, voici quelques recommandations / exemples lorsque cela peut ne pas être nécessaire.

  • Évitez ce test lorsqu'il existe un scénario de test pour lequel un défaut existe. Dans une telle situation, il est nécessaire de documenter le point de défaillance du cas de test, puis de vérifier / tester à nouveau le défaut lorsqu'il est corrigé. Par conséquent, cela ne sera pas applicable ici.
  • Il peut également y avoir certains scénarios où des clients ou des clients peuvent être invités à tester la version bêta du logiciel . Dans de tels cas, ces tests ne doivent pas être effectués.
  • Un autre scénario est celui où un écran d'interface utilisateur très simple est ajouté. Les tests traditionnels positifs et négatifs devraient suffire ici pour faire ressortir le maximum de défauts.

Types de tests ad hoc

Les tests ad hoc peuvent être classés en trois catégories ci-dessous:

# 1) Test d'amis

Dans cette forme de test, il y aura un membre de test et un membre de développement qui seront choisis pour travailler sur le même module. Juste après le le développeur termine le test unitaire , le le testeur et le développeur s'assoient ensemble et travaillez sur le module. Ce type de test permet à la fonctionnalité d'être vue dans une portée plus large pour les deux parties.

Le développeur aura une perspective de tous les différents tests exécutés par le testeur et le testeur aura une perspective de la conception inhérente qui l'aidera à éviter de concevoir des scénarios invalides, empêchant ainsi les défauts invalides. Cela aidera l'un à penser comme l'autre.

# 2) Test de paires

Dans ce test, deux testeurs travaillent ensemble sur un module avec la même configuration de test partagée entre eux. L'idée derrière cette forme de test est que les deux testeurs réfléchissent à des idées et à des méthodes pour avoir un certain nombre de défauts. Les deux peuvent partager le travail de test et faire la documentation nécessaire de toutes les observations faites.

# 3) Test de singe

Ces tests sont principalement effectués au niveau des tests unitaires. Le testeur analyse les données ou les tests de manière complètement aléatoire pour s'assurer que le système est capable de résister à toute panne. Ces tests peuvent être classés en deux catégories:

programme de sauvegarde gratuit pour windows 7

Avantages des tests ad hoc

Ce test garantit au testeur une grande puissance pour être aussi créatif que nécessaire.

Cela augmente la qualité et l'efficacité des tests comme ci-dessous:

  • Le plus grand avantage qui ressort est qu'un testeur peut trouver le nombre de défauts que dans les tests traditionnels en raison des différentes méthodes innovantes qu'il peut appliquer pour tester le logiciel.
  • Cette forme de test peut être appliquée n'importe où dans le SDLC; il n’est pas seulement limité à l’équipe de test. Les développeurs peuvent également effectuer ces tests, ce qui les aiderait à mieux coder et à prédire quels problèmes pourraient survenir.
  • Il peut être couplé à un autre test pour obtenir les meilleurs résultats, ce qui peut parfois réduire le temps nécessaire aux tests réguliers. Cela permettrait de générer des cas de test de meilleure qualité et une meilleure qualité du produit dans son ensemble.
  • Il n'impose aucune documentation à faire, ce qui évite la charge supplémentaire sur le testeur. Un testeur peut se concentrer sur la compréhension de l'architecture sous-jacente.
  • Dans les cas où il n'y a pas beaucoup de temps disponible pour tester, cela peut s'avérer très précieux en termes de couverture et de qualité des tests.

Inconvénients des tests ad hoc

Les tests ad hoc présentent également quelques inconvénients. Jetons un coup d'œil à certains des inconvénients prononcés:

Comme il n’est pas très organisé et qu’il n’ya pas de documentation obligatoire, le problème le plus évident est que le testeur doit se souvenir et se souvenir de tous les détails des scénarios ad hoc en mémoire. Cela peut être encore plus difficile, en particulier dans les scénarios où il y a beaucoup d'interaction entre différents composants.

  • Suite au premier point, cela aurait également pour conséquence de ne pas pouvoir recréer des défauts dans les tentatives ultérieures si on lui demandait des informations.
  • Une autre question très importante que cela met en lumière est la responsabilité de l'effort. Comme cela n'est pas planifié / structuré, il n'y a aucun moyen de rendre compte du temps et des efforts investis dans ce type de test.
  • Les tests ad-hoc ne doivent être effectués que par un testeur très compétent et compétent dans l'équipe, car ils exigent d'être proactif et intuition en termes de prévision des zones potentiellement défectueuses.

Meilleures pratiques pour rendre ces tests plus efficaces

Nous avons longuement discuté des forces et des faiblesses associées à ces tests.

Idéalement, les tests ad-hoc devraient trouver leur place dans le SDLC, mais s'ils ne sont pas abordés de manière appropriée, ils peuvent s'avérer coûteux et une perte de temps de test précieux. Voici donc quelques conseils pour rendre les tests ad hoc efficaces:

# 1) Identifiez les zones sujettes aux défauts:

Lorsque vous avez une bonne emprise sur le test d'un logiciel particulier, vous conviendrez que certaines fonctionnalités seront plus sujettes aux erreurs que les autres. Si vous êtes nouveau dans le système, allez-y et vérifiez les fonctionnalités par rapport aux défauts qui s’y rapportent.

Le nombre de défauts dans une fonction particulière vous montrera qu'elle est sensible et vous devez choisir précisément cette zone pour effectuer des tests ad hoc. Cela s'avère être un moyen très efficace d'exposer certains défauts graves.

# 2) Renforcement de l'expertise:

Sans aucun doute, un testeur qui a plus d'expérience est plus intuitif et peut deviner où les erreurs pourraient se trouver, par rapport à quelqu'un qui n'a pas beaucoup d'expérience. Je dirais, expérimenté ou non, c’est à l’individu de franchir le pas et de développer son expertise sur le système testé.

Oui, les testeurs expérimentés ont un avantage car leurs compétences acquises au fil des ans sont utiles, mais les nouveaux testeurs devraient l'utiliser comme plate-forme pour acquérir autant de connaissances que possible afin de concevoir de meilleurs scénarios ad hoc.

# 3) Créez des catégories de test:

Une fois que vous connaissez la liste des fonctionnalités à tester, prenez quelques minutes pour décider de la manière dont vous classeriez ces fonctionnalités et les tester. Par exemple, vous devez décider de tester les fonctionnalités les plus visibles et les plus couramment utilisées par l’utilisateur avant toute autre chose, car elles semblent essentielles au succès du logiciel.

Ensuite, vous pouvez les catégoriser en fonction de leurs fonctionnalités / priorités et les tester segment par segment.

Un autre exemple où cela est particulièrement important est s'il y a intégration entre des composants ou des modules. Dans ces cas, de nombreuses anomalies peuvent survenir. L'utilisation de la catégorisation aiderait à aborder ce type de test au moins une ou deux fois.

# 4) Ayez un plan approximatif:

Oui, oui, ce point pourrait vous dérouter un peu car nous avons décrit les tests ad hoc comme des tests qui ne devraient avoir aucune planification ni documentation. L'idée ici est de s'en tenir à l'essence des tests ad hoc, tout en notant quelques conseils approximatifs sur la façon dont vous envisagez de tester.

Un exemple très basique est que parfois vous ne pouvez tout simplement pas vous souvenir de tous les tests que vous avez l'intention d'effectuer. Donc, les noter vous assurerait de ne rien manquer.

# 5) Outils:

Prenons un exemple auquel nous sommes tous confrontés très fréquemment. Souvent, si vous observez, le test de la fonctionnalité en soi réussit sans qu'aucune anomalie ne soit signalée dans son comportement. Cependant, les journaux en arrière-plan pourraient signaler certaines exceptions qui pourraient être manquées par les testeurs, car cela n'entrave en aucune façon l'objectif du test.

Celles-ci pourraient même être très sévères. Il est donc très important pour nous d’apprendre et de disposer d’outils qui nous aideront à le déterminer immédiatement.

# 6) Document pour plus de défauts:

Encore une fois, je comprends que cela peut à nouveau soulever des sourcils. La documentation n'a pas besoin d'être détaillée, mais juste une petite note pour votre propre référence de tous les différents scénarios couverts, des écarts dans les étapes impliquées et enregistrez ces défauts pour la catégorie de fonctionnalité de test particulière.

Cela vous aidera également à améliorer le bucket de test global, grâce auquel vous pourrez décider comment improviser des cas de test existants ou en ajouter d'autres si nécessaire.

Conclusion

Nous avons discuté en détail des techniques de test ad hoc - ses forces, ses faiblesses, les situations où cela serait et ne serait pas bénéfique.

C'est une technique de test qui garantit de répondre et de satisfaire au maximum la créativité d'un testeur. Dans mon ensemble carrière de test , Je tire la plus grande satisfaction des tests ad-hoc car il n'y a pas de limite à l'innovation et vous finissez par être plus compétent.

Cela dit, la principale chose à retenir de toutes les informations ci-dessus serait de déterminer comment exploiter les atouts des tests ad hoc et en faire une valeur ajoutée au processus de test global et à la qualité du produit.

A propos de l'auteur: Il s'agit d'un article invité de Sneha Nadig. Elle travaille en tant que Test lead avec plus de 7 ans d'expérience dans des projets de tests manuels et d'automatisation.

Effectuez-vous des tests ad hoc sur votre projet? Quelles sont vos suggestions pour réussir les tests ad hoc?

lecture recommandée

^