Menu

Test piloté par le contexte: 7 principes de base avec un exemple

context driven testing

Essayez Notre Instrument Pour Éliminer Les Problèmes

7 Principes de base des tests contextuels avec un exemple:

meilleur pare-feu gratuit pour windows xp

Lorsque je conduis à l'aéroport, je prends généralement l'autoroute qui m'y amènera dans les plus brefs délais et évite les péages. Mais ce jour-là, j'ai emprunté un itinéraire routier local plus long avec un péage. Parce que je voulais quelques minutes supplémentaires avec mon ami sur le trajet, qui a parcouru une très longue distance pour passer le week-end avec notre famille. Le pire choix normal, dans ce cas, s'est avéré être le meilleur.

Mais, considérez ceci.

Et si j'étais à court d'essence?

Et si j'avais peu d'argent?

Je choisirais l'option différente. Pourquoi? Le contexte.

Qu

(image crédit )

Lorsque vous prenez des décisions basées sur les éléments suivants, il s'agit d'une décision contextuelle:

  • Les personnes impliquées
  • Conditions
  • Buts
  • Options disponibles
  • Émotions, etc.

Alors, qu'est-ce que les tests contextuels?

Les tests contextuels sont un changement de mentalité (ou école de tests) développé par Cem Kaner, James Bach et Bret Pettichord. Des détails à ce sujet peuvent être trouvés dans leur célèbre livre: Enseignements tirés des tests logiciels .

Il y a 7 principes de base. Les éléments suivants sont directement tirés de leur livre:

#1) La valeur de toute pratique dépend de son contexte.

#deux) Il existe de bonnes pratiques dans le contexte, mais il n'y a pas de bonnes pratiques.

# 3) Les gens, travaillant ensemble, sont la partie la plus importante du contexte de tout projet.

# 4) Les projets se déroulent au fil du temps de manière souvent imprévisible.

# 5) Le produit est une solution. Si le problème n’est pas résolu, le produit ne fonctionne pas.

# 6) Un bon test de logiciel est un processus intellectuel difficile.

# 7) Ce n'est que grâce au jugement et à la compétence, exercés en collaboration tout au long du projet, que nous sommes en mesure de faire les bonnes choses au bon moment pour tester efficacement nos produits.

Je ne vais pas expliquer chacun d'eux car c'est fait pour nous par le experts eux-mêmes ici .

Je vais simplement faire une explication basée sur un scénario sur mon point de vue sur les tests contextuels.

Un exemple de test piloté par le contexte:

Supposons que je commence un projet de test - Projet A qui comprend des tests de bout en bout pour une application Web.

quel est le meilleur logiciel de suppression de logiciels malveillants

Quelle serait ma stratégie?

Selon les processus standards, ce sera la séquence des événements:

  • Recueillir les exigences et comprendre l'application
  • Créer un plan de test
  • Créer une documentation de test - Scénarios de test, cas de test, matrice de traçabilité, etc.
  • Faire réviser et approuver toute la documentation
  • Configurer l'environnement QA et tester les données
  • Effectuer l'exécution du test
  • Créer des rapports de bogue
  • Générez et partagez des rapports d'état d'exécution de test, etc.

Si je me pose la question: «Comment ai-je décidé que c'était ce que je devais faire?» Ma réponse serait, les meilleures pratiques, les normes d'assurance qualité, les directives de l'industrie, les bases de l'expérience passée, etc., n'est-ce pas?

Je répète ce qu'on m'a appris à faire ou ce que j'ai vu d'autres faire.

Maintenant, y a-t-il quelque chose qui ne va pas avec ça? Pas du tout. Cela pourrait même fonctionner aussi car il y a un certain sens de répétabilité et de temps éprouvé dans cette approche. Cependant, ouvre-t-il la voie à des résultats optimaux?

Douteux. Pourquoi?

Parce que pour chaque projet, vous allez faire face à des circonstances différentes:

  • Exigences documentées ou non documentées
  • Équipes en étroite collaboration ou réparties géographiquement
  • Équipes de développement et de test appartenant à la même entreprise vs concurrence
  • Temps suffisant vs. Des horaires serrés
  • La composition de votre équipe - Nouveaux arrivants vs expérimentés. Formés vs non formés.
  • Disponibilité des outils - Utilisation des outils de gestion manuelle ou de gestion des tests
  • Type de projet - Nécessite un strict respect des règles (FDA ou banque) vs expérimental (comme les médias sociaux)
  • La technologie du projet.Par exemple:vous ne testeriez pas le Web et une application Windows de la même manière
  • Exigences des clients (certains veulent des rapports détaillés quotidiens, d'autres ne veulent que les faits saillants)
  • Processus suivi (Agile vs traditionnel, scripté vs test exploratoire)

Cette liste n'est pas exhaustive et vous savez aussi bien que moi qu'il existe de nombreuses variables à chaque projet.

Les tests contextuels consistent à laisser ces circonstances décider de vos pratiques de test, de vos techniques et même de vos définitions plutôt que de la norme, perçue par l’industrie. les meilleures pratiques' .

Maintenant, disons que voici les détails avec lesquels je travaille pour le projet A:

  • Je travaille avec une équipe de 5 à 4 nouveaux arrivants et 1 testeur expérimenté.
  • Je n'ai aucune exigence documentée.
  • Mon équipe est en Inde et l'équipe de développement est aux États-Unis, nous travaillons donc dans des fuseaux horaires opposés.
  • Le client souhaite un rapport d'état détaillé quotidien
  • Nous utilisons un outil de suivi des bogues basé sur le Web, tel que Mantis ou Bugzilla et c'est tout ce que nous avons.
  • Je dois faire 2 séries de tests en 10 jours avec 3 jours pour la documentation des tests

Voici un plan de match approximatif:

1) Étant donné que beaucoup de nouveaux arrivants sont dans l'équipe, nous avons besoin de nombreux examens par les pairs.

deux) Nous avons également besoin d'au moins 2 réunions de discussion sur les exigences avec l'équipe BA et Dev. Cela doit être formel car les équipes sont situées ailleurs et il me reste peu de place pour les aborder avec des questions.

3) Il s'agit d'un calendrier de test agressif pour la documentation. Plus nous rédigeons de documentation, plus nous avons besoin de révisions, ce qui équivaut à plus de temps. Donc, nous devrons garder une documentation minimale. Nous allons documenter uniquement le principal TC de bout en bout et le reste va être testé exploratoire .

4) Des rapports d'état quotidiens pendant l'exécution des tests seront créés et envoyés chaque jour.

5) La plupart des tests sont exploratoires, alors conseillez le temps d'essayer de faire un bref aperçu de chaque test exécuté. De cette façon, nous savons ce qui est testé et ce qui ne l'est pas.

6) Les défauts seront signalés en temps réel dans Mantis. Étant donné que l'équipe travaille dans un fuseau horaire différent, ils devront peut-être attendre une journée entière avant d'entendre l'équipe d'assurance qualité, au cas où ils auraient besoin d'une clarification. Par conséquent, organisez un appel quotidien dans une équipe pratique, où l'équipe d'assurance qualité fera une démonstration de la reconstitution des bogues. De cette façon, il n'y aura pas besoin d'attendre ou de faire un suivi.

Etc.

Une fois que vous avez une stratégie globale, rédigez un plan de test de base expliquant ces points. Vous êtes maintenant prêt à vous lancer dans un projet de test après un examen attentif et une stratégie de réussite personnalisée.

En résumé:

C'est Tests contextuels; faire de votre situation (pas des normes) les principaux intrants et influenceurs de votre stratégie de test. Il nous pousse à regarder autour de vous et à prendre en compte tout ce qui vous entoure.

Personnellement, je suis amoureux de ce concept car trop souvent les pratiques de test sont perçues comme rigides et basées sur l'imitation. Quelqu'un l'a fait et a réussi, alors je vais le faire aussi. C'est le genre d'image qui effraie les gens d'essayer et de rester dans une carrière de testeur.

Mais, il y a beaucoup de place pour la pensée créative, les compétences analytiques et la prise de décision. Pour en savoir plus, lisez le sujet dans les liens fournis ci-dessus.

Bon test basé sur le contexte

lecture recommandée

^