Les développeurs, les testeurs et les utilisateurs professionnels devraient-ils avoir un script de test unifié?

En cours de développement, j'aurais normalement mes propres scripts de test qui documenteraient les données, les scénarios et les étapes d'exécution que je prévois de tester; c'est mon plan de test dev. Une fois la fonctionnalité déployée dans Test, les testeurs la testent à l'aide de leur propre script de test qu'ils ont écrit. Dans UAT, l'utilisateur professionnel teste ensuite à l'aide de son propre plan de test.

Rétrospectivement, il semble que cela offre une meilleure couverture, avec des tests de développement ayant un mélange de tests de boîte noire et blanche, tandis que les testeurs et les utilisateurs professionnels se concentrent sur les tests de boîte noire. Mais d'un autre côté, cela fait apparaître des cas de test distincts qui ne sont exécutés que par étape (c'est-à-dire certains cas auxquels les testeurs pensaient ne sont exécutés que sur la phase de test) et il aimerait que le développeur le manque, ce qui en fait un constat / bogue .

Vaut-il la peine de consolider les scripts de test dès le départ? Ainsi, en utilisant un script de test unifié, ou est-il difficile de le faire à l'avance?

Premièrement, l'AQ n'est pas un test. Si votre service AQ n'est pas impliqué dans l'ensemble du processus de développement, il s'agit de Test, pas d'AQ. Le contrôle qualité lors de son travail, fournit une assurance qualité, au mieux le test montre le manque de qualité, mais ne peut pas prouver que la qualité existe - c'est-à-dire que le test montre que le contrôle qualité a échoué, mais ne peut pas montrer qu'ils ont réussi, donc le test et le contrôle qualité ne devraient pas être le même département.

Je pense que la meilleure façon est que chaque groupe gère ses propres tests, car il offre une meilleure couverture. Cependant, chaque équipe doit commencer les tests dès que possible. Cela signifie que l'UAT démarre dès qu'il y a quelque chose que les utilisateurs peuvent utiliser, le test démarre dès qu'une partie pour laquelle ils ont un test est prête, etc. Cela empêche la recherche tardive de cas de test distincts. Cela peut signifier une réorganisation de vos modèles de travail, car souvent UAT et Test s'attendent à travailler sur un produit complet et ont besoin de formation pour tester des sorties partiellement complètes. Cela peut être plus cher à moins que le flux de travail ne soit discipliné et qu'un développeur «Complet» signifie Complet.

L'AQ doit superviser cela, ainsi que d'autres mesures de qualité, pour garantir que le processus fournit non seulement la sortie de qualité souhaitée, mais également à un niveau d'efficacité approprié.

Edit: la référence de question d'origine à QA a été supprimée, par conséquent, cette réponse apparaît maintenant OT.

Nous utilisons les UAT depuis le début.

Il agit comme une référence universelle et je pense que cela fonctionne bien. Bien qu'il puisse y avoir des scripts de test qui ne sont utilisés que par les développeurs ou les testeurs pour les composants plus petits, la direction du test est toujours dirigée vers une cible unifiée. À la fin de la journée, l'UAT est le seul qui compte, alors vous pouvez tout aussi bien en faire le point de départ.

Faire des UAT dès le départ présente également un avantage supplémentaire. Cela élimine vraiment toute ambiguïté entre les attentes des clients et les vôtres.

Ils n'ont pas besoin d'un script de test unifié, car les choses qu'ils testent et la façon dont ils effectuent les tests sont souvent censées être différentes, ce dont ils ont besoin est une exigence unifiée sur laquelle toutes les parties travaillent. Si UAT et QA testent des choses auxquelles le développeur n'a jamais pensé, il est temps de se pencher sur les exigences.

Je suis d'accord, il serait bien d'avoir un script de test unifié pour les développeurs, les testeurs et les utilisateurs professionnels, mais je crois que ce n'est pas possible sans beaucoup d'efforts, où le coût dépasse l'avantage.

La raison de la difficulté est que le contenu de la base de données dans chaque système est différent et les tests dépendent généralement fortement du contenu de la base de données. notre approche des "tests unifiés" était que chaque système obtient également une base de données de test supplémentaire et qu'il existe des scripts pour créer cette base de données à partir de zéro. les scripts de test s'exécutent sur la base de données de test où le contenu est standardisé.

Dans un monde parfait, les développeurs doivent avoir des tests unitaires (xUnit), des testeurs - des tests d'intégration automatisés (Selenium) et des utilisateurs professionnels - des tests d'acceptation (FIT). Ils peuvent avoir accès aux autres tests.

Cela dépend vraiment du projet. Dans certains cas, une équipe unifiée de test, d'assurance qualité et d'UAT qui se réunit pour discuter des résultats peut être très bénéfique. Il évite la duplication des efforts de test et garantit que toutes les parties ont une compréhension plus claire des besoins de l'entreprise via les scripts UAT. D'un autre côté, en fonction de la complexité du projet, il peut être plus judicieux d'avoir une QA approfondie des entrées et des sorties avant de tester des exemples commerciaux. Pour le développement de systèmes locaux, un contrôle qualité initial serait indispensable avant l'acceptation par l'utilisateur. Pour les implémentations prêtes à l'emploi, une équipe de test unifiée serait la plus logique.