Le test ad hoc est un type de test de logiciel que les développeurs et les sociétés de logiciels mettent en œuvre lorsqu’ils vérifient l’itération actuelle du logiciel. Cette forme de test permet de mieux comprendre le programme et de localiser des problèmes que les tests conventionnels ne peuvent pas mettre en évidence.
Il est primordial que les équipes de test comprennent parfaitement le processus de test ad hoc afin de savoir comment contourner ses difficultés et de s’assurer que l’équipe peut mettre en œuvre cette technique avec succès.
Savoir exactement comment fonctionnent les tests ad hoc et quels outils peuvent faciliter leur mise en œuvre permet à une entreprise d’améliorer en permanence ses propres procédures d’assurance qualité. Le processus de test formel suit des règles très précises, ce qui peut amener l’équipe à manquer certains bogues. Les vérifications ad hoc permettent de contourner ces angles morts et de tester rapidement toutes les fonctionnalités du logiciel.
Dans cet article, nous examinons de près les tests ad hoc et la manière dont vous pouvez les utiliser à votre avantage lors du développement d’un produit logiciel.
Signification des tests ad hoc : Qu’est-ce qu’un test ad hoc ?
Les tests ad hoc sont un processus d’assurance qualité qui évite les règles formelles et la documentation. Ils aident les testeurs à trouver des erreurs dans leur application que les approches conventionnelles ne peuvent pas identifier. Cela nécessite généralement une connaissance approfondie du logiciel avant le début des tests, y compris une compréhension du fonctionnement interne du programme. Ces contrôles ad hoc visent à casser l’application de manière à refléter les données de l’utilisateur, en tenant compte de diverses situations potentielles afin que les développeurs puissent corriger les problèmes existants.
L’absence de documentation est au cœur de cette technique, qui ne comprend ni liste de contrôle ni cas de test pour guider les testeurs à travers les fonctionnalités d’une application. Les tests ad hoc consistent à tester le logiciel de la manière que l’équipe juge la plus efficace à ce moment précis. Cela peut prendre en compte des tests formels préexistants, mais peut aussi simplement consister à effectuer autant de tests que possible dans le temps (probablement limité) qui est alloué à cette technique.
1. Quand et pourquoi faut-il faire des tests ad hoc dans les tests de logiciels ?
La principale raison pour laquelle les entreprises effectuent des tests ad hoc est leur capacité à découvrir des erreurs que les approches traditionnelles ne parviennent pas à déceler. Cela peut être dû à un certain nombre de raisons, comme le fait que les cas de test conventionnels suivent un processus particulièrement standardisé qui ne peut pas prendre en compte les particularités d’une application.
Chaque type de test peut offrir de nouvelles perspectives et des approches intéressantes en matière d’assurance qualité – ce qui permet également de mettre en évidence les problèmes liés à la stratégie de test habituelle. Par exemple, si les tests ad hoc permettent d’identifier un problème que les cas de test de l’équipe ne traitent pas, cela suggère qu’il serait utile de recalibrer leur méthodologie de test.
Les testeurs peuvent effectuer des contrôles ad hoc à tout moment du processus de test. Il s’agit généralement d’un complément à l’assurance qualité traditionnelle (et plus formelle) et, dans cette optique, les testeurs peuvent effectuer des inspections ad hoc pendant que leurs collègues procèdent à des examens plus formels. Toutefois, ils peuvent préférer conserver les contrôles ad hoc jusqu’à la fin du processus de test formel, en tant que suivi ciblant spécifiquement les points aveugles potentiels.
Les tests ad hoc peuvent également être utiles lorsque le temps est particulièrement limité en raison du manque de documentation – le moment opportun dépend de l’entreprise et de l’approche qu’elle privilégie.
2. Quand il n’est pas nécessaire de faire des tests ad hoc
S’il n’y a pas assez de temps pour effectuer des tests ad hoc et formels, il est important que l’équipe donne la priorité à ces derniers, car ils garantissent une couverture de test substantielle, même si des lacunes subsistent.
Si les tests formels de l’équipe révèlent des bogues à corriger, il est généralement préférable d’attendre que les développeurs aient apporté les modifications nécessaires pour procéder à des vérifications ad hoc. Dans le cas contraire, les résultats qu’ils fournissent pourraient rapidement devenir obsolètes, en particulier si les tests portent sur le composant qui connaît déjà des bogues.
En outre, des tests ad hoc doivent être effectués avant la phase de test bêta.
3. Qui est impliqué dans les tests ad hoc ?
Plusieurs rôles clés sont impliqués dans le processus de test ad hoc, notamment
– Les testeurs de logiciels sont les principaux membres de l’équipe qui effectuent des contrôles ad hoc. Si vous effectuez des tests en binôme, plusieurs de ces testeurs travailleront ensemble sur les mêmes composants.
– Les développeurs peuvent utiliser ces contrôles de manière indépendante avant l’étape formelle d’assurance de la qualité pour inspecter rapidement leur propre logiciel, bien que cela soit moins approfondi que les tests ad hoc dédiés.
– Les chefs d’équipe ou de service autorisent la stratégie globale de test – en aidant les testeurs à déterminer quand commencer les tests ad hoc et comment les effectuer sans perturber les autres contrôles.
Avantages des tests ad hoc
Les avantages des tests ad hoc dans les tests de logiciels sont les suivants :
1. Résolutions rapides
Comme ces tests n’impliquent pas de documentation fréquente avant, pendant ou après les vérifications, les équipes peuvent identifier les problèmes beaucoup plus rapidement. Cette simplicité offre une grande liberté aux testeurs.
Par exemple, si l’équipe teste un composant et n’identifie aucune erreur, elle peut simplement passer au test suivant sans le noter dans un document.
2. Complète d’autres types de tests
Aucune stratégie de test n’est parfaite, et une couverture à 100 % est généralement impossible à atteindre, même avec un programme complet. Il y aura toujours des lacunes dans les tests conventionnels et il est donc important que les entreprises intègrent des approches multiples.
Les tests ad hoc visent spécifiquement à détecter les problèmes que les tests formels ne peuvent pas couvrir, ce qui garantit une couverture globale plus large des tests.
3. Exécution souple
Les tests ad hoc peuvent avoir lieu à n’importe quel moment du processus d’assurance qualité avant les tests bêta, ce qui permet aux entreprises et aux équipes de décider du meilleur moment pour effectuer ces vérifications. Ils peuvent choisir d’effectuer des tests ad hoc en même temps que les tests conventionnels ou attendre jusqu’à ce qu’ils soient terminés – quoi qu’il en soit, l’équipe bénéficie des choix qui sont à sa disposition.
4. Une plus grande collaboration
Les développeurs sont plus impliqués dans ce processus que dans de nombreuses autres formes de test – en particulier si l’entreprise utilise des tests de jumelage.
En conséquence, les développeurs ont une meilleure vision de leurs propres applications et peuvent être en mesure de corriger les bogues de manière plus efficace. Cela permet d’améliorer encore la qualité générale du logiciel.
5. Diversité des points de vue
Les tests ad hoc permettent de présenter l’application sous de nouveaux angles, ce qui aide les testeurs à s’intéresser à ces fonctionnalités d’une nouvelle manière. Des perspectives supplémentaires sont essentielles tout au long des essais, car les contrôles formels présentent souvent des lacunes au moins mineures.
Si les testeurs ad hoc utilisent le logiciel avec l’intention spécifique de le casser, ils seront en mesure de repérer plus facilement les limites du programme.
Les défis des tests ad hoc
Le processus d’essai ad hoc présente également plusieurs difficultés, notamment :
1. Difficultés liées à l’établissement de rapports
Le manque de documentation rend les tests ad hoc beaucoup plus rapides, mais peut aussi rendre difficile l’établissement de rapports pour tout ce qui n’est pas un problème majeur.
Par exemple, un contrôle effectué précédemment peut devenir plus pertinent à une date ultérieure bien qu’il n’ait pas donné de résultats significatifs au départ. En l’absence d’une documentation complète, l’équipe pourrait ne pas être en mesure d’expliquer ces tests.
2. Moins reproductible
Dans le même ordre d’idées, les testeurs peuvent ne pas être pleinement conscients des conditions exactes nécessaires pour provoquer les réactions qu’ils observent. Par exemple, un contrôle ad hoc qui renvoie une erreur peut ne pas contenir suffisamment d’informations pour permettre à l’équipe de prendre des mesures. Il se peut qu’ils ne sachent pas comment répéter ce test et obtenir le même résultat.
3. Nécessite une expérience en matière de logiciels
Comme la rapidité est essentielle dans les tests ad hoc et qu’il s’agit généralement d’essayer de casser l’application, il est important que ces testeurs aient une connaissance approfondie de ce programme.
Le fait de savoir comment il fonctionne permet aux testeurs de casser et de manipuler le logiciel de plus de manières, mais cela pourrait augmenter de manière significative les exigences en matière de compétences pour les tests ad hoc.
4. Responsabilité limitée
Un manque de documentation peut causer plus de problèmes qu’un simple rapport médiocre ; il peut également allonger par inadvertance le processus de test, ce qui a un impact sur l’utilité des tests individuels rapides et ad hoc.
Les testeurs peuvent avoir du mal à suivre leurs progrès s’ils ne disposent pas d’une documentation suffisante à chaque étape. Cela peut même les amener à répéter un contrôle que d’autres testeurs ont déjà effectué.
5. Peut ne pas refléter l’expérience de l’utilisateur
L’objectif de pratiquement tous les types de tests est de tenir compte des erreurs qui affectent les utilisateurs finaux d’une manière ou d’une autre. Les tests ad hoc reposent principalement sur le fait qu’un testeur expérimenté essaie d’imiter un utilisateur inexpérimenté, ce qui doit être cohérent à chaque vérification, y compris lorsqu’il tente de casser l’application.
Caractéristiques des tests ad hoc
Les principales caractéristiques des tests ad hoc réussis sont les suivantes :
1. L’enquête
La principale priorité des tests ad hoc est d’identifier les erreurs dans l’application en utilisant des techniques que les contrôles conventionnels ne prennent pas en compte. Des examens ad hoc parcourent ce logiciel dans le but exprès de trouver des failles dans la procédure de test de l’équipe, y compris dans la couverture de ses cas de test.
2. Non structuré
Les contrôles ad hoc n’ont généralement pas de plan défini, si ce n’est la réalisation d’autant de tests que possible en dehors des limites habituelles de l’assurance qualité formelle. Les testeurs regroupent généralement les contrôles par composant pour des raisons de commodité, mais cela n’est pas nécessaire – ils peuvent même concevoir les contrôles pendant qu’ils les effectuent.
3. L’expérience
Les testeurs ad hoc utilisent leur expérience logicielle préexistante pour évaluer les tests qui apporteraient le plus d’avantages et qui permettraient de combler les lacunes des tests formels.
Bien que le processus de test soit encore totalement non structuré, les testeurs appliquent leurs connaissances des contrôles ad hoc précédents, entre autres, lorsqu’ils décident de leur stratégie.
4. Large éventail
Il n’existe pas de guide précis sur les contrôles que l’équipe doit effectuer lors des tests ad hoc, mais ils couvrent généralement une série de composants, en se concentrant éventuellement sur les aspects les plus sensibles de l’application. Cela permet aux testeurs de s’assurer que leurs examens sont en mesure de compléter pleinement les tests formels.
Que testons-nous dans les tests ad hoc ?
Les équipes d’assurance qualité testent généralement les éléments suivants lors de tests ad hoc :
1. Qualité des logiciels
Ces contrôles visent à identifier les erreurs dans l’application que les tests conventionnels ne peuvent pas déceler ; cela signifie que le processus teste principalement la santé générale de l’application.
Plus les tests ad hoc permettent de détecter de bogues, plus les développeurs peuvent apporter d’améliorations avant la date limite.
2. Cas de test
Les tests ad hoc n’implémentent généralement pas de cas de test – et ce, précisément pour que l’équipe puisse examiner dans quelle mesure ils sont efficaces pour fournir une couverture étendue. Les cas de test sont probablement inadéquats si des vérifications ad hoc peuvent trouver des erreurs que les processus de test conventionnels ne peuvent pas détecter.
3. Personnel chargé des tests
L’objectif peut également être de vérifier les compétences et les connaissances de l’équipe de test, même si les cas de test sont adéquats. Par exemple, leur méthodologie de mise en œuvre des cas peut être insuffisante et des tests ad hoc peuvent être essentiels pour combler les lacunes qui en résultent dans la couverture des tests.
4. Limites du logiciel
Les tests ad hoc visent également à comprendre les limites de l’application, par exemple la façon dont elle réagit à des entrées inattendues ou à des charges de système élevées. Les testeurs pourraient étudier spécifiquement les messages d’erreur du programme et la manière dont l’application fonctionne lorsqu’elle est soumise à une pression importante.
Pour dissiper une certaine confusion :
Tests ad hoc et tests exploratoires
Certains considèrent que les tests ad hoc et les tests exploratoires sont synonymes, mais la vérité est plus compliquée que cela.
1. Qu’est-ce qu’un test exploratoire ?
Les tests exploratoires font référence aux procédures d’assurance qualité qui étudient le logiciel d’un point de vue holistique et combinent spécifiquement les processus de découverte et de test en une seule méthode. Il s’agit généralement d’un moyen terme entre les tests entièrement structurés et les contrôles ad hoc entièrement libres.
Les tests exploratoires donnent de meilleurs résultats dans des scénarios spécifiques, par exemple lorsqu’un retour d’information rapide est nécessaire ou si l’équipe doit traiter des cas limites. Ce type de test atteint généralement son plein potentiel lorsque l’équipe utilise en parallèle des tests scénarisés.
2. Différences entre les tests exploratoires
et tests ad hoc
La plus grande différence entre les tests ad hoc et les tests exploratoires est que les premiers utilisent la documentation pour enregistrer et faciliter leurs vérifications, alors que les tests ad hoc l’évitent complètement. Les tests exploratoires mettent davantage l’accent sur la liberté des tests, mais jamais au même niveau qu’une approche ad hoc qui n’est pas du tout structurée.
Les tests exploratoires impliquent également l’apprentissage de l’application et de son fonctionnement interne au cours de ces vérifications – les testeurs ad hoc ont souvent une connaissance approfondie de la fonctionnalité du logiciel avant de commencer.
Types de tests ad hoc
Il existe trois formes principales de tests ad hoc dans les tests de logiciels :
1. Tests sur les singes
Peut-être le type de test ad hoc le plus populaire, les tests de singe sont ceux qui impliquent qu’une équipe examine au hasard différents composants.
Cela se produit généralement au cours du processus de test unitaire et met en œuvre une série de vérifications sans aucun cas de test. Les testeurs étudient les données de manière indépendante et non structurée, ce qui leur permet d’examiner le système dans son ensemble et sa capacité à résister à la pression intense exercée par les entrées de l’utilisateur.
L’observation des résultats de ces techniques non scénarisées aide l’équipe de test à identifier les erreurs que les autres tests unitaires n’ont pas détectées en raison des lacunes des méthodes de test conventionnelles.
2. Test du copain
Dans un contexte ad hoc, les tests de jumelage font appel à un minimum de deux membres du personnel – généralement un testeur et un développeur – et se déroulent principalement après l’étape des tests unitaires. Les « copains » travaillent ensemble sur le même module pour repérer les erreurs. La diversité de leurs compétences et leur vaste expérience en font une équipe plus efficace, ce qui permet d’atténuer les nombreux problèmes liés à un manque de documentation.
Le développeur peut même suggérer lui-même un certain nombre de tests, ce qui lui permet d’identifier les éléments qui pourraient nécessiter plus d’attention.
3. Tests par paires
Le test en binôme est similaire en ce sens qu’il implique deux membres du personnel, mais il s’agit généralement de deux testeurs distincts, dont l’un exécute les tests proprement dits tandis que l’autre prend des notes.
Même sans documentation formelle, la prise de notes peut permettre à l’équipe de suivre de manière informelle les vérifications individuelles ad hoc. Les rôles de testeur et de scribe peuvent s’inverser en fonction du test ou le binôme peut conserver les rôles qui lui ont été attribués tout au long du processus.
Le testeur le plus expérimenté est généralement celui qui effectue les contrôles proprement dits – bien qu’ils se partagent toujours le travail.
Tests ad hoc manuels ou automatisés ?
Les tests automatisés peuvent aider les équipes à gagner encore plus de temps tout au long de la phase d’assurance qualité, ce qui permet aux testeurs d’intégrer davantage de contrôles dans leur emploi du temps. Même sans structure définie, il est essentiel que les testeurs s’efforcent de maximiser la couverture et que l’automatisation encourage des inspections plus approfondies de ce logiciel.
Les contrôles ad hoc automatisés sont généralement plus précis que les tests manuels, car ils permettent d’éviter les erreurs humaines lors des tâches routinières – ce qui est particulièrement utile lorsqu’il s’agit d’effectuer les mêmes tests sur différentes itérations. Le succès de cette procédure dépend généralement de l’outil de test automatisé choisi par l’équipe et de ses fonctionnalités.
Cependant, les tests automatisés ont certaines limites. Par exemple, la principale force des tests ad hoc est leur capacité à émuler les entrées de l’utilisateur et à effectuer des vérifications aléatoires au fur et à mesure que le testeur en a l’idée. Ces tests peuvent perdre leur caractère aléatoire si le programme de test de l’organisation a du mal à effectuer des contrôles complexes.
Le temps nécessaire à l’automatisation de ces tâches très spécifiques peut également limiter les gains de temps typiques de ce processus. Il est important que les équipes étudient minutieusement les outils d’automatisation disponibles afin de trouver celui qui correspond au projet de leur entreprise.
De quoi avez-vous besoin pour commencer les tests ad hoc ?
Voici les principales conditions préalables aux tests ad hoc :
1. Personnel qualifié
Les tests ad hoc étant des inspections rapides et aléatoires du fonctionnement interne du logiciel, il est généralement utile d’avoir des testeurs qui ont l’expérience du logiciel. Ils doivent également avoir une connaissance pratique des principes clés des tests, ce qui leur permet d’identifier facilement les contrôles les plus efficaces.
2. Une approche non structurée
Les testeurs doivent être prêts à abandonner leurs stratégies habituelles pour les tests ad hoc ; cet état d’esprit est tout aussi essentiel que les contrôles de qualité eux-mêmes. Cette méthode ne peut réussir qu’en l’absence de structure ou de documentation et il est essentiel que les testeurs s’en souviennent à chaque étape.
3. Logiciel d’automatisation
Bien que les tests ad hoc s’appuient davantage sur des entrées et des conditions aléatoires, l’automatisation reste une technique très efficace dans tous les contextes.
C’est pourquoi les contrôles ad hoc devraient toujours mettre en œuvre des outils de test automatisés lorsque c’est possible, car l’application adéquate peut considérablement rationaliser le processus.
4. Autres formes de tests
Les tests ad hoc fonctionnent mieux avec d’autres vérifications qui adoptent une approche plus formelle – aidant l’équipe à garantir une couverture substantielle à travers le logiciel. Il est essentiel que les testeurs mélangent différentes techniques, que ce soit avant, pendant ou après la réalisation des tests ad hoc.
Processus de test ad hoc
Les étapes habituelles que les testeurs doivent suivre lorsqu’ils effectuent des tests ad hoc dans le cadre de tests de logiciels sont les suivantes :
1. Définir les objectifs des tests ad hoc
Cette étape est limitée en raison du manque de documentation et de structure, mais il est toujours primordial que l’équipe ait un objectif clair. Les testeurs peuvent commencer à partager de vagues idées sur les prochains tests à effectuer et les composants à prioriser.
2. Sélection de l’équipe de test ad hoc
Lorsque l’équipe réfléchit à un certain nombre de vérifications ad hoc potentielles, elle détermine également quels sont les testeurs les plus aptes à effectuer ce type de tests. Ils sélectionnent généralement des testeurs qui comprennent parfaitement l’application et peuvent également les associer à un développeur.
3. Exécution de tests ad hoc
Après avoir décidé quels sont les testeurs appropriés pour cette étape, ces membres de l’équipe commencent leurs vérifications à un moment convenu du test. Leur objectif est d’effectuer le plus grand nombre possible de vérifications ad hoc, que les testeurs n’ont peut-être pas conçues avant cette étape.
4. Évaluer les résultats des tests
Une fois les tests terminés (ou même entre les différents contrôles), les testeurs évalueront les résultats, mais sans les documenter formellement dans un cas de test. S’ils découvrent des problèmes avec la demande, ils les enregistrent de manière informelle et discutent des prochaines étapes de l’équipe.
5. Signaler les bogues découverts
Une fois les résultats évalués, les testeurs doivent informer les développeurs des erreurs présentes dans le logiciel afin qu’ils aient suffisamment de temps pour les corriger avant la publication.
L’équipe de test utilise également les informations pour déterminer comment améliorer ses processus de test formels.
6. Répétition des tests si nécessaire
L’équipe chargée des tests répétera probablement le processus ad hoc pour les nouvelles itérations de l’application afin de vérifier si elle gère bien les mises à jour. Étant donné que les testeurs auront comblé un grand nombre des lacunes précédemment identifiées dans leurs cas de test, les futurs contrôles ad hoc pourraient nécessiter une approche différente.
Meilleures pratiques pour les tests ad hoc
Il existe certaines pratiques que les équipes de test doivent mettre en œuvre lors des tests ad hoc :
1. Cibler les lacunes potentielles en matière d’essais
Bien que les tests ad hoc impliquent beaucoup moins de planification que les autres types de tests, l’équipe vise toujours à combler les lacunes en matière d’assurance de la qualité. Si les testeurs ad hoc soupçonnent des problèmes spécifiques avec les cas de test de l’équipe, ils doivent en faire une priorité lors de leurs vérifications.
2. Envisager un logiciel d’automatisation
Les stratégies d’automatisation telles que l’hyperautomatisation peuvent offrir de nombreux avantages aux entreprises qui souhaitent réaliser des tests ad hoc.
Le succès de cette démarche dépend de plusieurs facteurs clés, notamment l’outil choisi par l’entreprise, ainsi que la complexité générale de ses tests ad hoc.
3. Prendre des notes détaillées
L’absence de documentation dans les tests ad hoc permet principalement de rationaliser encore davantage ce processus – l’équipe pourrait tirer profit de la prise de notes informelles au fur et à mesure qu’elle progresse. Les testeurs disposent ainsi d’un enregistrement clair de ces vérifications et de leurs résultats, ce qui accroît leur répétabilité globale.
4. Continuer à affiner les tests
Les testeurs ad hoc affinent continuellement leur approche pour tenir compte des changements dans la stratégie de test de l’équipe. Lorsqu’ils examinent les nouvelles versions du logiciel de l’entreprise, par exemple, ils peuvent ajuster ces contrôles en fonction de nouveaux cas de test formels plus complets.
7 erreurs et pièges dans la mise en œuvre
Tests ad hoc
Comme dans tout processus de test, il existe un large éventail d’erreurs potentielles que l’équipe doit s’efforcer d’éviter :
1. Testeurs inexpérimentés
Pour maintenir le rythme prévu des tests ad hoc, le chef d’équipe doit affecter les testeurs en fonction de leurs connaissances et de leurs compétences. Alors que de nombreuses formes de tests peuvent être effectuées par du personnel d’assurance qualité débutant, les contrôles ad hoc nécessitent des membres de l’équipe qui comprennent parfaitement le logiciel, de préférence avec de l’expérience dans l’exécution de ces tests.
2. Contrôles non ciblés
Les tests ad hoc peuvent améliorer de manière significative la couverture des tests en raison de leur rythme plus rapide – l’équipe n’a pas besoin de remplir une documentation exhaustive avant et après chaque vérification.
Cependant, les testeurs ad hoc doivent toujours maintenir une attention particulière ; par exemple, ils peuvent décider de donner la priorité à certains composants présentant un risque de défaillance plus élevé.
3. Pas de planification
Le fait d’éviter tout plan peut limiter l’efficacité des tests ad hoc. Malgré la nature non structurée de cette approche, il est important que l’équipe ait une idée approximative des tests à effectuer avant de commencer.
Le temps est limité au cours de ce processus et savoir comment procéder peut offrir de nombreux avantages.
4. Trop structuré
À l’opposé, cette approche repose généralement sur un manque de planification, car elle aide les testeurs à détourner activement les cas de test et à trouver des erreurs cachées.
Les tests ad hoc sont également connus sous le nom de tests aléatoires et le fait de leur imposer une structure pourrait les empêcher de localiser des bogues.
5. Pas de changement à long terme
L’objectif des tests ad hoc est d’identifier les faiblesses des scénarios de test de l’équipe ; cela permet d’examiner leur stratégie globale tout autant que le logiciel lui-même.
Toutefois, cela signifie que les tests ad hoc ne sont généralement efficaces que si l’équipe utilise ces informations pour affiner ses contrôles formels au fil du temps.
6. Ensembles de données incompatibles
Pratiquement toutes les formes de test nécessitent une forme de données simulées pour évaluer la façon dont l’application réagit ; certains outils permettent aux testeurs de remplir automatiquement un programme avec des données fictives.
Toutefois, cela peut ne pas refléter la manière dont un utilisateur utiliserait le logiciel – les vérifications ad hoc nécessitent des ensembles de données que le logiciel est susceptible de rencontrer.
7. Silos d’information
Il est essentiel que les testeurs et les développeurs soient en communication constante les uns avec les autres, même si ces derniers ne font pas partie du processus de test ad hoc.
Cela permet à chacun de comprendre quels tests ont été effectués – en indiquant les prochaines actions à entreprendre tout en évitant aux testeurs de répéter inutilement certaines vérifications.
Types de résultats des tests ad hoc
Les contrôles ad hoc produisent plusieurs résultats distincts, notamment
1. Résultats des tests
Les différents tests produisent des résultats différents en fonction du composant et de l’approche utilisés, qui peuvent prendre de nombreuses formes.
Il incombe généralement au testeur de déterminer si les résultats constituent une erreur, bien qu’un manque de documentation rende difficile la comparaison avec ses attentes. L’équipe transmet ces résultats aux développeurs s’ils constatent des problèmes.
2. Journaux d’essai
Le logiciel lui-même utilise un système complexe de journaux internes pour surveiller les entrées de l’utilisateur et mettre en évidence un certain nombre de problèmes de fichiers ou de bases de données susceptibles d’apparaître.
Cela pourrait indiquer une erreur interne, y compris la partie spécifique du logiciel à l’origine du problème. Grâce à ces informations, les testeurs et les développeurs ad hoc peuvent résoudre les problèmes qu’ils découvrent beaucoup plus facilement.
3. Messages d’erreur
De nombreux contrôles ad hoc visent spécifiquement à casser le logiciel et à exposer ses limites, ce qui signifie que les messages d’erreur de l’application sont l’un des résultats les plus courants de ces tests.
En provoquant délibérément des messages d’erreur, l’équipe peut montrer ce que l’utilisateur final moyen voit lorsque les actions inattendues qu’il entreprend ont un effet négatif sur le fonctionnement du programme.
Exemples de tests ad hoc
Voici trois scénarios de tests ad hoc qui montrent comment une équipe peut les mettre en œuvre pour différentes applications :
1. Application web de commerce électronique
Si une entreprise souhaite tester une application web basée sur le commerce électronique, elle peut utiliser des tests ad hoc – en particulier des tests de singe – pour voir dans quelle mesure la plateforme gère les interactions inattendues des utilisateurs.
Les testeurs peuvent chercher à repousser les limites de chaque fonctionnalité, par exemple en ajoutant des articles à leur panier en quantités irréalistes ou en essayant d’acheter des produits qui ne sont plus en stock. Ils ne sont pas limités par les cas de test de l’équipe et les contrôles qu’ils peuvent effectuer sont peu nombreux ; les testeurs peuvent même essayer d’effectuer des achats à l’aide d’URL obsolètes.
2. Application de bureau
Les testeurs ad hoc peuvent également mettre en œuvre ces techniques pour les applications de bureau, en se concentrant éventuellement sur différentes machines et sur la manière dont chacune d’entre elles s’adapte au programme.
Les membres de l’équipe peuvent effectuer ces vérifications à plusieurs reprises pour voir comment les changements de paramètres matériels ou logiciels affectent les performances globales d’une application. Par exemple, une carte graphique spécifique peut avoir du mal à restituer l’interface.
Par ailleurs, ces testeurs pourraient simplement donner à leur programme des entrées impossibles et voir comment il réagit, par exemple s’il peut afficher correctement des messages d’erreur qui expliquent le problème de manière adéquate à l’utilisateur final.
3. Application mobile
Les testeurs ad hoc peuvent notamment examiner une application mobile en testant ses protocoles de sécurité – ils peuvent essayer d’accéder directement aux outils de développement de l’application, par exemple.
L’équipe peut essayer de voir si elle est en mesure d’effectuer des actions non autorisées en trouvant des failles et des exploits courants ; elle peut demander spécifiquement à des membres du personnel ayant une expérience en matière de sécurité des applications de faciliter cette tâche.
Cela peut également impliquer des tests en binôme avec les développeurs en raison de leur connaissance de la conception de l’application, ce qui permet à un testeur de casser le logiciel et de montrer exactement les lacunes en matière de sécurité.
Types d’erreurs et de bogues détectés
par des tests ad hoc
Les contrôles ad hoc peuvent mettre en évidence de nombreux problèmes liés à un programme, tels que
1. Erreurs de fonctionnalité
L’utilisation de tests ad hoc pour examiner les fonctionnalités de base d’une application peut révéler des bogues graves qui affectent la façon dont les utilisateurs finaux peuvent s’en servir.
Par exemple, un test de singe sur les options de paiement d’un site de commerce électronique illustrera les conditions qui empêchent la transaction.
2. Questions relatives aux performances
Les testeurs peuvent travailler spécifiquement à créer des problèmes de performance dans le programme, par exemple en remplissant la base de données avec diverses entrées de spam.
Cela peut se manifester par un temps de latence important ou même par une instabilité générale du logiciel, qui conduira probablement à une panne (potentiellement à l’échelle du système).
3. Problèmes d’utilisation
Ces contrôles peuvent également mettre en évidence des défauts au niveau de l’interface et de l’expérience générale de l’utilisateur. L’interface utilisateur d’une application mobile, par exemple, peut se présenter différemment selon le système d’exploitation ou la résolution de l’écran. Une interface médiocre peut conduire les utilisateurs à avoir du mal à utiliser cette application.
4. Les failles de sécurité
La nature aléatoire des tests ad hoc leur permet de couvrir un éventail de problèmes de sécurité courants ou rares ; un testeur peut utiliser ces vérifications pour trouver les portes dérobées administratives d’un programme.
Par ailleurs, leur inspection peut montrer que le logiciel ne comporte pas de cryptage des données.
Mesures communes pour les tests ad hoc
Les tests ad hoc utilisent diverses mesures pour faciliter l’obtention des résultats, notamment
1. Efficacité de la détection des défauts
Cette mesure évalue l’efficacité du processus de test à trouver des défauts pour chaque forme de test, y compris les tests ad hoc. L’efficacité de la détection des défauts est le pourcentage de défauts découverts divisé par le nombre total de problèmes, ce qui montre l’efficacité des tests.
2. Taux de couverture des tests
Une fonction auxiliaire des tests ad hoc consiste à augmenter la couverture en vérifiant les composants d’une manière dont les cas de test ne tiennent pas compte. Cela signifie que les testeurs s’efforceront également d’augmenter radicalement la couverture des tests pour chaque vérification, dans la mesure du possible.
3. Durée totale du test
Les tests ad hoc sont beaucoup plus rapides que les autres processus d’assurance qualité – et il est essentiel que les testeurs s’efforcent de conserver cet avantage. Les mesures de la durée des tests montrent aux membres de l’équipe comment ils peuvent gagner du temps et multiplier les avantages des stratégies ad hoc.
4. Taux d’accidents
Ces tests visent souvent à casser le logiciel et à provoquer un crash ou une erreur grave, ce qui leur permet d’aller au-delà des stratégies de test habituelles et de découvrir des problèmes inattendus. À cette fin, il peut être utile de savoir à quelle fréquence le logiciel se bloque et quelles sont les causes de ces problèmes.
5 meilleurs outils de test ad hoc
Il existe de nombreux outils de test gratuits et payants pour les tests ad hoc dans les tests de logiciels – les cinq meilleurs sont les suivants :
1. ZAPTEST Free & Enterprise Edition
ZAPTEST est un programme complet de test de logiciels qui offre un niveau élevé de fonctionnalités de test + RPA dans ses versions gratuite et entreprise.
Cette suite complète d’automatisation de logiciels et de RPA permet de réaliser des tests complets sur différentes plateformes de bureau et mobiles ; la technologie 1SCRIPT du logiciel permet également aux utilisateurs d’exécuter les mêmes vérifications de manière répétée avec facilité. En outre, l’outil s’appuie sur une vision informatique de pointe, ce qui permet à ZAPTEST d’effectuer des tests ad hoc d’un point de vue humain.
2. BrowserStack
BrowserStack est une plateforme en nuage qui peut faciliter les tests sur plus de 3 000 machines différentes, avec en plus la possibilité d’automatiser les scripts Selenium. Bien qu’il offre une bonne couverture pour les projets logiciels, il fonctionne mieux avec les navigateurs et les applications mobiles.
Les solutions de test BrowserStack comprennent également une version d’essai gratuite avec 100 minutes de tests automatisés – bien que l’utilisation de cette version puisse être limitée.
Bien que l’approche basée sur l’informatique en nuage puisse être utile, elle a également un impact négatif sur le temps de réponse de la plateforme.
3. Test Lambda
LambdaTest utilise également une technologie basée sur le cloud et met l’accent sur les tests de navigateurs, ce qui peut limiter son efficacité pour d’autres applications – bien qu’il s’adapte bien aux programmes iOS et Android. Il s’agit d’une plateforme utile lorsque l’évolutivité est un problème et elle s’intègre à de nombreux autres services d’hébergement de tests.
Toutefois, certains utilisateurs ont des réactions mitigées quant au prix de l’application pour les différentes options non expérimentales disponibles, ce qui pourrait limiter l’accessibilité pour les petites organisations.
4. TestRail
TestRail est généralement assez adaptable car il fonctionne entièrement dans le navigateur et, bien qu’il soit fortement axé sur des cas de test efficaces, il peut également se targuer d’offrir des fonctionnalités ad hoc directes. Les analyses qu’il fournit après chaque test peuvent également aider les équipes qui évitent activement de réaliser leur propre documentation indépendante tout en leur permettant de valider leur processus de test.
Cependant, les grandes suites pourraient avoir du mal à supporter son format basé sur un navigateur, ce qui peut limiter considérablement le gain de temps des tests ad hoc.
5. Zéphyr
Zephyr est une plateforme de gestion des tests de SmartBear qui aide les équipes d’assurance qualité à améliorer la visibilité de leurs tests tout en s’intégrant bien avec d’autres logiciels de suivi des bogues.
Cependant, cette fonctionnalité est limitée à certaines applications, Confluence et Jira étant celles qui bénéficient le plus de Zephyr – ce ne sont peut-être pas les solutions les plus efficaces pour toutes les entreprises. Plusieurs programmes évolutifs sont disponibles sous la marque Zephyr à différents prix.
Liste de contrôle, conseils et astuces pour les tests ad hoc
Voici d’autres conseils que les équipes doivent prendre en compte lorsqu’elles effectuent des tests ad hoc :
1. Donner la priorité aux composants sensibles
Certaines caractéristiques ou certains composants sont naturellement plus exposés au risque d’erreur que d’autres, surtout s’ils sont importants pour le fonctionnement global du programme.
Chaque approche des tests doit permettre d’identifier les parties d’une application qui peuvent bénéficier d’une attention plus approfondie. Cela s’avère particulièrement utile lorsque le temps imparti pour les tests est limité.
2. Étudier différents outils de test
L’outil qu’une organisation met en œuvre pour faciliter ses tests peut avoir une incidence sur la couverture et la fiabilité de ces contrôles.
Avec les tests ad hoc, il vaut la peine d’examiner autant de programmes que possible pour trouver ceux qui conviennent à son aspect centré sur l’utilisateur. Les logiciels qui utilisent la technologie de la vision par ordinateur, comme ZAPTEST, peuvent aborder les tests ad hoc en utilisant une stratégie semblable à celle de l’homme.
3. Adopter un état d’esprit ad hoc
Les tests ad hoc offrent une grande liberté tout au long de la phase d’assurance qualité, mais l’équipe doit s’y engager pour bénéficier des principaux avantages de cette stratégie.
Par exemple, les testeurs ad hoc doivent renoncer à tous leurs documents habituels au-delà de la prise de notes de base et ils doivent inspecter le logiciel d’un point de vue entièrement nouveau.
4. Faire confiance à son instinct
L’expérience des tests ad hoc ou des vérifications générales de logiciels peut contribuer à mettre en évidence les points communs de défaillance, ce qui aide les testeurs à déterminer comment repérer les erreurs de tous types.
Il est essentiel que les testeurs fassent confiance à leur instinct et utilisent toujours ces connaissances à leur avantage – ils peuvent deviner quelles vérifications ad hoc seraient les plus utiles.
5. Enregistrement complet des bogues découverts
Bien que les tests ad hoc n’aient pas de documentation formelle et reposent principalement sur des notes informelles, il est toujours essentiel que l’équipe soit en mesure d’identifier et de communiquer la cause d’une erreur logicielle.
Ils doivent enregistrer toutes les informations fournies par le test qui sont pertinentes pour les développeurs, telles que les causes potentielles de ces problèmes.
6. Toujours tenir compte de l’utilisateur
Chaque forme de test a pour but de prendre en compte, dans une certaine mesure, l’expérience globale de l’utilisateur – et les tests ad hoc ne font pas exception à la règle. Bien qu’ils examinent souvent plus en profondeur le fonctionnement interne de l’application et même son code interne, les testeurs ad hoc doivent essayer de casser ce logiciel de la manière dont les utilisateurs pourraient théoriquement le faire.
7. Améliorer en permanence le processus
Les équipes de test devraient affiner leur approche des tests ad hoc entre plusieurs itérations du même logiciel et d’un projet à l’autre.
Ils peuvent recueillir les réactions des développeurs pour voir dans quelle mesure leurs tests ad hoc ont contribué à la phase d’assurance qualité et s’ils ont été en mesure d’augmenter de manière significative la couverture des tests.
Conclusion
Les tests ad hoc peuvent aider les organisations de toutes sortes à authentifier leur stratégie de test de logiciels, mais la manière dont elles mettent en œuvre cette technique peut être un facteur important de son efficacité.
L’équilibre entre les différents types de tests est essentiel pour tirer le meilleur parti des contrôles ad hoc, d’autant plus que cette forme de test vise à compléter les autres en comblant une lacune stratégique.
Avec une application telle que ZAPTEST, il est possible pour les équipes de mener des tests ad hoc avec plus de confiance ou de flexibilité, en particulier si elles mettent en œuvre l’automatisation. Quelle que soit l’approche spécifique de l’équipe, son engagement en faveur des tests ad hoc pourrait révolutionner l’ensemble du programme ou du projet.
