Le test Adhoc est généralement effectué pour casser le système et en utilisant des moyens non conventionnels. La caractéristique la plus étonnante du test Adhoc est qu’il n’a pas de technique de conception de test pour créer des cas de test.

Le processus est généralement effectué pour trouver les failles d’un logiciel. Puisque le test Adhoc n’a pas de cas de test, il est souvent effectué sans aucune documentation.

Voyez le processus en détail

Le test Adhoc est une technique qui fait partie de la catégorie ‘Test non structuré’.

Qu’est-ce que le test structuré et le test non structuré ?

Test structuré

Dans cette approche, chaque activité qui se produit au cours de la procédure de test, de la création des cas de test à leur exécution séquentielle, tout est scripté. Les testeurs suivent ce script pour effectuer les tests en fonction de celui-ci.

Testing non structuré

Dans cette approche, les tests sont couramment effectués en devinant les erreurs, où les testeurs créent les cas de test, pendant le processus de test lui-même.

Qu’est-ce que le test adhoc ?

Comme discuté ci-dessus, c’est un type d’approche de test non structuré, où aucun plan organisé n’est créé avant de commencer le processus de test.

Par conséquent, avant le test, aucune documentation des exigences ou planification et conception des cas de test ne sont faites.

Les tests ad hoc sont généralement effectués par un testeur qui a une forte connaissance du logiciel testé, concernant ce qu’il fait et comment il fonctionne.

Ces tests sont effectués en créant au hasard des cas de test en devinant les erreurs et en les exécutant, sans suivre aucune exigence pour le test.

Une partie importante de ce test est de trouver les zones potentielles du logiciel, où des erreurs pourraient être présentes.

C’est pourquoi il est aussi parfois connu sous le nom de Monkey Testing ou Random Testing. C’est pourquoi il est important que seuls les testeurs qui ont une bonne connaissance du logiciel effectuent ce test.

Un avantage du test Ad-Hoc est qu’il permet d’économiser pas mal de temps, qui autrement va dans la création de documents comme les exigences de test, la planification des cas de test, la conception, etc.

Il est aussi généralement effectué après que le test structuré a déjà été effectué. Ceci est fait, afin de trouver des failles peu communes dans le logiciel qui ne pourraient pas être détectées en suivant les cas de test écrits au préalable.

Types de tests ad hoc

1) Buddy Testing

Dans ce type de tests ad hoc, les tests sont effectués avec l’effort d’équipe d’au moins deux personnes. Cette équipe est généralement composée d’au moins un testeur de logiciels et d’un développeur de logiciels.

Ce type de test a lieu après la conduction des tests unitaires d’un module.

L’équipe des deux « copains » travaille ensemble sur ce module pour créer des cas de test valides.

Ceci est fait pour que le testeur ne finisse pas par rapporter des erreurs générées par des cas de test invalides. Ce type de test peut également être considéré comme la combinaison des tests unitaires et des tests système.

2) Test de singe

Le caractère aléatoire de l’approche utilisée dans ce test est la raison pour laquelle il est qualifié de « test de singe ».

Ici, le logiciel testé est fourni par des entrées aléatoires, pour lesquelles leurs sorties correspondantes sont observées.

Sur la base des sorties obtenues, toute occurrence d’erreurs, d’incohérences ou de plantages du système est déterminée.

3) Test en binôme

Ce test ressemble beaucoup au test en binôme. Cependant, ici, une paire de seulement les testeurs travaillent ensemble sur les modules à tester.

Ils travaillent ensemble pour partager des idées, des opinions et des connaissances sur la même machine pour identifier les erreurs et les défauts.

Les testeurs sont jumelés en fonction de leurs niveaux de connaissances et de leur expertise, afin d’obtenir un aperçu différent de tout problème.

Caractéristiques des tests ad hoc

• Ces tests sont effectués après que des techniques de tests formels ont déjà été menées sur le logiciel. La raison en est que les tests ad-hoc sont effectués pour découvrir les anomalies de l’application, qui ne peuvent pas être prédites avant le test.
• Ces tests ne peuvent être effectués que par les testeurs qui ont une bonne connaissance approfondie du fonctionnement de l’application. En effet, une « estimation des erreurs » efficace ne peut être effectuée que lorsque le testeur sait ce que fait l’application et comment elle fonctionne.
• La technique de test ad hoc est la plus adaptée pour trouver les bogues et les incohérences qui donnent lieu à des failles critiques dans une application. De telles erreurs sont généralement très difficiles à découvrir.
• Ce test prend comparativement moins de temps que les autres techniques de test. C’est parce qu’il est effectué sans planification, conception et structuration préalables.
• Les tests ad hoc ne sont effectués qu’une seule fois, car toute erreur trouvée doit être testée à nouveau.

Exemples de tests ad hoc

• Tester le bon fonctionnement d’une application lorsque les paramètres du navigateur sont différents. Par exemple, identifier les erreurs qui se produisent lorsque l’option pour JavaScript est désactivée dans différents navigateurs, etc.
• Tester l’application sur plusieurs plateformes. Il est essentiel de vérifier si l’application développée peut fonctionner de manière fluide dans différents systèmes d’exploitation ou navigateurs.
• Fournir des entrées au système qui sont en dehors de la plage des entrées valides, pour vérifier si l’action résultante prise par l’application est appropriée ou non.
• Copier l’URL de l’application et la manipuler pour qu’elle fonctionne sur un navigateur différent. Ceci est fait pour s’assurer qu’aucun utilisateur non autorisé n’est en mesure d’obtenir un accès non authentifié au système.
• Passer par une série d’étapes aléatoires ou naviguer de manière aléatoire dans l’application de manière à vérifier les résultats obtenus en passant par une certaine combinaison d’entrées inhabituelles.

Quand effectuer des tests ad hoc

En général, les tests ad hoc sont effectués lorsqu’il n’y a pas assez de temps pour effectuer des tests exhaustifs et complets, ce qui inclut la préparation du document des exigences de test, des cas de test et des conceptions de cas de test.

Le moment idéal pour effectuer ce type de test est après l’achèvement des techniques de test formelles.

Cependant, les tests ad-hoc peuvent également être effectués au milieu du développement du logiciel.

Ils peuvent être effectués après le développement complet du logiciel, ou même après le développement de quelques modules.

Ils peuvent également être effectués pendant le processus des méthodes de test formelles également.

Il y a quelques situations où ces tests, cependant, ne doivent pas être effectués. Par conséquent, chaque testeur doit savoir quand éviter ce test.

Données ci-dessous sont quelques conditions où le test ad-hoc ne doit pas être effectué :

• Le test ad-hoc ne doit pas être effectué lorsque le test Bêta est effectué. En effet, le test Bêta implique les clients, qui testent le logiciel développé pour fournir des suggestions sur les nouvelles fonctionnalités qui doivent être ajoutées ou pour modifier les exigences de celui-ci.
• Il est également conseillé de ne pas effectuer ce test dans les cas de test qui ont déjà des erreurs existantes. Les erreurs doivent d’abord être correctement documentées avant d’être retirées du système. Après qu’elles aient été corrigées, les cas de test doivent être retestés, pour assurer leur bon fonctionnement.

Quels sont les avantages du test ad hoc ?

• Un avantage du test ad hoc est que de nombreuses erreurs, qui passent généralement inaperçues lorsque seules les méthodes de test formelles sont utilisées, peuvent être trouvées en testant l’application de manière aléatoire.

Les testeurs ont la possibilité d’explorer l’application librement, selon leur intuition et leur compréhension de l’application. Ils peuvent ensuite exécuter les tests au fur et à mesure, ce qui les aide à trouver les erreurs au cours de ce processus.

• Les testeurs ainsi que les développeurs de l’application peuvent facilement tester l’application, car il n’est pas nécessaire de planifier et de concevoir des cas de test. Cela aide les développeurs à générer facilement des codes plus efficaces et sans erreur.
• Ce test peut également aider à la création de cas de test uniques qui peuvent détecter inefficacement les erreurs. Par conséquent, de tels cas de test peuvent être ajoutés aux tests formels avec d’autres cas de test planifiés.
• Les tests ad hoc peuvent être effectués à n’importe quel moment du cycle de vie du développement logiciel car ils ne suivent aucun processus formel.
• Il peut être combiné avec d’autres techniques de test et exécuté pour produire des résultats plus informatifs et efficaces.

Quels sont les inconvénients des tests ad hoc ?

• Puisque le processus de test n’est pas documenté et qu’aucun cas de test particulier n’est suivi, il devient très difficile pour le testeur de régénérer une erreur. C’est parce que le testeur doit se souvenir des étapes exactes qu’il a suivies pour obtenir cette erreur, ce qui n’est pas possible à chaque fois.
• Parfois, en raison de l’exécution de cas de test invalides développés au hasard par le testeur, des erreurs invalides sont rapportées, ce qui devient un problème dans les processus ultérieurs de correction des erreurs.
• Si les testeurs n’ont pas de connaissances préalables sur le fonctionnement de l’application testée, alors l’exécution de tests ad-hoc ne pourra pas découvrir beaucoup d’erreurs. Cela est dû au fait que les testeurs doivent travailler à travers la devinette des erreurs et créer intuitivement et exécuter des cas de test sur place.
• Les tests ad-hoc ne fournissent pas l’assurance que les erreurs seront trouvées. La devinette proactive des erreurs pour les tests dépend totalement des compétences et des connaissances du testeur.
• Puisqu’il n’y a pas de cas de test créés et documentés au préalable, la quantité de temps et d’efforts qui sont consacrés à ces tests reste incertaine. Parfois, trouver ne serait-ce qu’une seule erreur pourrait prendre énormément de temps.

Bonnes pratiques pour mener des tests ad hoc

Pour mener efficacement la technique de test ad hoc, il est important de connaître les moyens les plus efficaces et efficients de le faire.

Car si les tests ne sont pas menés de manière appropriée, alors les efforts et le temps mis dans les tests seront gaspillés.

Par conséquent, pour mener ce type de tests, il faut connaître les meilleures pratiques qui peuvent aider à une approche plus complète des tests :

1) Bonne connaissance du logiciel

S’assurer que le testeur assigné pour le test de l’application par l’approche ad-hoc a une bonne prise sur l’application.

Le testeur doit être familier avec toutes les fonctionnalités de l’application afin de faciliter une meilleure  » devinette des erreurs  » sur l’application.

Avec une connaissance suffisante pour soutenir le processus de test du testeur, trouver plus d’erreurs, de bogues et d’incohérences devient plus facile.

2) Trouver les zones sujettes aux erreurs

Si les testeurs, comment ne sont pas familiers avec l’application, alors la meilleure pratique pour eux de commencer leur processus de test est de vérifier la partie de l’application où se trouve la majorité des erreurs.

Prélever ces zones sensibles pour effectuer des tests ad hoc peut les aider à trouver des erreurs plus facilement.

3) Prioriser les zones de test

Il est toujours préférable de commencer les tests à partir des zones de l’application qui est la plus utilisée par les utilisateurs finaux ou les clients. Cela aide à sécuriser les fonctionnalités importantes et à signaler tout bug à l’avance.

4) Planifier grossièrement le plan de test

Bien que les tests adhoc ne nécessitent aucune planification ou documentation préalable, ils s’avèrent très utiles et efficaces si un plan grossier est créé au préalable.

Le simple fait de noter les principaux pointeurs et les zones qui nécessitent des tests peut aider les testeurs à couvrir la partie maximale de l’application en peu de temps.

5) Outils

Il est essentiel d’utiliser le bon type d’outils comme les débogueurs, les moniteurs de tâches et les profileurs pour faciliter le processus de test.

C’est parce qu’il y a des moments où des bogues et des exceptions spécifiques ne peuvent pas être vus et ne sont pas attrapés pendant le test.

Cependant, l’utilisation des bons outils peut aider à isoler l’erreur en peu de temps.

Testing ad hoc vs test exploratoire

.

Testing ad hoc	Testing exploratoire
Les testeurs doivent avoir une idée claire du flux de travail de l’application	Les testeurs apprennent à connaître l’application sur le tas	. l’application en cours
Plus sur le perfectionnement du processus de test	C’est une méthode d’apprentissage pour connaître l’application
Une forme de test positif	Une forme de système négatif
Il n’y a pas de plan	Un plan basé sur une charte sera mis en œuvre
Il n’y a pas de délai proposé	Temps encadré/vecteur de caractères
Peut être exécuté par l’ingénieur de test logiciel	Doit être fait par l’expert
L’accent est mis sur le processus d’application	Les zones de saisie de données seront le principal centre d’intérêt
La complexité des tests ne gênera pas beaucoup ce processus	Défis impliqués

.