Si vous exécutez un projet utilisant BDD avec une couverture à 100% des user stories avec des tests d'acceptation automatisés, quel serait le rôle d'un testeur / responsable de l'assurance qualité?
Je suppose que j'imagine que les développeurs écriraient les tests d'acceptation en collaboration avec le propriétaire du produit, faites-moi savoir si cela semble être une hypothèse stupide.
Réponses:
Je suis peut-être trop démodé, mais même les techniques de développement ou de traitement les plus modernes ne peuvent pas remplacer un autre ensemble d'yeux, des yeux frais, avant de proposer un produit à votre client.
Même si votre produit est simplement une API pour un autre développeur, vous pouvez utiliser l'AQ pour penser en tant qu'utilisateur de l'API, en fournissant des scénarios de test / utilisation auxquels vous ou votre client n'avez pas pensé à l'avance.
Si votre produit est lourdement basé sur l'interface utilisateur, vous voulez certainement qu'une autre personne (ce n'est pas vous ou quelqu'un de votre équipe) regarde le résultat final avant de l'envoyer au client.
Comme tout autre mot à la mode dans notre industrie, BDD - même avec une couverture à 100% - n'est pas une solution miracle .
Une couverture à 100% n'est pas la même chose qu'à 100%.
Je verrais une personne QA dans un projet ATDD comme quelqu'un qui aiderait à écrire les tests et à effectuer les autres types de tests qui existent toujours. Ie UI Testing, tests de destruction et tests de charge / contrainte.
Mais je n'ai jamais élaboré de projet ATDD.
Le travail de QA est de casser l'application, le travail des développeurs est de ne pas la casser. Par conséquent, ils rédigent leurs tests sous un angle différent. Par exemple, les développeurs écrivent des tests pour voir si le comportement attendu se produit, QA écrit des tests pour voir ce qui se passe lorsque les utilisateurs font quelque chose que le développeur ne considérerait jamais comme le ferait l'utilisateur. De plus, les développeurs interprètent souvent mal les exigences et les tests d'AQ sont détectés lorsque leur interprétation est différente de ce que le développeur pensait que cela signifiait, puis se réunissent avec les parties prenantes du projet pour déterminer quelle est la bonne interprétation. Les tests écrits par les développeurs qui ont écrit le code ont souvent de gros angles morts car le développeur avait un gros angle mort. Par exemple, il pourrait tester ce qui se passe 97% du temps, mais pas les cas marginaux.
Chez un ancien employeur, le rôle de QA n'était pas de tester le produit mais de garantir que les développeurs faisaient essentiellement ce qu'ils avaient dit qu'ils allaient faire en ce qui concerne les tests d'acceptation définis précédemment qui étaient définis par QA.
Le propriétaire du produit, en revanche, n'avait absolument rien à voir avec les tests. S'occuper des tests à n'importe quel niveau à mon humble avis n'est pas le rôle du propriétaire du produit.
À un moment donné, vous devez avoir confiance en vos employés; les freins et contrepoids sont bons, mais vous ne devriez pas avoir à forcer une solution dans le cycle de développement qui, en réalité, ne concerne qu'un petit sous-ensemble de l'éthique de travail des employés.
Dans un monde parfait, je vois la collaboration avec dev et QA se formaliser avec la rédaction des tests d'acceptation de manière conjointe. L'AQ doit apporter un aspect différent à la table, tout comme l'équipe de développement. L'AQ doit avoir sa main dans la tarte à ses débuts et rester engagée tout au long du cycle. Le propriétaire du produit, d'autre part, devrait alors engager l'AQ pour comprendre ce qu'est l'état actuel du produit, les risques, etc. et se concentrer sur le produit de manière holistique; pas les nuances spécifiques qui composent le produit.
D'après mon expérience: nous utilisions le test unitaire pour couvrir plus de 90% du code. Il y avait aussi des tests d'intégration et des builds toutes les heures. jEffectuer des tests de BDD.
Rôle QA: - adopter des user stories pour les tests - écrire du code derrière les étapes - tester l'exploration en utilisant le plug-in RestClient pour IDEA (ainsi nous avons trouvé quelques bugs majeurs)
Une partie du BDD applique l'approche des 3 Amigos où les parties prenantes collaborent pour produire les critères d'acceptation. QA / Dev peut écrire le code d'étape pour exécuter des scénarios en tant que tests d'acceptation. Quelle est la valeur de l'AQ pour exécuter manuellement les mêmes tests d'acceptation qu'un outil BDD exécutera automatiquement? La valeur ajoutée de QA est de valider ces tests d'acceptation et d'effectuer des tests exploratoires manuels en dehors des tests d'acceptation scriptés. La duplication donnera généralement le même résultat.
Les développeurs ne réécrivent pas les exigences et les spécifications, QA ne réécrit pas le code de l'application ... il est possible que QA n'ait pas à effectuer les mêmes tests de script que les développeurs exécutent en tant que tests d'acceptation. Il est temps pour les développeurs de porter une partie du chapeau QA!