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