Qui devrait rédiger le plan de test?

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

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.

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.

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.

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.

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).

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.

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.