Qui devrait rédiger le plan de test?

10

Je fais partie de l'équipe de développement interne de mon entreprise et nous développons les sites Web de notre entreprise en fonction des besoins de l'équipe marketing. Avant de leur remettre le site pour des tests d'acceptation, on nous a demandé de leur donner un plan de test à suivre.

Cependant, l'équipe de développement estime que, puisque les exigences provenaient des demandeurs, ils auraient la meilleure connaissance de ce qu'il faut tester, de ce qu'il faut rechercher, comment les choses devraient se comporter, etc. et un plan de test n'est donc pas nécessaire. Nous sommes toujours en discussion à ce sujet, et les développeurs trouvent que c'est une perte de temps d'écrire des choses comme: -

  1. Cliquez sur le bouton A .
  2. Entrez XYZ dans le bouton champ de formulaire et cliquez sur B .
  3. Vous devriez voir le comportement C .

que nous devons répéter pour chaque exigence / fonctionnalité demandée. Il s'agit essentiellement de reformuler ce qui figure déjà dans le document des exigences.

Nous évoluons vers une approche Agile pour la gestion de nos projets et cela est également demandé à la fin de chaque itération.

Mis à part les tests unitaires et d'intégration, qui devrait être le seul à proposer le plan de test d'acceptation de l'utilisateur final? Doit-il s'agir des demandeurs ou des développeurs?

Merci d'avance.

Cordialement
CK

ckng
la source
1
La seule contribution à cela que les développeurs devraient avoir est de suggérer des zones et éventuellement des cas marginaux qui devraient être testés (et non oubliés). Mais ils ne devraient pas donner de détails étape par étape sur la façon exacte de tester.
CaffGeek

Réponses:

10

Le plan de test ne doit PAS être écrit par les développeurs. Le plan de test consiste en partie à vérifier si le développeur a correctement interprété l'exigence. Un développeur ne peut pas écrire efficacement un plan de test sur le code qu'il va écrire. Les plans de test doivent être rédigés par les personnes qui vont effectuer l'AQ ou par les analystes commerciaux. Si les développeurs doivent écrire les plans, n'affectez jamais quelqu'un pour écrire le plan pour la partie du programme qu'il va écrire.

Notez que ceci est différent de la conception de tests unitaires qui doivent être écrits par le développeur car il devrait tester le code qu'il a écrit pour voir s'il fait ce qu'il attend. Mais les plans de test consistent à tester pour voir si l'application fonctionne comme prévu et cela doit être fait par une personne qui ne sait pas comment l'application a été conçue pour fonctionner afin d'être efficace.

HLGEM
la source
C'est ce que je disais depuis des années à un poste.
David Thornley
1
Bien jusqu'à la dernière phrase, mais les tests ne devraient jamais se limiter à vérifier que l'application respecte les attentes (mais devraient également couvrir l'inattendu!), Et savoir au moins un peu comment l'application a été conçue techniquement m'aide TOUJOURS en tant que testeur à identifier les fissures dans lesquelles je peux obtenir mon pied de biche testeur pour tirer la chose grande ouverte. ;) C'est un peu une vieille notion d'imaginer que les testeurs feraient mieux de ne rien savoir de l'implémentation.
testerab le
1
Exactement, @testerab. Ne pas connaître les internes aide à concevoir certains types de cas de test, tout en connaissant les aides internes dans les tests de boîte grise, par exemple, je connais la zone à risque dans le code, j'ai juste besoin de prouver que l'application a atteint ce code.
dzieciou
7

L'équipe AQ ​​doit rédiger et exécuter le plan de test.

Idéalement, le plan de test doit être rédigé en parallèle avec la spécification fonctionnelle - c'est incroyable de voir comment la réflexion sur la façon de tester la fonctionnalité concentre l'esprit et améliore la spécification.

Chris Card
la source
3
Peut-être avec l'aide des développeurs, mais surtout de l'équipe QA.
Zachary K
Et si nous n'avons pas d'équipe QA? Cette tâche devrait-elle alors incomber aux demandeurs? D'après les réponses ici, ce serait plus logique.
ckng
Si vous vous dirigez vers Agile, essayez d'embaucher des personnes spécialisées dans les tests dans votre équipe de développement actuelle. (Remarque: lisez d'abord les différentes écoles de tests, certaines ne sont pas compatibles avec une approche Agile - redcanary.mypublicsquare.com/view/hiring-software )
testerab
2
Si vous n'avez pas d'équipe AQ, vous devrez vous réunir avec les demandeurs pour prendre cette décision. D'une part, les développeurs ne devraient pas avoir besoin de faire des plans de test. D'un autre côté, de nombreux clients / la plupart des entreprises ne connaissent pas le test, et vous passerez UNE TONNE DE TEMPS DE FORMATION ET DE MAINTIEN DES MAINS au début. Nous avons essayé une fois et les clients commerciaux ont eu beaucoup de mal. Les cas réguliers n'étaient pas un gros problème, mais en ce qui concerne les cas détaillés et en particulier les cas de tests négatifs, ils ont eu du mal. Il vaudrait mieux obtenir / désigner un responsable de l'assurance qualité ou un analyste commercial que de le confier aux clients.
sdek
4

Une réponse Scrum: Si vous souhaitez définir la `` Définition de Terminé '', vous remarquerez qu'avoir un plan de test devient rapidement l'un des éléments. Sinon, comment pouvez-vous décrire l'histoire à faire, si elle n'a pas été testée.

Qui est alors responsable de la création du plan de test? L'équipe

Qui est l'équipe? Toute personne engagée à réaliser le produit doit être membre de l'équipe.

Donc, dans votre cas, vous pouvez inclure (ou embaucher) la personne qui peut rédiger les plans de test dans votre «équipe de développement». Si vous passez à Agile, vous remarquerez que la création d'un plan de test se produit en parallèle du développement. Les deux partent de la même histoire, et grâce à la communication finissent par être synchronisés et livrés en même temps. Vous ne devez pas déclarer votre histoire «terminée» avant d'avoir réussi les cas de test que les parties prenantes considèrent comme critiques.

Rudi
la source
2

Je trouve que les plans de tests fonctionnels doivent être rédigés par des analystes fonctionnels / commerciaux. Ils écrivent l'analyse fonctionnelle (même si vous travaillez agile, je suppose que vous avez une analyse), et ils devraient donc être l'écriture des chemins dans l'application à suivre à des fins de test.

Cela dépend totalement de la façon dont vous travaillez, mais à mon avis, les développeurs ne devraient pas écrire de documents fonctionnels sur la façon de tester l'application, les données à utiliser pour la tester, etc.

koenmetsu
la source
2

Voici une idée qui pourrait rendre les deux groupes heureux et s'intégrer parfaitement à une approche Agile:

Automatisez vos vérifications d'acceptation des utilisateurs et effectuez une capture vidéo.

http://pragprog.com/magazines/2009-12/automating-screencasts

Cela ressemble à une partie du problème que vous rencontrez est que les plans de test que vous écrivez sont très répétitifs et purement confirmatifs. Pour être honnête, je n'appellerais pas du tout ce que vous écrivez des tests - si cela ne fait que confirmer les exigences, c'est vérifier . L'automatisation et la diffusion vidéo vous permettront de préparer régulièrement une démonstration soignée pour vos clients (vous pouvez même les envoyer sur une courte journée) - ils seront plus susceptibles de cliquer sur une démonstration et de la regarder que d'ouvrir un plan de test et commencez à travailler dessus, donc j'espère que vous obtiendrez des commentaires plus rapides (très important si vous vous dirigez vers une approche plus agile). Vous pourrez réutiliser les composants afin de réduire la charge de travail pour vous,

Il fournit également un moyen d'exécuter réellement les exigences - avez-vous rencontré les spécifications exécutables de Gojko Adzic? Jetez un coup d'œil ici: http://gojko.net/2010/08/04/lets-change-the-tune/ Si vous pensez à cela comme un moyen de mettre les exigences sous forme exécutable à démo à vos clients , cela semble soudain beaucoup moins inutile.

Maintenant, en mettant mon chapeau de testeur, je suis honoré de souligner que si le truc de screencast décolle, cela vous libérera / vos parties prenantes pourront faire des tests appropriés - c'est-à-dire essayer des cas de pointe et des tests qui contestent réellement l'application , plutôt que de simplement confirmer les exigences. Je vous suggère de fournir les captures d'écran ainsi que de courtes questions ou suggestions pour les domaines sur lesquels vous souhaitez plus de commentaires, par exemple:

1) Voici notre nouveau formulaire d'inscription - regardez ce screencast pour voir comment cela fonctionne!

Sur quoi nous aimerions avoir des commentaires: nous avons ajouté de nombreuses vérifications supplémentaires sur ce formulaire pour nous assurer que les clients ne sont pas en mesure d'entrer les mauvaises données - nous aimerions vraiment que vous regardiez les messages d'erreur que les clients reçoivent lorsqu'ils mettez la mauvaise chose et dites-nous si nos clients les trouveront faciles à comprendre.
Nous aimerions également savoir si nous avons été trop stricts dans certains cas - si vous avez des données client particulièrement inhabituelles (peut-être un nom vraiment long ou très court, ou quelqu'un avec des caractères inhabituels dans leur nom, ou autre chose à laquelle nous n'avons pas pensé, ou peut-être que leur adresse n'a pas de nom de rue ou quelque chose de bizarre comme ça?) alors peut-être pourriez-vous passer quelques minutes à les essayer?

C'est-à-dire que vous présentez un bon screencast, puis demandez des commentaires, encadrez-le sans être trop spécifique, faites-les réfléchir à des problèmes potentiels plutôt que de simplement confirmer. Faites-les réfléchir , au lieu de simplement cliquer aveuglément sur un plan de test. Vous rédigez essentiellement une charte de test exploratoire pour eux. (Si vous regardez les quadrants de tests agiles , ce seraient des tests dans le quadrant 3).

testerab
la source
Excellente réponse, excellent moyen de sortir les développeurs de la monotonie sourde tout en obtenant les commentaires des clients. Et d'excellents liens.
Ethel Evans
1

Prenons l'exemple de la rénovation de votre maison. Accepteriez-vous une liste de contrôle établie par votre entrepreneur vous demandant de cocher ce qu'il a fait pour vous? Ou pourriez-vous établir votre propre liste de contrôle et vérifier si l'entrepreneur a fait ce que VOUS avez spécifié?

La réponse est claire: le demandeur doit vérifier si ce qu'il a demandé est fait conformément aux spécifications. Il / elle doit sortir avec sa propre liste de contrôle et tester l'application. contre cette liste.

Le développeur, cependant, devrait avoir sa propre liste de contrôle et s'assurer que les tests internes appropriés sont effectués et les bogues corrigés avant de gérer l'application. plus pour UAT. Idéalement, le développeur devrait automatiser la plupart de ces tests sous forme de scripts de test. Rappelez-vous TDD? Idéalement, les scripts de test (dans ce cas, les cas de tests unitaires) devraient être écrits pour tester les composants des applications. Une suite de tests doit ensuite être écrite pour combiner ces cas de tests unitaires pour effectuer des tests de régression intégrés et ultérieurs.


la source
1

Le plan de test d'acceptation de l'utilisateur final est généralement rédigé par les clients ou un associé de l'entreprise qui représente le client. Il est censé représenter les fonctionnalités souhaitées par le client et complète les tests d'intégration de QA. Ni l'AQ ni le développement ne peuvent planifier efficacement les tests d'acceptation des utilisateurs, car l'un des principaux objectifs des tests d'acceptation des utilisateurs est de s'assurer que ce que l'AQ et le développement pensaient que le client voulait était réellement exact.

Ethel Evans
la source
en.wikipedia.org/wiki/… pour plus d'informations.
Ethel Evans
+1 pour indiquer que les tests d'acceptation des utilisateurs doivent être conçus par l'utilisateur. Bien que j'aie suggéré une approche alternative dans ma réponse (car il ne semble pas qu'ils aient réellement une ressource d'assurance qualité), les tests d'acceptation des utilisateurs ne peuvent pas être effectués efficacement par des non-utilisateurs. Dans cette situation, il semble que les développeurs et les utilisateurs soient un peu dans l'impasse, donc je pense que les développeurs doivent essayer de briser cela d'une manière ou d'une autre.
testerab le