Des plans de Test et la meilleure façon de les écrire

Question

Nous essayons de trouver le meilleur moyen d'écrire des tests dans notre plan de test.Plus précisément, lors de l'écriture d'un test qui est destiné à être utilisé par toute personne, y compris QA personnel, devrait les mesures dans le test être très précis ou plus large en donnant le testeur plus grande marge de manœuvre dans la façon dont la tâche peut être accomplie.Comme un exemple très simple, si vous testez l'ouverture d'un document dans le document de traitement de texte, si le test de lecture:

1. À l'aide de la souris, ouvrez le menu fichier
2. Choisissez "Ouvrir un Fichier..." dans le menu fichier
3. Dans la boîte de dialogue ouvrir fichier qui apparaît, naviguez jusqu'à x et double-cliquez sur le document appelé y

OU

1. Afficher la boîte de dialogue ouvrir fichier
2. Ouvrir le fichier y

Maintenant je me rends compte qu'une seule réponse sera probablement "cela dépend de ce que vous essayez de test", mais je vais essayer de répondre à une question plus large ici:Si les étapes de test sont trop précis, ne risquons-nous pas un), rendant le processus de test à long et fastidieux et surtout b) doit-on courir le risque de rater quelque chose parce que nous avons écrit trop spécifiques à un chemin d'accès pour atteindre un but.Alternativement, si nous en faire large ne nous trop dépendre des caprices du testeur à la fois et de perdre crucial expérimentation de parcours qui sont plus fréquents pour les clients/clients?

Answer 1

Ma première question serait - pourquoi n'est-ce pas votre service d'assurance qualité de l'écriture de la plans de test?Généralement, les développeurs de logiciels fournir l'assurance qualité avec une spécification fonctionnelle de la façon dont le logiciel est censé travailler, et puis QA crée des plans de test sur cette base.

Avec cela dit, je vous suggère d'être très précis avec le temps, car vous êtes détaillant la façon dont les choses sont censé de travail.C'est le travail de l'appareil de contrôle pour vous assurer que vos mesures spécifiques d'obtenir les résultats souhaités et c'est aussi leur travail pour s'écarter du plan et d'essayer de casser des choses.

Si il y a plusieurs façons d'atteindre un objectif, vous avez besoin pour décrire chaque chemin pour y arriver.

Answer 2

Je ne suis pas un testeur, mais à mon avis il est essentiel de documenter le "INTERFACE utilisateur de route" que le test doit prendre pour éviter toute confusion.

J'ai travaillé sur d'innombrables défauts que je ne pouvais pas reproduire tout simplement parce que je n'étais pas accès à la fonction à partir de la même INTERFACE utilisateur chemin d'accès que le testeur a été.par exempleMenu du Clic droit vs Barre d'outils ou fonctions qui peuvent être réalisées à partir de différentes boîtes de dialogue, etc.etc.

Answer 3

Il semble que votre QA personnel est vraiment QC (Contrôle de Qualité) si ils ne sont pas responsable de l'écriture des tests.Si elles ne le sont réellement responsable de l'écriture des tests, vos tests, vous sera utile, mais les spécifications sont claires serait une meilleure source pour eux d'écrire les tests eux-mêmes.Il serait encore mieux de les avoir dans le cadre du processus d'examen pour les specs, de sorte qu'ils peuvent demander des détails qui leur permettra d'écrire des tests.

Si vous êtes vraiment dans une position où vous écrivez des tests pour d'autres personnes, il ya quelques considérations.Vous voulez un douloureux de niveau de détail si :

• les personnes exécutant les tests ne sont pas en mesure de venir vous poser des questions
• les personnes exécutant les tests ne sont pas familiers avec votre produit

Vous pouvez éviter certains détails si ce n'est pas vrai.Cependant, il dépend encore :)

Tout cela étant dit, ce que vous avez écrit n'est pas ce qui est généralement considéré comme un "test plan".Un Plan de Test décrit quels sont les types de tests seront exécutés (fonctionnels, de régression, de sécurité, etc.), quelles sont les fonctionnalités à tester, peut-être même quels sont les tests à être écrite, qui vont faire le test, lorsque des groupes de tests sont prévues et autres type de planification des activités.

Ce que vous décrivez ci-dessus est tout simplement une série de tests.

Answer 4

La première est la fonction de test.Test avec les étapes détaillées contenant de l'INTERFACE utilisateur de l'itinéraire qu'il est peut-être plus de routes que de la destination.Test de toutes les routes.Ce dernier ressemble plus à des tests d'utilisabilité.Il faut le faire aussi, mais pas seulement par vos testeurs, mais aussi par des personnes extérieures.

Answer 5

Nous allons distinguer le Plan de Test et des Suites de Test :)

Suite de Test est un ensemble de tests de lui-même

Plan de Test est [une partie de] Suite de Test + ressources disponibles (personnes, matériel, temps, ...).

C'est OK d'avoir les deux variantes (détaillé et "rough") décrits dans la documentation de test, il suffit de placer détaillée et "rugueux" tests de différents documents et les classer par ordre de priorité des documents.

Ensuite, lorsque vous avez suffisamment de temps pour tester tout le produit, vous prenez tous les documents, disons, de la catégorie A et le produit à l'essai conformément à ces documents.Si vous n'avez pas le temps, mais de manière rapide conclusion au sujet de la qualité, vous prenez de la catégorie B de documents et de passer les contrôles qui y sont décrits.

bon côté:vous pouvez sélectionner la méthode de test de produit

mauvais côté:vous avez besoin de "dupliquer" documents

Answer 6

Il est parfaitement bien de vouloir exacte, détaillée, les étapes pour reproduire quand quelqu'un trouve un problème.Mais si vous écrivez vos plans de test, de cette façon, vous risque de les problèmes suivants:

1) La cécité inattentionnelle - J'ai vu des gens de l'exécution d'une procédure détaillée script de test, scrupuleusement la marche à travers et l'enregistrement de chaque étape méticuleusement, et MANQUE TOTALEMENT de l'erreur manifeste juste en face d'eux.Parce qu'il "n'était pas dans le script".Leur attention était tellement concentré sur tous ceux capricieux, étapes de test qu'ils ont littéralement ne pouvait pas voir les problèmes en face d'eux.

2) Vous manquez de TOUS ces bugs qui sont juste un pas hors de votre très détaillé, très précis chemin.Lorsque les clients de votre produit, ils ne suivent pas le plan d'essai.Ils vont naviguer autour de votre application dans une variété de façons.Ils vont changer leurs esprits.Ils ont des noms plus longs, ou courts, que vous pensiez, probable ou possible.Ils vont obtenir à mi-chemin par le biais d'une transaction et de l'abandonner.Ils vont se promener.Ils ne collent pas à un seul chemin.Et chaque fois que quelqu'un répète le test, ils vont manquer ces bugs à nouveau.

3) Vous permettra de passer un très long temps à essayer de faire "n'importe qui peut suivre ce" test des scripts écrits.Croyez-moi, j'ai passé des années à essayer de perfectionner ce, et il n'est tout simplement pas humainement possible.Pire encore, la quantité de temps que vous gaspillez à essayer de faire ce pourrait être dépensé beaucoup plus de profit de toute autre manière, de sorte que votre produit est le pire.

4) vous Vous retrouverez avec une tonne de répétition, et il est difficile de dire quel est le point de votre test est sans lire la totalité de la chose.Il ne sera pas facile de numériser rapidement à travers les tests pour voir ce que les cas d'utilisation que vous avez manqués.

Gardez vos plans de test large et de permettre aux gens de faire le test à l'exercice de leur jugement.Si vous avez des renseignements sur des scénarios d'utilisation spécifiques qui doivent être vérifiées, ou sur la façon dont le groupe d'utilisateurs cible sera souhaitez utiliser, puis donner les testeurs aussi bien avec les plans de test - peut-être sous la forme de personnages, peut-être juste dans la forme de cas d'utilisation.Si vous avez besoin de choses coché, pensez à utiliser une liste de contrôle.(Pour plus d'informations, voir Cem Kaner l'excellente présentation www.kaner.com/pdfs/ValueOfChecklists.pdf).

Sinon, écrivez votre l'essai des plans à court exploratoire des chartes.Vous pourriez, par exemple, de fournir des conseils tels que:"Centre d'appels d'utilisateurs sur les postes de travail avec des pas de souris ci-joint.Explorer le processus d'élever un ticket pour le compte d'un client, en veillant à ce qu'il est possible de compléter toutes les activités à l'aide de raccourcis clavier seulement." C'est beaucoup plus susceptible d'entraîner vos testeurs de trouver des défauts que de dire "Onglet dans le champ 1.Entrez "Plainte au sujet de la qualité de la ligne".Onglet dans le champ 2.Sélectionnez "appel" dans le menu déroulant.La languette dans l' ....domaine de 68."

Answer 7

il y a des avantages et des inconvénients pour le traitement de votre testeur comme ils n'ont pas de connaissance sur le système ou les ordinateurs en général.

si vous sort des choses dans le moindre détail (p. ex."à partir du menu fichier, sélectionnez "Open"...") que l'avantage est que vous pouvez utiliser entrepreneurs qui ne sont pas familiers avec le système. mais il vous faut plus de temps pour écrire comme cela

si vous passez beaucoup de détails (par ex."ouvrir un fichier..."), que celui qui utilise votre plan de test est plus susceptible de se coincer, et que vous interrompre pour des précisions. mais il est beaucoup plus rapide à écrire

il peut être une fausse économie, de penser à son plus rapide si vous ne le dynamisme de la version, si vous vous retrouvez juste de consacrer plus de temps à expliquer le système de l'assurance de la qualité de la personne

j'ai un article où je vais en plus en profondeur sur ce sujet: L'écriture d'un Système de Plan de Test

dans cet article, je suis en faveur de l'approche plus détaillée.mais j'ai été l'élaboration d'un "point milieu" entre ces deux approches dernièrement (appelé Test de FONCTIONNALITÉ de la plan), mais je ne suis pas à un point où son assez mature pour partager encore

-- LM