Dans le développement agile, qui devrait écrire les cas de test? [fermé]

https://stackoverflow.com/questions/194790

10-07-2019
|

Question

Notre équipe dispose d’un système de tâches dans lequel nous publions de petites tâches incrémentielles assignées à chaque développeur.

Chaque tâche est développée dans sa propre branche, puis chaque branche est testée avant d'être fusionnée avec le tronc.

Ma question est la suivante: une fois la tâche terminée, qui doit définir les scénarios de test à exécuter pour cette tâche?

Idéalement, je pense que le développeur de la tâche lui-même convient le mieux, mais les développeurs me répugnent beaucoup, car ils pensent que c'est une perte de temps ou qu'ils n'aiment tout simplement pas le faire.

La raison pour laquelle je n'aime pas que les gens de mon QA le fassent, c'est parce que je n'aime pas l'idée qu'ils créent leur propre travail. Par exemple, ils peuvent laisser de côté des tâches qui demandent trop de travail et ne pas connaître les détails techniques nécessaires.

Mais de la même manière, les développeurs qui effectuent les scénarios de test ont la possibilité d’omettre certains éléments qui, à leur avis, risquent de se présenter. (même inconsciemment peut-être)

En tant que chef de projet, j'ai moi-même écrit les scénarios de test pour chaque tâche, mais mon temps est compté et je souhaite changer cela.

Des suggestions?

EDIT: Par cas de test, j'entends la description des tâches d'assurance qualité individuelles devant être effectuées dans la branche avant de les fusionner avec le tronc. (Boîte noire)

La solution

L'équipe.

Si un défaut parvient à un client, c'est l'erreur de l'équipe. Par conséquent, l'équipe doit être écrire des cas de test pour s'assurer que les défauts ne parviennent pas au client.

Le responsable de projet doit comprendre le domaine mieux que quiconque dans l'équipe. Leur connaissance du domaine est vital pour avoir des cas de test qui ont un sens pour le domaine. Ils devront fournir des exemples d'entrées et répondre aux questions sur les attentes concernant les entrées invalides. Ils doivent au moins fournir le scénario de test "chemin heureux".
Les développeurs connaissent le code. Vous suggérez que le développeur est peut-être le mieux à la tâche, mais que vous recherchez des cas de test boîte noire. Tous les tests proposés par un développeur sont des tests de boîte blanche. C'est l'avantage de permettre aux développeurs de créer des scénarios de test: ils savent où se trouvent les coutures dans le code.

Les bons développeurs viendront également au Premier ministre avec des questions "Que devrait-il se passer quand ...?" - chacun de ceux-ci est un cas de test. Si la réponse est complexe " Si a , alors x , mais si b , puis y , sauf le jeudi " - il existe plusieurs cas de test.
Les testeurs (QA) savent comment tester un logiciel. Les testeurs sont susceptibles de proposer des cas de test auxquels le PM et les développeurs ne penseraient pas - c'est pourquoi vous avez des testeurs.

Autres conseils

Je pense que le gestionnaire de projet ou l'analyste métier devrait écrire ces cas de test.
Ils doivent ensuite les remettre à la personne chargée de l’assurance qualité pour qu’ils développent et testent.

De cette façon, vous ne garantissez aucun écart manquant entre la spécification et ce qui est réellement testé et livré.

Le développeur ne devrait absolument pas le faire, car il testera ses tests unitaires. Donc c'est une perte de temps.

De plus, ces tests trouveront des erreurs que le développeur ne trouvera jamais, car elles sont probablement dues à une incompréhension dans les spécifications, à une fonctionnalité ou à un itinéraire du code n'ayant pas été réfléchi et implémenté correctement.

Si vous pensez que vous ne disposez pas de suffisamment de temps pour cela, engagez quelqu'un ou promouvez quelqu'un à ce poste, car il est essentiel de fournir un excellent produit.

Nous avons expérimenté l’appariement du développeur avec une personne responsable de l’assurance qualité avec de très bons résultats. Ils se sont généralement "tenus honnêtes les uns les autres" et, comme le développeur disposait de tests unitaires pour gérer le code, il était déjà assez au courant des modifications. Le responsable de l'assurance qualité ne l'a pas fait, mais il l'a abordé du côté de la boîte noire. Tous deux ont été tenus responsables de leur exhaustivité. Une partie du processus de révision en cours a permis de déceler les défaillances des tests unitaires. Par conséquent, je ne savais pas trop d'incidents où quelqu'un évitait délibérément d'écrire un test X car cela prouverait probablement l'existence d'un problème.

J'aime l’idée de couplage dans certains cas et pense que cela a plutôt bien fonctionné. Cela ne fonctionnera peut-être pas toujours, mais le fait d’interagir entre ces joueurs de différentes régions a permis d’éviter la mentalité qui consiste à «jeter par-dessus le mur» qui se produit souvent.

Quoi qu'il en soit, j'espère que cela vous sera utile.

De par notre expérience passée, nous avons eu beaucoup de chance de définir des tests à différents niveaux pour tester des choses légèrement différentes:

1er niveau: au niveau du code / de la classe, les développeurs doivent écrire des tests d'unité atomique. Le but est de tester autant que possible des classes et des méthodes individuelles. Ces tests doivent être exécutés par les développeurs au fur et à mesure qu'ils codent, probablement avant l'archivage du code dans le contrôle de source, et par un serveur à intégration continue (automatisé), le cas échéant.

2ème niveau: au niveau de l'intégration des composants, demandez aux développeurs de créer des tests unitaires, mais testant l'intégration entre les composants. Le but n'est pas de tester des classes et des composants individuels, mais de tester leur interaction. Ces tests doivent être exécutés manuellement par un ingénieur d'intégration ou automatisés par un serveur à intégration continue, le cas échéant.

3ème niveau: au niveau de l'application, demandez à l'équipe d'assurance qualité d'exécuter ses tests système. Ces cas de test doivent être basés sur les hypothèses métier ou les documents d'exigences fournis par un chef de produit. Fondamentalement, testez comme si vous étiez un utilisateur final, réalisez les tâches que les utilisateurs finaux devraient pouvoir effectuer, conformément aux exigences documentées. Ces cas de test doivent être écrits par l’équipe d’assurance qualité et les chefs de produits qui (supposément) savent ce que le client veut et comment il est attendu qu’il utilise l’application.

Je pense que cela fournit un très bon niveau de couverture. Bien entendu, les niveaux 1 et 2 ci-dessus devraient idéalement être exécutés avant d'envoyer une application construite à l'équipe d'assurance qualité. Bien sûr, vous pouvez l’adapter à votre modèle d’entreprise, mais cela a plutôt bien fonctionné lors de mon dernier emploi. Notre serveur d'intégration continue enverrait un courrier électronique à l'équipe de développement si l'un des tests unitaires échouait également au cours du processus de construction / d'intégration, au cas où quelqu'un oublierait d'exécuter ses tests et commettrait du code erroné dans l'archive source.

"Les développeurs qui pensent que c'est une perte de temps ou qu'ils n'aiment tout simplement pas le faire" Puis récompensez-les pour cela. Quelle ingénierie sociale est nécessaire pour les amener à créer des cas de test?

QA peut-il examiner le code et les cas de test et prononcer "Couverture insuffisante - Plus de cas". Si tel est le cas, alors le programmeur qui a "suffisant" la couverture sera tout de suite le Big Kahuna.

Donc, ma question est la suivante: une fois la tâche terminée, qui doit définir l’objectif de "suffisant" cas de test pour cette tâche? Une fois que vous savez "assez", vous pouvez charger les programmeurs de remplir "suffisamment". et QA chargé de veiller à ce que "suffisamment" le test est fait.

Trop difficile à définir "assez" Intéressant. C’est probablement la cause première du conflit avec les programmeurs. Ils pourraient penser que c'est une perte de temps, car ils en ont déjà assez "suffisamment". et maintenant, quelqu'un dit que cela ne suffit pas.

les personnes responsables de l'assurance qualité, conjointement avec le "client", doivent définir les scénarios de test pour chaque tâche [nous mélangeons vraiment la terminologie ici], et le développeur doit les écrire. d'abord!

La raison pour laquelle je n'aime pas que les gens de mon QA le fassent, c'est parce que je n'aime pas l'idée qu'ils créent leur propre travail. Par exemple, ils risquent de laisser de côté des tâches qui demandent trop de travail et d’ignorer les détails techniques nécessaires.

Oui, vous devez avoir plus de confiance dans votre service d'assurance qualité, ou dans un meilleur. Imaginez que vous ayez dit: «Je n'aime pas que mes développeurs développent des logiciels. Je n'aime pas l'idée qu'ils créent leur propre travail. "

En tant que développeur, je sais que la rédaction de mes propres tests comporte des risques. Cela ne veut pas dire que je ne fais pas ça (surtout si je fais du TDD), mais je ne me fais aucune illusion quant à la couverture des tests. Les développeurs vont écrire des tests qui montrent que leur code fonctionne comme ils le pensent. Peu de gens vont écrire des tests qui s’appliquent à la véritable analyse de rentabilisation.

Le test est une compétence et, espérons-le, votre service d'assurance qualité, ou du moins ses responsables, maîtrisera bien cette compétence.

Sélectionnez (pas seulement au hasard) un ou deux testeurs et laissez-les écrire les scénarios de test. La revue. Il peut également être utile si un développeur travaillant avec une tâche examine les cas de test de la tâche. Encouragez les testeurs à suggérer des améliorations et des ajouts aux ensembles de tests - parfois, les gens ont peur de réparer ce que le patron a fait. De cette façon, vous pourriez trouver quelqu'un qui est bon en conception de test.

Informez les testeurs des détails techniques. Je pense que tous les membres d’une équipe agile devraient avoir un accès en lecture au code et à toute la documentation disponible. La plupart des testeurs que je connais savent lire (et écrire) du code, ils pourraient donc trouver les tests unitaires utiles, voire même les étendre. Assurez-vous que les concepteurs de test obtiennent des réponses utiles des développeurs, s’ils ont besoin de savoir quelque chose.

Je suggérerais que quelqu'un d'autre examine les cas de test avant la fusion du code pour garantir la qualité. Cela peut signifier qu'un développeur néglige le travail d'un autre développeur, mais cette deuxième série d'yeux peut attirer l'attention sur quelque chose qui n'a pas été capturé initialement. Les cas de test initiaux peuvent être réalisés par tout développeur, analyste ou responsable, et non par un testeur.

L’assurance qualité ne devrait pas écrire les cas de test car il peut s’agir de situations dans lesquelles le résultat attendu n’a pas encore été défini. À ce stade, il peut être difficile d’avoir un arbitre entre l’assurance qualité et le développement si chaque partie pense que son interprétation est la même. le bon. C’est quelque chose que j’ai vu maintes fois et que j’aimerais que cela ne se produise pas aussi souvent que cela se produit.

Je décompose vaguement mes tests en "développeur". tests et "client" des tests, ces derniers étant des "tests de réception". Les premiers sont les tests que les développeurs écrivent pour vérifier que leur code fonctionne correctement. Ces derniers sont des tests que autre que les développeurs écrivent pour s’assurer que le comportement correspond à la spécification. Les développeurs ne doivent jamais écrire les tests d'acceptation, car leur création du logiciel qu'ils testent suppose qu'ils ont bien agi. Ainsi, leurs tests d'acceptation vont probablement affirmer ce que le développeur savait déjà être vrai.

Les tests d'acceptation doivent être régis par les spécifications. S'ils sont écrits par le développeur, ils seront pilotés par le code et donc par le comportement actuel, et non par le comportement souhaité.

Le Canon Agile est que vous devez disposer d'au moins deux couches de tests: les tests de développeur et les tests de client.

Les

tests de développeur sont écrits par les mêmes personnes que celles qui écrivent le code de production, de préférence à l'aide du développement piloté par les tests . Ils aident à proposer une conception bien découplée et veillent à ce que le code donne les résultats escomptés, même après une refactorisation.

Les

tests client sont spécifiés par le client ou son mandataire. En fait, ils constituent la spécification du système et doivent être écrits de manière à ce qu'ils soient à la fois exécutables (entièrement automatisés) et et compréhensibles par les gens d'affaires. Souvent, les équipes trouvent le moyen pour le client de même les écrire , avec l'aide de personnes chargées de l'assurance qualité. Cela devrait se produire pendant ou même avant que la fonctionnalité soit développée.

Idéalement, la seule tâche que le contrôle qualité puisse effectuer juste avant la fusion consiste à appuyer sur un bouton pour exécuter tous les tests automatisés et à effectuer des tests exploratoires supplémentaires (= sans script). Vous voudrez également exécuter ces tests après la fusion pour vous assurer que l'intégration des modifications n'a pas cassé quelque chose.

Un scénario de test commence en premier dans la fiche récit.

Le but des tests est de conduire les défauts à gauche (plus tôt dans le processus de développement logiciel quand ils sont moins chers et plus rapides à réparer).

Chaque fiche d’histoire doit inclure des critères d’acceptation. Le Product Owner s'associe à l'analyste de solution pour définir les critères d'acceptation de chaque récit. Ce critère est utilisé pour déterminer si le but d'une carte de scénario a été atteint.

Les critères d'acceptation de la fiche d'historique détermineront quels tests unitaires automatisés doivent être codés par les développeurs lors de leur développement piloté par les tests. Il pilotera également le test fonctionnel automatisé mis en œuvre par les testeurs automatiques (et peut-être avec l'assistance des développeurs si des outils tels que FIT).

De manière tout aussi importante, les critères d'acceptation guideront les tests de performances automatisés et peuvent être utilisés lors de l'analyse du profilage de l'application par les développeurs.

Enfin, le test d'acceptation des utilisateurs sera déterminé par les critères d'acceptation des fiches de récit et devra être conçu par le partenaire et / ou les utilisateurs. Suivez ce processus et vous libérerez probablement avec zéro défaut.

J'ai rarement entendu parler ou vu des chefs de projet écrire des scénarios de test, sauf dans les petites équipes. Dans toute grande application logicielle complexe, il faut un analyste que vraiment connaisse l’application. J'ai travaillé dans une société de crédit hypothécaire en tant que PM - devais-je comprendre le crédit subprime, les taux d'intérêt, etc.? Peut-être à un niveau superficiel, mais de vrais experts devaient s'assurer que tout fonctionnait bien. Mon travail consistait à maintenir l'équipe en bonne santé, à protéger les principes agiles et à rechercher de nouvelles opportunités de travail pour mon équipe.

L’analyste système doit vérifier tous les cas de test et sa relation correcte avec les cas d’utilisation. De plus, l'analyste doit effectuer l'UAT final, qui pourrait également être basé sur des cas de test. Ainsi, l'analyste et le responsable de la qualité procèdent à une sorte d'examen par les pairs.

La qualité consiste à examiner les cas d'utilisation pendant qu'il construit des cas de test, et l'analyste examine les cas de test une fois qu'ils ont été écrits et pendant qu'il exécute l'UAT.

Bien sûr, BA est l’expert du domaine, pas du point de vue technique. BA comprend les exigences et les scénarios de test doivent être mis en correspondance avec les exigences. Les développeurs ne doivent pas être les personnes écrivant les cas de test à tester par rapport à leur code. QA peut écrire les étapes de test de détail par exigence. Mais la personne qui écrit l'exigence devrait dicter ce qui doit être testé. Qui écrit réellement les cas de test, je m'en fous trop, tant que les cas de test peuvent être retracés aux exigences. Je pense qu'il est logique que BA guide l'orientation ou la portée des tests et que QA rédige les plans de tests granulaires.

Nous devons évoluer à partir du "c'est la mentalité qui a été faite ou qui devrait l'être" " il échoue et échoue continuellement. Le meilleur moyen de résoudre le problème d'écriture de plan / test de test est que les cas de test doivent être écrits dans le document d'exigences de waterfall ou la user story dans l'agile au moment de l'écriture de ces reqs / user stories. De cette façon, il n’ya aucun doute sur ce qui doit être testé et les équipes d’assurance qualité et d’UAT peuvent exécuter le ou les cas de test et se concentrer sur les tests et la résolution des défauts.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow