Les tests ad-hoc : Comment trouver les défauts sans processus formel de test

Le terme même d’ad-hoc implique le manque de structure ou quelque chose qui n’est pas méthodique. Lorsque vous parlez de test ad-hoc, cela signifie qu’il s’agit d’une forme de boîte noire ou de test comportemental effectué sans aucun processus formel en place.

Le processus formel signifie ici avoir de la documentation comme des documents d’exigences, des plans de test, des cas de test, et une planification de test appropriée en termes de son calendrier et de l’ordre des tests effectués. En outre, toutes les actions effectuées pendant les tests ne sont généralement pas documentées.

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 les processus traditionnels ou formels suivis pendant le cycle de test.

Comme déjà compris, l’essence de ce test réside dans le fait de ne pas avoir une manière formelle ou structurée de tester. Lorsque ce type de techniques de test aléatoire est effectué, il est évident que les testeurs l’effectuent sans aucun cas d’utilisation particulier à l’esprit dans le but de casser le système.

Il est donc définitivement encore plus évident qu’une telle méthodologie de test intuitive ou créative nécessite que le testeur soit extrêmement compétent, capable et ait un savoir-faire approfondi du système. Les tests ad hoc permettent de s’assurer que les tests effectués sont complets et sont particulièrement très utiles pour déterminer l’efficacité du seau de test.

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

Commençons par un exemple de test ad hoc

Voici un exemple de la façon dont nous pouvons effectuer ce test lorsqu’il s’agit de l’assistant d’interface utilisateur.

Disons que vous devez créer un plan ou un modèle pour une sorte de tâche à effectuer en utilisant cet assistant d’interface utilisateur. L’assistant est une série de volets qui ont une entrée utilisateur comme le nom, la description, etc.

A mesure que l’assistant progresse : disons sur l’un des volets, les données de l’utilisateur doivent être saisies, ce qui implique que l’assistant UI jette une boîte pop-up contextuelle qui ajoute les données associées pour compléter l’assistant et déployer/activer l’assistant.

Pour tester cela, le testeur fait ses tests réguliers tels que :

• Compléter l’assistant avec succès avec toutes les données valides et créer le plan.
• Annuler l’assistant à mi-chemin.
• Modifier un plan créé par l’assistant.
• Supprimer le plan créé et voir qu’il n’y a aucun résidu de celui-ci.
• Entrer une valeur négative dans l’assistant et voir les messages d’erreur appropriés.

Maintenant, pour l’exemple ci-dessus voici quelques cas de tests ad-hoc qui pourraient être effectués 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 restreints pour voir s’ils sont traités correctement. Par exemple, parfois les assistants ne restreignent pas les accolades {ou [ mais dans certaines situations, cela peut entrer en conflit avec le code basé sur le langage dans lequel il est écrit, et provoquer un comportement très peu fiable.
• Un autre test concerne spécifiquement les pop-ups. Un utilisateur peut provoquer le lancement de la pop up et ensuite essayer d’appuyer sur le bouton de retour en arrière sur le clavier. Plusieurs fois, j’ai observé qu’en faisant cela, l’assistant d’arrière-plan disparaît complètement et toutes les données de l’utilisateur qui ont été saisies jusqu’au moment où la pop-up a été lancée, sont perdues !

Caractéristiques des tests ad hoc :

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

Ils sont :

• Ils sont toujours en ligne avec l’objectif du test. Cependant, ce sont certains tests drastiques effectués avec l’intention de casser le système.
• Le testeur doit avoir une connaissance et une conscience complètes du système testé. Le résultat de ce test trouve des bogues qui tentent de mettre en évidence les failles du processus de test.
• En regardant également les deux tests ci-dessus, la réaction naturelle serait que – ce type de test peut être effectué juste une fois car il n’est pas faisable pour un re-test à moins qu’il y ait un défaut 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 accablées par trop de fonctionnalités à tester dans des délais limités. Dans ce laps de temps limité, il y a beaucoup d’activités de test qui sont dérivées du processus formel qui doivent également se terminer. Dans de telles situations, les tests ad hoc trouvant leur place dans les tests sont minces.

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

Puisque le test ad-hoc est plutôt une technique de test « sauvage » qui n’a pas besoin d’être structurée, la recommandation générale est qu’il doit être effectué après l’exécution du godet de test actuel. Un autre point de vue est que cela pourrait être fait lorsque les tests détaillés ne peuvent pas être effectués en raison du manque de temps.

De mon point de vue, 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 à un moment donné. Cependant, quand le test ad-hoc doit être fait pour faire ressortir la valeur maximale est mieux jugé par un testeur expérimenté qui a une connaissance approfondie du système testé.

Quand ne pas exécuter ?

Si la question précédente valait un million de dollars, celle-ci devrait valoir un milliard !

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

• Évitez ce test lorsqu’il existe un cas de test pour lequel un défaut existe. Dans une telle situation, il est nécessaire de documenter le point d’échec du cas de test, puis de vérifier/re-tester le défaut lorsqu’il est corrigé. Par conséquent, il ne sera pas applicable ici.
• Il peut également y avoir certains scénarios où les clients ou les clients peuvent être invités à tester la version bêta du logiciel. Dans de tels cas, ce test ne devrait pas être effectué.
• Un autre scénario est lorsqu’il y a un écran d’interface utilisateur très simple qui est ajouté. Les tests positifs et négatifs traditionnels 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) Buddy Testing

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 que le développeur ait terminé les tests unitaires, le testeur et le développeur s’assoient ensemble et travaillent sur le module. Ce type de test permet de voir la fonctionnalité dans une portée plus large pour les deux parties.

Le développeur aura une perspective de tous les différents tests que le testeur exécute et le testeur aura une perspective de la façon dont la conception inhérente est ce qui l’aidera à éviter de concevoir des scénarios invalides, empêchant ainsi les défauts invalides. Cela aidera l’un à penser comme pense l’autre.

#2) Test en binôme

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 pour 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) Monkey Testing

Ce test est principalement effectué au niveau des tests unitaires. Le testeur analyse les données ou les tests de manière complètement aléatoire afin de s’assurer que le système est capable de résister à d’éventuelles pannes. Ce test peut être encore classé en deux catégories:

Les avantages du test ad hoc

Ce test garantit au testeur beaucoup de pouvoir pour être aussi créatif que nécessaire.

Cela augmente la qualité et l’efficacité du test comme ci-dessous :

• Le plus grand avantage qui ressort est qu’un testeur peut trouver le nombre de défauts que dans le test traditionnel en raison des diverses 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 ; elle n’est pas seulement limitée à l’équipe de test. Les développeurs peuvent également effectuer ces tests, ce qui les aiderait à mieux coder et également à prédire les problèmes qui pourraient survenir.
• Il peut être couplé avec un autre test pour obtenir les meilleurs résultats qui peuvent parfois réduire le temps nécessaire pour les tests réguliers. Cela permettrait de générer des cas de test de meilleure qualité et une meilleure qualité du produit dans l’ensemble.
• Il ne nécessite pas de documentation à faire ce qui évite la charge supplémentaire sur le testeur. Un testeur peut se concentrer sur la compréhension réelle 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 de test et de qualité.

Les inconvénients du test ad hoc

Le test ad hoc a également quelques inconvénients. Jetons un coup d’œil à certains des inconvénients qui sont prononcés :

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

• Suivant le premier point, cela aurait également pour conséquence de ne pas pouvoir recréer les défauts dans les tentatives suivantes si l’on demande des informations.
• Une autre question très importante que cela met en lumière est la responsabilité de l’effort. Puisque ce n’est pas planifié / structuré, il n’y a aucun moyen de comptabiliser le temps et l’effort investis dans ce type de test.
• Les tests ad hoc ne doivent être effectués que par un testeur très compétent et qualifié dans l’équipe car ils exigent d’être proactif et d’avoir de l’intuition en termes de prévision des zones potentielles de défauts.

Bonnes pratiques pour rendre ce test plus efficace

Nous avons longuement discuté des forces et des faiblesses associées à ce test.

Enfin, le test ad-hoc doit trouver sa place dans le SDLC, cependant, s’il n’est pas abordé de la manière appropriée, il peut 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) Identifier les zones sujettes aux défauts :

Lorsque vous avez une bonne emprise sur le test d’un logiciel particulier, vous conviendrez qu’il y aura certaines fonctionnalités qui sont plus sujettes aux erreurs que les autres. Si vous êtes nouveau dans le système, alors allez-y et vérifiez les fonctionnalités v/s défauts ouverts contre eux.

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

#2) Construire l’expertise:

Indubitablement, un testeur qui a plus d’expérience est plus intuitif et peut deviner où les erreurs pourraient être, par rapport à quelqu’un qui n’a pas beaucoup d’expérience. Je dirais que, expérimenté ou non, c’est à l’individu de faire le grand saut et de construire une expertise sur le système qui est testé.

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

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

Une fois que vous connaissez la liste des fonctionnalités à tester, mettez de côté quelques minutes pour décider comment vous allez catégoriser ces fonctionnalités et les tester. Par exemple, vous devriez 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 sembleraient critiques pour le succès du logiciel.

Puis vous pourriez les catégoriser par fonctionnalité/priorité et les tester segment par segment.

Un autre exemple où cela est particulièrement très important est s’il y a une intégration entre les composants ou les modules. Dans ces cas, il peut y avoir beaucoup d’anomalies qui peuvent se produire. L’utilisation de la catégorisation aiderait à toucher à ce type de test au moins une ou deux fois.

#4) Avoir un plan approximatif :

Oui, oui ce point peut vous dérouter un peu car nous avons décrit les tests ad-hoc comme des tests qui ne doivent avoir aucune planification ou documentation. L’idée ici est de s’en tenir à l’essence du test ad-hoc, mais tout de même, d’avoir quelques pointeurs grossiers notés sur la façon dont vous prévoyez de tester.

Un exemple très basique est que parfois vous pouvez tout simplement ne pas être en mesure de vous souvenir de tous les tests que vous avez l’intention d’effectuer. Alors les noter vous permettrait de ne rien manquer.

#5) Outils :

Prenons un exemple auquel nous sommes tous confrontés très couramment. Très souvent, si vous observez, le test de la fonctionnalité en elle-même est réussi sans qu’aucune anomalie ne soit signalée dans son comportement. Cependant, les journaux derrière les scènes pourraient rapporter quelques exceptions vues qui pourraient être manquées par les testeurs car elles n’entravent en rien l’objectif du test.

Ces dernières pourraient même être d’une grande sévérité. Par conséquent, il est très important pour nous d’apprendre et des outils qui aideront à épingler cela immédiatement.

#6) Documenter pour plus de défauts:

De nouveau, je comprends que cela peut soulever quelques sourcils à nouveau. La documentation ne doit pas être détaillée, mais juste une petite note pour votre propre référence de tous les différents scénarios couverts, la déviation dans les étapes impliquées et enregistrer ces défauts pour la catégorie de fonctionnalité de test particulière.

Cela vous aidera à améliorer le seau de test global ainsi par lequel vous pourriez décider comment improviser les cas de test existants ou en ajouter plus si nécessaire.

Conclusion

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

C’est une technique de test qui garantit de répondre et de satisfaire la créativité d’un testeur au maximum. Dans toute ma carrière de testeur, j’obtiens la plus grande satisfaction des tests ad hoc car il n’y a pas de limite pour être innovant et vous ne faites que finir par être plus compétent.

Ayant dit cela, la principale chose à retenir de toutes les informations ci-dessus serait de déterminer comment exploiter les forces des tests ad hoc et faire en sorte qu’ils ajoutent de la valeur au processus de test global et à la qualité du produit.

A propos de l’auteur : Ceci est un article invité par 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.

Faites-vous des tests ad-hoc sur votre projet ? Quelles sont vos suggestions pour que les tests ad-hoc soient réussis ?