De test unitaires et responsabilité des testeurs, développeurs, clients [fermé]

Question

Il semble donc que beaucoup de gens jouent le jeu de blâme autour de là où je travaille, et il soulève une question intéressante.

knowns:

L'équipe Exigences écrit exigences pour le produit. Les développeurs créent leurs propres tests unitaires en fonction des besoins. l'équipe d'essai crée des conditions de test, la conception des tests et cas de test en fonction des besoins.

Produit libéré si et seulement si X% des cas de test de l'équipe de test passe.

Après delivery fait des tests d'acceptation -.> L'équipe de réponse client reçoit des bugs sur le terrain, et permet à l'équipe d'essais au courant de ces problèmes

Question:

Si le client finit par le dépôt d'un grand nombre de défauts, qui est à blâmer? Est-ce l'équipe d'essai pour ne pas couvrir les? Ou est-ce l'équipe des exigences pour ne pas écrire de meilleures conditions? Et comment améliorer le système?

Answer 1

La mention « Produit publié si et seulement si X% des cas de test de l'équipe de test passe » me dérange vraiment. L'équipe voudra peut-être envisager d'avoir de meilleurs critères de libération qui est fermée sur plus que les taux de réussite des tests. Par exemple, sont les scénarios connus, compris, ont représenté (et testé)? Certainement pas tous les bugs seront corrigés, mais sont ceux qui ont été reportées fixes ou non été correctement triés? Avez-vous atteint vos objectifs de test de stress et de performance? Avez-vous menace modélisé et représenté atténuations aux menaces potentielles? Avoir un montant x de clients (interne / externe) déployé construit et fourni une rétroaction avant la libération (à savoir « dogfood »)? Est-ce que les développeurs comprennent les bugs à venir sur le terrain et les testeurs pour créer des tests unitaires de régression? L'équipe comprend les exigences ces bugs à venir pour voir pourquoi les scénarios ne sont pas comptabilisés? Y at-il des points d'intégration entre les principales caractéristiques qui ne sont pas pris en compte dans les spécifications, le développement ou le test?

Quelques suggestions à l'équipe serait d'abord faire un post-mortem sur les problèmes rencontrés et comprendre où il a cassé, et nous nous efforçons de faire de la qualité en amont autant que possible. Assurez-vous que l'équipe des besoins, développeurs et testeurs communiquent souvent et bien tout au long de la planification, dev, et le cycle de test pour rendre tout le monde est sur la même page et sait qui fait quoi. Vous seriez étonné de voir quel point la qualité des produits peut gagner quand les gens parlent en fait de l'autre au cours du développement!

Answer 2

Les bugs peuvent entrer dans le système à la fois les exigences et les étapes de développement. L'équipe des exigences pourrait faire des erreurs ou trop simplifier les hypothèses lors de la création des exigences, et les développeurs pourraient mal interpréter les exigences ou leurs propres hypothèses.

Pour améliorer les choses, le client doit signer les exigences avant produit de développement, et devrait participer, au moins dans une certaine mesure, dans le développement de la surveillance pour assurer que les choses sont sur la bonne voie.

Answer 3

La première question dans mon esprit serait, « comment les défauts empilent contre les exigences? »

Si l'exigence lit, « bouton OK doit être bleue » et le défaut est « bouton OK est vert », je blâme le développement et le test - clairement, ni lire les exigences. D'autre part, si la plainte est «le bouton OK est pas jaune », clairement, il y avait un problème avec la collecte des besoins ou votre processus de changement de contrôle.

Il n'y a pas de réponse facile à cette question. Un système peut avoir un grand nombre de défauts avec la propagation de la responsabilité entre toutes les personnes impliquées dans le processus - après tout, est juste une autre façon un « défaut » de dire « les attentes des clients non satisfaits ». Les attentes, en elles-mêmes, ne sont pas toujours correctes.

Answer 4

« Produit libéré si et seulement si X% des cas de test de l'équipe de test passe »

- est l'un des critères de mise en liberté. Dans ce cas, « la couverture des tests » dans TCs écrit est très important. Il a besoin d'un bon examen de toutes les fonctionnalités que TCs ou scénario est manqué ou non. Si quelque chose a manqué à TCs il pourrait possible de trouver des bugs que certains besoins ne sont pas couverts dans les cas de test.

Il faut aussi des tests ad hoc ainsi que des tests exploratoires pour trouver des bugs découvrir dans TCs. Et il a aussi besoin de définir des « critères de sortie » pour les tests.

Si trouve tout bug / client déserter / client, il est nécessaire d'enquêter comme: i) Quel type de bug est trouvé? ii) Y at-il un cas de test écrit sur ce sujet? iii) En cas de cas de test (s) au sujet qui a exécuté correctement? iv) Si elle est absente dans TCs pourquoi il a manqué? et ainsi de suite

Après la décision d'enquête peut être prise qui devrait être blâmé. S'il est très simple et bug / défaut aux yeux ouverts, sans aucun doute les testeurs devraient être blâmés.