Menu

Qu'est-ce que les tests exploratoires dans les tests logiciels (un guide complet)

  • Principal
  • Autre
  • Qu'est-ce que les tests exploratoires dans les tests logiciels (un guide complet)

what is exploratory testing software testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

Qu'est-ce que le test exploratoire?

Le «test exploratoire» - comme son nom l'indique, est un processus simultané d'apprentissage, de conception de test et d'exécution de test. Nous pouvons dire que dans ce test, la planification des tests, l'analyse, la conception et l'exécution des tests sont tous effectués ensemble et instantanément.

Ce test consiste à explorer le système et à encourager la réflexion pratique et en temps réel d'un testeur.

Dans cette série, nous avons couvert les tutoriels suivants:

Tutoriel n ° 1: Qu'est-ce que les tests exploratoires dans les tests logiciels (Ce tutoriel)
Tutoriel n ° 2: Utilisation des visites pour garantir des tests exploratoires complets
Tutoriel n ° 3: Tests exploratoires vs tests scriptés
Tutoriel n ° 4: Tests exploratoires avec HP Sprinter
Tutoriel n ° 5: Top 17 des outils de test exploratoire

************************************
Essais exploratoires

Ce que vous apprendrez:

Aperçu

En termes simples, les tests exploratoires impliquent la conception simultanée de cas de test et l'exécution de tests d'une application ou d'un système testé. Le testeur créera ou rédigera une idée de test pour donner une direction, et explorera le système tout en testant pour créer davantage de tests critiques, pratiques et utiles pour le test réussi d'une application.

Cela nécessite une planification minimale. Les testeurs prennent continuellement une décision sur sa prochaine étape d'action. Cela dépend entièrement du processus de réflexion du testeur.

Parfois, ce test peut être plus bénéfique que l'approche de test formelle pour trouver des défauts subtils qui disparaissent dans les tests formels.

Consciemment ou inconsciemment, chaque testeur aurait effectué des tests exploratoires à un moment donné de sa carrière.

Comme nous le savons tous, un apprenant apprendra mieux grâce à une expérience pratique plutôt que de bourrer la théorie.

De la même manière, un testeur ne connaîtra mieux l'application qu'en explorant et en apprenant toutes les fonctionnalités qu'elle fournit par elle-même. Il est toujours bon d'avoir un point de vue client et commercial lors des tests pour garantir le succès des tests d'une application.

Par exemple, si vous ouvrez un site Web d'achat, vous avez une idée générale que ce site Web d'achat vous permettra de faire des achats en sélectionnant un produit de votre choix, puis en payant pour le même.

Au cours de ce processus, vous pourriez apprendre que le site Web vous fournit un sosie humain virtuel qui vous aide dans le processus de sélection de produits. Vous avez également constaté que vous pouvez commander un certain nombre de produits pour un essai à domicile ou que vous pouvez effectuer un paiement via les points de récompense de certaines banques, etc.

En tant que testeur, vous devez non seulement vérifier si un système fonctionne comme prévu, mais également vérifier si ce système ne se comporte pas d'une manière qui n'est pas attendue.

Quelques points à retenir lors de l'exécution de ce test:

  • Votre mission doit être claire.
  • Assurez-vous de créer des notes et de rendre compte de ce que vous faites et du comportement d'un système, ce qui pourrait être un bogue potentiel.
  • Apprenez, observez puis créez de nouveaux cas de test.

Service d'essais exploratoires recommandé

# 1) Digivante Direct

Logo Digivante Direct

Digivante Direct effectue des tests exploratoires à l'aide de son réseau mondial de testeurs professionnels afin que vous puissiez couvrir les tests sur tous les principaux appareils dans un délai qui n'est pas réalisable par tout autre fournisseur de tests ou équipe interne.

Libérez-vous plus rapidement, plus sûrement et permettez à vos plateformes numériques de fournir une plus grande satisfaction client et une augmentation des revenus en ligne.

Caractéristiques:

  • 24 jours ouvrables de test en seulement 24 heures ou 90 jours ouvrables en 72 heures, et un niveau de tests complet et inégalé irréalisable par tout autre moyen.
  • À bas prix , des packages de tarification faciles à comprendre sans extras cachés.
  • En libre service portail en ligne qui ne nécessite aucun engagement permanent.
  • De vraies personnes testent sur de vrais appareils - une couverture d'appareils et de navigateurs bien supérieure à celle que vous pouvez obtenir en interne et le tout dans un délai d'exécution plus rapide.
  • Couverture complète des tests exploratoires - réduire les risques et améliorer la satisfaction des utilisateurs finaux et les taux de conversion, augmentant ainsi les revenus tout en réduisant les coûts.
=> Visitez le site Web de Digivante Direct

Exemples de tests exploratoires

Exemple 1:

Un site Web de fournisseur de services de soins à domicile avec les éléments suivants:

  • Connexion
  • Prestations de service
  • Chariot
  • Paiement
  • Historique des commandes
  • Attribution de techniciens

Une idée générale pour commencer exploratoire le test sera de se connecter ou de réserver un service.

Comment couvrir les cas de test?

Cas de test exploratoire

Questions et réponses pour l'entretien des tests d'automatisation du sélénium

Au dessus Exemple, l'idée est de commencer avec des fonctionnalités basées sur vos connaissances. Au fur et à mesure que vous en apprenez et observez davantage sur l'application, vous pouvez gérer votre prochain ensemble de cas de test.

Exemple n ° 2:

J'ai été une fois inclus dans un petit projet qui impliquait l'ajout d'un nouveau fonds commun de placement dans l'application. Ma tâche était de tester l'application pour m'assurer que le nouveau fonds commun de placement est disponible pour les utilisateurs à acheter et vérifier si la valorisation associée est correcte. Je n'avais que 2 jours pour terminer mes tests.

Étant donné le délai serré et la gravité des tests, j'ai utilisé l'approche exploratoire des tests. Mon objectif était de tester de nouvelles fonctionnalités et de trouver des violations des exigences de compatibilité.

L'objectif mentionné ci-dessus est devenu ma charte pour cette session de test.

Les cas de test suivants ont évolué au cours de ces tests:

  • Test pour s'assurer que le nouveau fonds commun de placement a été ajouté à l'application.
  • Le nouveau MF est acheté avec succès.
  • L'évaluation du nouveau MF est correcte.
  • J'ai essayé d'acheter un nouveau MF pour un portefeuille existant.
  • Un nouveau MF peut-il être ajouté à tous les portefeuilles?
  • Impact du nouveau MF sur la valorisation de l'existant.
  • Donc, dans d'autres cas de test ont été évolués.

J'ai préparé des notes et des rapports lors de mes tests pour discuter de mon observation avec le BA et le client impliqué.

La stratégie fondamentale des tests exploratoires est d'avoir un plan d'attaque. Commencez à tester avec votre idée et improvisez de nouveaux cas de test en fonction de vos connaissances et de vos observations.

Exemple n ° 3:

Essais exploratoires du site Web de l'IRCTC

=> Cliquez ici pour télécharger les exemples de cas de test de tests exploratoires du site Web de l'IRCTC.

Approche de test

  • Utilisez l'heuristique pour guider les tests.
  • L'exécution des cas de test et la création de cas de test vont de pair.
  • Les cas de test continuent d'évoluer en fonction de l'observation et de l'apprentissage des testeurs.
  • Différentes techniques de test comme Analyse de la valeur limite , les tests d'équivalence, etc. peuvent être appliqués à ET.
  • ET basé sur la session peut être utilisé pour le rendre plus structuré et ciblé.
  • Les testeurs peuvent dériver leurs idées mais ne jamais s'éloigner de votre mission.
  • Les tests ET n'utilisent pas de scripts, mais dépendent de l'intuition, des compétences et de l'expérience du testeur.

Avantages

Les avantages de ce test incluent:

  • Favorisez la réflexion en temps réel et aide à découvrir plus de défauts.
  • Promouvoir les cas d'utilisation et les tests basés sur des scénarios.
  • Documentation minimale, tests maximum.
  • L'accent est davantage mis sur l'apprentissage et l'élargissement de l'horizon d'un testeur.
  • Évitez le travail en double.
  • Utile lorsque vous souhaitez auditer le travail d'autres testeurs.

Démérites

Les démérites sont inscrits ci-dessous:

  • Les tests dépendent de l'expérience, des compétences et des connaissances du testeur.
  • Nécessite du temps pour apprendre l'application. Le testeur est plus susceptible de manquer s'il en sait moins sur l'application.
  • Ne convient pas aux projets avec un temps d'exécution long.

Tests exploratoires basés sur des sessions

Lors des tests exploratoires, il est très difficile pour les testeurs de mettre des mots sur combien il a testé et sur quelle base.

En gros, il est difficile de quantifier le travail et le temps passé. Cependant, dans chaque projet, nous devons fournir des mesures, des estimations et des rapports d'avancement aux chefs d'équipe et aux gestionnaires. Comme le dit le proverbe, «si vous ne pouvez pas le quantifier, vous ne pouvez pas le gérer».

Les tests basés sur la session sont une approche basée sur le temps pour effectuer ces tests, ce qui facilite la gestion et le suivi. Il comprend une session de test limitée dans le temps sans interruption du courrier électronique, du téléphone, des messages, etc.

Approcher:

Les tâches de test sont divisées en sessions.

Voici les composants des tests basés sur la session (SBT):

  • Mission: La mission crie le but de la session et, d'une certaine manière, fournit une orientation au testeur. Il comprendra également une durée de session.
  • Charte: Comprend la portée des tests. Fondamentalement, un ordre du jour détaillant les objectifs à atteindre au cours de la session.

Exemple de charte de test pour la fonctionnalité de connexion du site Web du service de soins à domicile:

Exemple de charte de test pour la fonctionnalité de connexion

  • Session: Session de test programmée prédéfinie sans aucune interruption. Chaque session peut avoir la durée suivante:
    • 'Court' (60min)
    • 'Normal' (90 min)
    • «Long» (120 min)
  • Rapport de session: Incluez des notes et un rapport léger pour fournir des mesures aux dirigeants et aux gestionnaires. Il donne des détails sur la session de charte restante ou terminée, l'heure de configuration de la session, le scénario testé, le processus de test, une liste de bogues et les problèmes trouvés et d'autres informations pour les métriques.
  • Résumé de la session: Une brève réunion ou stand-up entre le testeur et le Test Lead / Manager pour passer en revue les résultats de la session de test.

Les gestionnaires peuvent obtenir les mesures pratiques suivantes en fonction du rapport de session:

  • Le nombre de sessions terminées et restantes.
  • Le nombre de bogues signalés.
  • Temps consacré à la configuration de la session.
  • Temps consacré aux tests.
  • Temps consacré à l'analyse des problèmes ou des problèmes.
  • Fonctionnalités couvertes.

Pour résumer ce qui précède:

SBT permet la responsabilisation des tests exploratoires et offre une meilleure gestion du temps consacré aux tests. Il augmente également la productivité et offre une meilleure compréhension de la détection des bogues. C'est un excellent moyen de fournir aux chefs d'équipe et aux gestionnaires des mesures pour vérifier l'avancement du projet.

Essais exploratoires par paires

Le test de paire est une approche dans laquelle deux personnes testent la même chose / fonctionnalité de l'application en même temps en partageant un PC. Ils partagent continuellement leurs pensées et leurs idées. Lors de ce test, une personne prend en charge le clavier tandis que l'autre suggère des cas de test et prend note.

Il est toujours utile d'avoir une bonne communication entre les partenaires pour que les deux sachent ce qui est fait et pourquoi. Une paire dans laquelle la force des testeurs complète mutuellement leur faiblesse est considérée comme un groupement fort.

Un tel jumelage profite aux deux parties et chacun peut apprendre quelque chose de son partenaire. C'est également un bon moyen de former de nouvelles ressources en les associant à des ressources expérimentées.

Avantages du test de paires

  • Aide un testeur à se concentrer sur la tâche à accomplir.
  • Encouragez la confiance mutuelle et le respect entre les partenaires.
  • Le brainstorming entre des testeurs appariés conduit généralement à des idées plus constructives.
  • Évitez la vision tunnel.
  • Il y a moins de chance que d'autres les interrompent.

Techniques d'essais exploratoires

Tours: C'est une technique simple qui permet à un testeur d'utiliser son imagination et de se considérer comme un touriste explorant une ville qu'il visite. Ici une application à tester est la ville et les testeurs sont les touristes. Il est très difficile d'explorer toute la ville à moins d'avoir beaucoup de temps et d'argent en main, donc un touriste doit avoir un plan avec un certain objectif en tête.

Un touriste peut faire les visites suivantes:

  • Visite guidée - Test de la fonctionnalité mise en évidence de l'application. Utilisez des scénarios basés sur l'utilisateur.
  • Explorer l'histoire de la ville - Testez les anciennes fonctionnalités d'une application.
  • Tour d'argent, ce qui signifie s'assurer que toutes les fonctionnalités critiques en référence au client ou client sont testées et fonctionnent avec succès.
  • Tournée Crime Spree - Entrez une entrée invalide et testez des scénarios négatifs.
  • Visite de la ruelle - Testez les fonctionnalités les moins utilisées de l'application.
  • Tour ennuyeux - Passez un minimum de temps sur chaque écran de l'application, remplissez les champs minimum et prenez le chemin le plus court. Cela aidera avec la valeur par défaut et les tests de validation.

Lors d'une visite guidée, vous avez toujours le choix de prendre n'importe quel itinéraire. Vous pouvez naviguer dans le logiciel et trouver un chemin unique pour tester la fonctionnalité.

Voici quelques conseils / astuces que vous pouvez utiliser dans ET:

  • Divisez l'application en modules et bifurquez les modules en différentes pages. Démarrez votre ET à partir des pages. Cela donnera la bonne couverture.
  • Faites une liste de contrôle de toutes les fonctionnalités et mettez une coche lorsque cela est couvert.
  • Commencez par un scénario de base, puis améliorez-le progressivement pour ajouter plus de fonctionnalités pour le tester.
  • Testez tous les champs de saisie.
  • Tester le message d'erreur
  • Testez tous les scénarios négatifs.
  • Vérifiez l'interface graphique par rapport aux normes.
  • Vérifiez l'intégration de l'application avec d'autres applications externes.
  • Vérifiez la logique métier complexe.
  • Essayez de faire le piratage éthique de l'application.

Les facteurs qui affectent ET sont les suivants:

  • L'objectif du projet
  • Stratégie de test
  • L'objectif de test d'une phase particulière
  • Outils et installations disponibles
  • Rôle et compétences des testeurs
  • Temps disponible
  • Support à la gestion
  • Soutien par les pairs
  • Ressources disponibles (matériel d'étude, conditions d'essai, etc.)
  • Intérêt des clients
  • Compréhensibilité du produit.
  • L'interface utilisateur de l'application
  • La fonctionnalité de l'application
  • Résultats des tests précédents
  • Risques associés à l'application
  • Défauts antérieurs
  • Changements récents
  • Types de données à utiliser pour les tests
  • Type d'utilisateur qui l'utilisera

Au lieu de demander aux testeurs ce qu'ils doivent exécuter, nous laissons le jugement du testeur décider de ce qu'il souhaite tester et de la manière dont il souhaite tester.

Différence entre les tests exploratoires et les tests ad hoc

Ne confondez pas ET avec Test ad hoc .

  • Les tests ad-hoc font référence à un processus de recherche de défauts non scriptée, non planifiée et impromptue, tandis que les tests exploratoires sont une méthodologie réfléchie pour les tests ad-hoc.
  • Les tests ad-hoc sont une méthode d'essai et d'essai pour trouver un bogue alors que ET ne l'est pas. Dans l'approche ET, un testeur découvre le système au fur et à mesure qu'il explore et fait évoluer les tests en utilisant les connaissances acquises.
  • Les tests ad hoc sont une activité non structurée alors que ET est une activité quelque peu structurée.

Tests automatisés exploratoires (EAT)

Les tests automatisés exploratoires sont une méthode qui aide un testeur à rationaliser le signalement et la reproduction des bogues, la collecte d'instantanés et la préparation de la future combinaison de régression. Il s’agit d’un processus qui combine des tests d’automatisation et des tests exploratoires.

Il existe deux types d'approche EAT:

  • EAT passif
  • EAT actif

EAT passif

L'EAT passif peut être effectué par un seul testeur ou par paire. Dans cette méthodologie, généralement, un outil qui capture et enregistre chaque activité effectuée par une ou plusieurs ressources de test et est installé sur le PC de la ressource.

Passive EAT est similaire à l'ET qui est effectué manuellement car il n'y a aucun changement dans la façon dont les tests sont exécutés en dehors de l'élaboration du résultat du test basé sur la session capturée. Ces résultats de test peuvent être utilisés pour rapporter et reconstituer des actions enregistrées plus tard dans le temps.

L'outil vidéo installé aide un testeur à enregistrer les cas de test et à signaler les défauts.

Il présente également quelques autres avantages tels que:

  • Fournit des étapes claires pour reproduire les bogues.
  • La reproduction des défauts est plus facile même lorsque le rapporteur de défauts n'est pas disponible.
  • Éliminez les conflits entre l'équipe de test et l'équipe de développement lorsqu'un bogue intermittent est signalé.
  • Aide aux tests de performances en obtenant le temps de réponse du système à un moment précis.

Voici quelques autres points à prendre en compte avant le Passive EAT:

  • Il est conseillé d'effectuer un test pilote avant d'adapter complètement l'outil pour Automated EAT. Ceci permet de garantir que le temps requis pour la reconception des journaux de test créés pendant la session de test ne dépasse pas l'exécution du test. Si tel est le cas, l'équipe doit prendre une décision mutuelle sur les points suivants:
    • Si du tout, l'automatisation des tests est nécessaire pour le projet particulier.
    • Si l'outil utilisé doit être changé.
    • Si les performances de l'outil utilisé peuvent être optimisées.
  • L'outil utilisé pour effectuer un EAT automatisé doit être installé sur chaque ressource de test impliquée dans les tests. C'est également une bonne idée d'impliquer les développeurs, ce qui peut être réalisé en donnant aux développeurs un VPN ou un accès à distance aux machines de test ou en installant l'outil dans l'environnement de développement.
  • C'est toujours une bonne idée d'organiser l'objet GUI de l'application dans l'outil de test afin que, lorsque vient le temps d'analyser le bogue ou un problème, l'objet soit reconnaissable grâce à un nom significatif.
  • Il est très pratique de donner un nom significatif à l'objet GUI utilisé dans AUT et de les garder organisés pour une utilisation ultérieure.

Maintenant, passons à la deuxième approche.

EAT actif

Il est conseillé d'effectuer Active EAT avec Pair Testing. Dans cette approche, le test basé sur les mots clés est utilisé en synchronisation avec le test de session. Un testeur crée le script de test automatisé et le second testeur exécute les scripts de test créés par le premier testeur.

La création de scripts de test d'automatisation dans cette approche prend un chemin différent de celui des tests conventionnels. Des scripts de test automatisés sont créés pendant les tests et ce qui a été découvert lors des tests précédents détermine leur conception.

Une phase de clôture est exécutée à la fin de la session de test. Et il devrait avoir les tâches suivantes:

  • Les testeurs impliqués doivent permuter les rôles afin que la ressource de test qui a créé le script de test ait une chance de réexécuter les scripts pour confirmer la fiabilité et la robustesse de la suite créée.
  • Une brève description ainsi que quelques caractéristiques d'identification doivent être fournies pour chaque script de test automatisé.
  • Un critère doit être défini pour identifier les scripts de test automatisés pouvant être utilisés pour le test de régression.

Avantages de EAT

  • Au début de chaque session, des scripts de test automatisés déjà créés sont exécutés, améliorant ainsi la couverture de test à chaque fois.
  • Meilleur rapport de bogue et documentation pour la reproduction des défauts.
  • EAT fournit suffisamment de preuves et de documentation pour qu'une partie prenante puisse voir les progrès.

Types de tests exploratoires

Voici quelques types d'ET:

1) Freestyle ET:

Exploration de l'application dans un style ad hoc.

Dans ce type d'ET, il n'y a pas de règles, pas de compte de couverture, etc. Cependant, ce type de test est bon lorsque vous avez besoin de vous familiariser rapidement avec l'application, lorsque vous souhaitez vérifier le travail des autres testeurs, et quand vous voulez enquêter sur un défaut ou faire un test de fumée rapide.

2) ET basée sur un scénario:

Comme son nom l'indique, les tests effectués sont basés sur des scénarios. Cela commence par des scénarios d'utilisateurs réels, des scénarios de bout en bout ou des scénarios de test. Après le test initial, les testeurs peuvent injecter une variation selon leur apprentissage et leur observation.

Les scénarios sont comme un guide générique sur ce qu'il faut faire pendant l'ET. Les testeurs sont encouragés à explorer plusieurs chemins possibles lors de l'exécution d'un scénario afin de garantir que tous les chemins possibles vers les fonctionnalités fonctionnent. Les testeurs doivent également s'assurer de rassembler autant de scénarios que possible dans différentes catégories.

3) Stratégiebasé ET:

Techniques de test connues telles que l'analyse de la valeur limite, la technique d'équivalence et la technique basée sur les risques qui sont combinées avec des tests exploratoires. Un testeur expérimenté ou un testeur familiarisé avec l'application est désigné pour ce type de test.

Tests exploratoires agiles

Même si vous n'avez pas travaillé dans un environnement agile, je suis sûr que vous devez en avoir lu ou entendu parler en raison de sa popularité croissante. La méthodologie Agile a des sprints courts et des délais serrés, ce qui donne à une équipe quelques semaines pour terminer la planification, l'estimation, le développement, le codage, les tests et la publication.

quel est le meilleur dissolvant de logiciels espions

Les tests exploratoires deviennent utiles dans des délais aussi serrés, car dans cette approche de test, l'accent est mis sur le résultat rapide et utile. Une fois que vous avez compris l'exigence, vous pouvez commencer les tests en fonction de votre expérience et de vos connaissances.

Une fois que vous êtes familiarisé avec les fonctionnalités et le comportement de l'application, vous pouvez concevoir plus de cas de test pour valider la fonctionnalité de l'application et détecter les bogues imprévus. Comme il s’agit d’une approche de test de style libre, vous devez tout documenter. Cependant, vous devez conserver des notes et un bref rapport sur ce que vous avez testé, les bogues et problèmes trouvés, etc.

Mérites de l'exploratoire en Agile

  • Fournir des commentaires aux développeurs dès que possible.
  • Une plus grande variété de défauts est découverte.
  • Un groupe diversifié d'une ressource comme un développeur, un testeur, une BA, des concepteurs peut effectuer ET car il n'y a pas de cas de test scriptés et chacun apporte une perspective différente.
  • Le scoutisme effectué en ET aide à explorer de nouveaux territoires et à exposer des bogues critiques.
  • En cas de codage itératif d'une application, ET peut se concentrer sur le test de nouvelles fonctionnalités tandis que l'automatisation effectue des tests de régression et de compatibilité descendante.
  • En cas d'exigence instable, ET peut aider à tester de nouvelles exigences dans un temps limité.

Points à retenir:

1. Nécessite différentes compétences: Les testeurs effectuant des ET doivent avoir de bonnes capacités d'écoute, de lecture, de réflexion et de rapport. Une expérience du domaine est requise car il n'y a pas de scripts ni de cas de test.

2. Parfois, il est difficile de signaler un bug: Dans un flux ET, nous pouvons rencontrer un défaut, mais nous ne pourrons peut-être pas le reproduire. En effet, nous ne suivons pas les étapes de test et nous pouvons oublier les étapes exactes pour reproduire ce problème.

3. Peut être fait comme activité récréative: Personnellement, je fais ET lorsque je souhaite interrompre mon cycle d'exécution de test régulier. Mais de nombreuses équipes ont ET comme phase distincte de leur cycle de test.

4. Cela peut être fait pour toutes les phases de test: Nous pouvons implémenter ET avant le début de toute phase de test. Vous pouvez effectuer ET avant même la phase de test fonctionnel.

5. Rétroaction rapide: ET nécessite un retour rapide sur les problèmes et les anomalies rencontrées.

6. Esprit critique et des idées diverses: Ces tests nécessitent une réflexion critique. Les testeurs doivent être capables de reproduire, de revoir et d'exprimer leurs idées de manière logique. Un testeur peut mettre en œuvre son expérience dans les différentes technologies et domaines sur lesquels il a travaillé.

Comment penser au-delà des limites des tests traditionnels dans les tests exploratoires

«J'apprécie vraiment votre préoccupation pour le produit et nous rend utiles dans la perspective de l'utilisateur final. Cela va être très utile. Merci pour le bon travail et continuez comme ça !!! »

C'était le dernier e-mail d'une chaîne d'e-mails avec 21 e-mails de notre client. Il était minuit et la sortie de notre produit a été retardée en raison d'un bug critique que nous avons trouvé. Vous pourriez penser, qu'est-ce qu'il y a de nouveau là-dedans? Cela peut arriver plusieurs fois. Mais c'était vraiment différent car le bogue critique que nous avons signalé n'était le résultat d'aucun cas de test documenté.

Après avoir complété les tests de régression pour la dernière fois ce soir-là, je jouais juste avec le produit. Qu'est-ce que cela signifie? Vous êtes libre de faire ce que vous n'êtes pas censé faire. Sur la base de mon expérience et de ma connaissance du projet, j'ai eu quelques idées sur la façon de tester le produit en dehors de notre référentiel de test typique, appelé Essais exploratoires .

Les tests exploratoires effectués ont trouvé un bogue critique lié à un problème de blocage du serveur lors d'une action inattendue.

En tant que fan des tests exploratoires, j'aime explorer le produit de différentes manières. Pour moi, la définition d'un logiciel est:

«Il doit faire ce qu'il est censé faire, et il ne doit pas faire ce qu'il n'est pas censé faire.»

Processus de test exploratoire

Limiter les limites des tests pour vérifier si les produits censés fonctionner fonctionnent fait de vous un testeur incomplet. En fait, la vie d’un testeur commence lorsque les tests de régression documentés se terminent et que les résultats sont mis à jour. Examiner les produits sous différents angles et comprendre les exigences des utilisateurs finaux dans différents scénarios fait une grande différence. Alors aujourd'hui, comprenons ensemble comment cette différence peut être faite:

Comment regarder un produit sous différents angles?

tests exploratoires

#1. Comprendre le client / l'utilisateur final

Le test logiciel consiste à vérifier la qualité du produit en termes de satisfaction client. Comment connaissez-vous le point de vue d’un client? La réponse est simple: vous devez être le client. OK, laissez-moi faire une correction. Être client ne suffira pas. Vous devez comprendre comment le client souhaite gérer le produit. Aucun client ayant acheté les mêmes matières premières ne préparera la même recette. Oui, le produit que nous développons / livrons est une matière première pour les entreprises des clients et ils ont un état d’esprit différent lorsqu’ils l’utilisent.

En tant que testeur de logiciel, nous devons vérifier le but du produit et non l'objet ou l'aspect de celui-ci.

Laissez-moi vous donner quelques exemples concrets:

  • Les ciseaux n'ont jamais été limités au papier découpé uniquement. La découpe est le but et non le papier (objet).
  • Les téléphones portables ne se sont jamais limités à appeler, mais «pouvoir appeler» a toujours été l'objectif fondamental.
  • Les boîtes de stockage sont utilisées pour stocker, mais la sécurité du matériel stocké est aussi importante que le stockage.

Comprendre les parties prenantes et un large éventail de leurs attentes devrait être la base des tests exploratoires.

# 2. Un état d'esprit

Lorsque vous cherchez (disons) une annonce d’emploi, voyez-vous ce jackpot et entre les pages avec la police en gras? La plupart d’entre nous ne le font pas (croyez-moi, c’est vrai). Parce que nous avons demandé à notre esprit de chercher ce qui est utile ou à vérifier. Tout le reste n'est d'aucune utilité, alors l'esprit nous refuse de le reconnaître.

Ouvrez votre esprit et ne vous fixez aucune attente lorsque vous commencez à explorer un produit . Rappelez-vous toujours que ce n’est pas OK si le produit fait ce qu’il est censé faire. Il est également important qu'il ne fasse pas ce qu'il n'est pas censé faire.

Je me souviens d'un exemple classique:

Sous Linux, la commande «cat» est utilisée pour vérifier le contenu d’un fichier et la commande «ls» est pour vérifier le contenu du répertoire. En travaillant avec Linux et en testant des logiciels pendant cinq ans, je n'ai jamais pensé à faire du chat parce que mon esprit était déterminé; si j'avais besoin de contenu dir, je dois utiliser «ls». Cela a fonctionné, mais le revers de l'attente est que le produit n'était pas censé se comporter de la manière dont il n'était pas censé le faire, était faux. Un de nos clients, qui ne connaissait pas bien Linux, a fait des chats par erreur et le système s'est écrasé. Nous avons payé pour cet état d'esprit.

Soyez toujours prêt à faire des erreurs avec le logiciel, car c'est ce que va faire l'utilisateur final. Pour tester le logiciel, vous avez été formé, mais l'utilisateur final ne sera pas aussi formé que vous ou il / elle ne sera pas autant un expert technique que vous. De plus, il / elle fera n'importe quoi avec le logiciel en cas de problème.

Pensez à ces scénarios et fournissez des commentaires sur les tests. La vie du logiciel et la vôtre (en tant que testeur) vont basculer.

# 3. Connaître les concurrents

Lors du test d'une application logicielle pour votre client, avez-vous déjà tenté de connaître et de comprendre d'autres logiciels dans le même but? Avez-vous déjà suggéré des fonctionnalités utiles que vous avez observées dans le produit d’un concurrent? Cela ne rentre pas dans notre description de poste, est la réponse typique. Mais connaissez-vous l'avantage de le faire?

Voici quelques exemples concrets pour vous faire comprendre le point:

  • N'aimez-vous pas le créateur qui non seulement coud votre robe, mais vous fournit également des informations sur les accessoires assortis?
  • N'aimez-vous pas la marque de pizza qui non seulement fait de bonnes pizzas, mais qui livre à domicile le plus à temps?
  • N'aimez-vous pas le photographe qui non seulement prend de bonnes photos, mais suggère un autre type de cadres pour la séance photo?

Tout le monde veut avoir quelque chose de plus pour ce pour quoi il paie. Notre analyse des logiciels concurrents peut fonctionner de la même manière pour nous. Le client aime toujours entendre des suggestions précieuses - principalement des suggestions comparatives pour rendre le produit plus utile ou commercialisable.

De plus, ce genre de comparaison et d'analyse de la même gamme de produits rend notre analyse plus puissante et finalement nous créons un trésor sur lequel nous pouvons revenir à tout moment et trouver quelque chose d'utile.

Conclusion

L'exploratoire ne relève pas d'une méthode de test conventionnelle, mais c'est quand même une méthode de test très puissante.

Il fait ressortir l'idée originale d'un testeur et l'encourage à proposer des cas de test pratiques et en temps réel pour trouver un défaut. Sa nature freestyle lui donne un avantage sur les autres types de tests et peut être effectué n'importe où, que ce soit un projet utilisant Agile ou waterfall ou tout autre projet nécessitant une documentation minimale.

Le succès des tests exploratoires dépend de nombreux éléments incorporels tels que la compétence d'un testeur, la capacité de créer des cas de test efficaces, leur expérience et le talent de suivre leur instinct.

Il est impératif de se rappeler que ET est un processus adaptatif plutôt que prédictif et il est essentiel de maintenir un équilibre sain entre les tests exploratoires et programmés ou réguliers.

Êtes-vous un testeur qui a des expériences typiques de tests exploratoires? Nous attendons vos pensées. N'hésitez pas à les partager dans la section commentaires ci-dessous.

Tutoriel suivant # 2: Comment utiliser les visites pour garantir des tests exploratoires complets

lecture recommandée

^