Un développeur doit-il également agir en tant que testeur? [fermé]


60

Nous sommes une équipe Scrum composée de 3 développeurs, d'un concepteur, du scrum master et du propriétaire du produit. Cependant, nous n'avons pas de testeur officiel dans notre équipe. Un problème qui nous préoccupe toujours, c'est que, tester l'application et réussir ces tests ainsi que la suppression des bogues ont été définis comme l'un des critères permettant de considérer un PBI (Product Backlog Item) comme tel.

Mais le problème est que, peu importe combien nous essayons (3 développeurs et 1 concepteur) de tester l'application et les cas d'utilisation mis en œuvre, certains bogues ne sont toujours pas vus et ruinent notre présentation ( loi de Murphy ) aux parties prenantes.

À titre de solution, nous avons recommandé à la société d’engager un nouveau testeur. Quelqu'un dont le travail serait tester et tester seulement. Un testeur professionnel officiel.

Cependant, le problème est que, Scrum Master et les parties prenantes estiment qu'un développeur (ou un concepteur) devrait également être un testeur.

Ont-ils raison? Est-ce que les développeurs (et les concepteurs) doivent aussi être des testeurs?


1
Doublon possible de programmers.stackexchange.com/questions/100637/… , bien que cela soit demandé du point de vue opposé.
Adam Lear

Dans l'équipe Scrum dans laquelle je suis entré, chacun testait l'application pour smartphone ou tablette et tous ont été d'une grande aide.
ott--

Les écrivains ont besoin d'un éditeur.
JeffO

Réponses:


59

Ex ante: Il semble y avoir beaucoup de confusion sur ce qui est considéré comme tester ce qui ne l’est pas. Bien sûr, chaque développeur doit tester son code au fur et à mesure qu'il le crée, il doit vérifier qu'il fonctionne. Il / elle ne peut pas le donner à un testeur avant qu'il / elle pense que c'est fait et assez bon. Mais les développeurs ne voient pas tout. Ils pourraient ne pas reconnaître les bugs. Ces bogues ne peuvent être trouvés que plus tard dans le cycle de développement, lorsque des tests approfondis sont effectués. La question est de savoir si les développeurs doivent effectuer ce type de test ou non, et à mon humble avis, cela doit être examiné du point de vue du chef de projet:

Les développeurs peuvent être des testeurs, mais ils ne devraient pas être des testeurs . Les développeurs ont tendance à éviter involontairement / inconsciemment d’utiliser l’application d’une manière qui pourrait la casser. C'est parce qu'ils l'ont écrit et le testent principalement de la façon dont il devrait être utilisé.

Un bon testeur, par contre, tente de torturer l'application. Son intention première est de le casser. Ils utilisent souvent l'application d'une manière que les développeurs n'auraient pas imaginée. Ils sont plus proches des utilisateurs que des développeurs et ont souvent une approche différente pour tester un flux de travail.

En outre, l'utilisation de développeurs en tant que testeurs augmente les coûts de développement et ne profite pas autant à la qualité du produit qu'à un testeur dédié. Je ne laisserais pas les développeurs confronter leurs travaux à des tests croisés quand je peux le faire mieux faire par un testeur pour pas cher. Seulement si la boucle de rétroaction entre développeurs et testeurs devenait trop chère, je demanderais aux développeurs d'analyser le code de chacun, mais d'après mon expérience, c'est rarement le cas et cela dépend fortement du processus.

Cela ne signifie pas qu'un développeur doit être négligent et tout laisser au testeur. Le logiciel doit être sauvegardé par des tests unitaires et les erreurs techniques doivent être réduites au minimum avant de confier le logiciel au testeur. Pourtant, parfois, vous avez des solutions, des problèmes ou d’autres bogues qu’aucun développeur ne pourrait prévoir, c’est bien. En outre, les tests d'intégration devraient être effectués principalement par les développeurs. L'objectif principal du testeur est de vérifier que les exigences sont remplies.

Dans une si petite équipe (et également en fonction de la taille de l'application), je peux également voir le testeur dans un rôle hybride, écrire des tests unitaires et des tests d'interface utilisateur. Vous devriez certainement en engager un .

Mais plus important que le testeur sont les gels / branches réguliers. Ne présentez rien qui n'ait pas été correctement testé. Lorsque vous avez ajouté une fonctionnalité ou modifié quelque chose, tout ce qui l'entoure doit être vérifié à nouveau. Vous n'aurez qu'une mauvaise réputation si votre entreprise ne le fait pas. Ne libérez pas quelque chose d'instable. Lorsque le client souhaite disposer du logiciel à une date donnée, arrêtez de développer suffisamment tôt et testez-le correctement afin de disposer de suffisamment de temps pour corriger les bogues. Il est souvent préférable de refuser les demandes de fonctionnalités de dernière minute que de les mettre en œuvre de manière médiocre ou de les publier sans tests appropriés.


9
Fortement et fermement en désaccord ... Les développeurs peuvent être des testeurs extrêmement efficaces, mais le développeur d'une fonctionnalité ne doit PAS être également le testeur de la même fonctionnalité. De nombreuses petites équipes jouent les deux rôles, avec trois personnes travaillant sur trois fonctionnalités différentes, puis confiant les tests à l'un des trois autres développeurs. Cela fonctionne extrêmement bien lorsqu'une équipe ne dispose pas d'un testeur d'assurance qualité.
maple_shaft

5
@maple_shaft: À mon avis, il n'y a aucune excuse pour ne pas avoir de testeur. Tout projet produira une qualité supérieure avec un testeur dédié et les développeurs peuvent se concentrer sur le développement, le cas échéant. Demander aux développeurs de tester le code de chacun est une solution de fortune, même pour les petites équipes à mon humble avis. Vous devriez également lire l'article de Joel à ce sujet.
Falcon

3
Les développeurs peuvent être des testeurs - et un bon développeur connaît en réalité de nombreux endroits où le code peut être faible et sujet à la casse. Ne jamais demander aux gens de tester le code qu'ils ont conçu ou écrit - c'est inutile. Le code des autres peut être ok.
StasM

4
@deadalnix: Cela me laisse vraiment perplexe de savoir pourquoi les gens votent sans même lire et comprendre ma réponse. Pour citer moi-même: "Le logiciel doit être sauvegardé par des tests unitaires et les erreurs techniques doivent être réduites au minimum avant de confier le logiciel au testeur."
Falcon

2
"En revanche, un bon testeur tente de torturer l'application. Son intention première est de la casser." - Complètement en désaccord. J'ai un testeur qui essaie continuellement d'écraser le clavier ou de déborder des champs. Bien sûr, ce sont des bugs, mais une facture de 1 billion de milliards de dollars qui jette une erreur est tellement faible sur ma liste de choses à faire que de ne pas vous inscrire. Un GRAND testeur teste tous les scénarios que divers utilisateurs utiliseraient l'application. Un bon développeur s'assure que tous les chemins de code ont été testés et que l'application fonctionne lorsqu'elle est utilisée comme prévu.
Paul

42

Les développeurs peuvent être des testeurs - du code des autres développeurs.

Mais tester votre propre code n’est pas une bonne chose: les développeurs ont tendance à avoir des blocages sur leur propre code et ont donc de la difficulté à concevoir des tests complets ou appropriés.

Il y aura toujours des développeurs qui pensent qu’ils le font bien, mais généralement pas (et je sais que j’ai beaucoup d’angles aveugles).

Si vous POUVEZ VRAIMENT engager un testeur, demandez aux développeurs de se tester mutuellement, c'est-à-dire que si A écrit le code et effectue les tests unitaires, demandez à B d'examiner ces tests unitaires et de voir si d'autres éléments pourraient être ajoutés . Et demandez à B d’essayer de tester le code (en tant qu’utilisateur) et de signaler les défauts.

Ce n'est pas parfait, mais c'est mieux qu'un seul développeur qui essaie de tout faire.

Parfois, vos collègues peuvent très bien casser votre logiciel, car ils en profitent et s'en moquent bien - car ce n'est pas LEUR code.


2
Oh oui, bien sûr. Complètement d'accord. C'est juste que lorsque vous ne pouvez pas obtenir 100% de ce que vous voulez, vous pourriez avoir à vous contenter de moins. Vous savez que moins n'est pas si bon mais c'est mieux que rien.
Rapidement maintenant

4
Je suis généralement d'accord avec les tests croisés, mais sur certaines équipes qui introduiront des conflits. Certaines personnes aiment blâmer les autres ("mon truc marche, le tien pas, lol, je suis tellement meilleur que toi") et c'est inacceptable. J'ai été témoin de cela plusieurs fois. Le croisement ne devrait être fait qu'entre collègues qui se respectent. Dans mon équipe, j'ai présenté le développeur sans nom qui est tenu pour responsable de chaque bug afin d'éviter que quelqu'un ne perde la face. Les bugs sont sans nom, ils se produisent.
Falcon

5
+1, il est impossible de tester correctement votre propre code. C'est incroyable les tours que l'esprit peut jouer sur vous - vous serez sûr à 100% d'avoir codé et testé certaines fonctions et il faudra que quelqu'un d'autre vous montre qu'il ne fonctionne en réalité que dans des cas très étroits et qu'il en soit ainsi. soyez évident pour vous une fois montré - mais vous ne le verriez jamais vous-même. L'esprit utilise des raccourcis cognitifs, et les tester rendent impossible à la personne qui a conçu et développé le code de le tester correctement.
StasM

2
@StasM - d'accord, avec une petite réserve: j'ai constaté que si je revenais dans mon propre code des mois plus tard, je pouvais voir les erreurs et pouvoir mieux le tester de manière objective. Mais tester votre propre après avoir écrit est très difficile.
Rapidement maintenant

1
@Ben Aston: un développeur devrait toujours effectuer des tests unitaires, des tests d'intégration, etc. Mais pas exclusivement. Les angles morts ne disparaîtront pas simplement parce que vous le souhaitez.
Rapidement maintenant

11

Le journaliste devrait-il avoir tendance à écrire correctement? Je veux dire, c’est le travail des correcteurs et des éditeurs de trouver toutes les erreurs grammaticales.

Néanmoins, les journalistes fournissent eux-mêmes un correcteur orthographique. Néanmoins, le correcteur est une profession distincte et importante.

Il en va de même pour les développeurs et les testeurs, à l'exception du fait que l'AQ est une partie encore plus importante du développement. Même si vous êtes un bon développeur, vous n'avez pas le temps de tester minutieusement tous les cas de test, afin de couvrir tous les environnements, navigateurs et systèmes d'exploitation pris en charge par votre produit.

Si quelqu'un, en plus de développer, fait constamment ce travail également, cela signifie simplement un fait - il est un testeur à temps partiel.


10

peu importe combien nous essayons (3 développeurs et 1 concepteur) de tester l'application et les cas d'utilisation mis en œuvre, quelques bugs ne sont toujours pas vus et gâchent notre présentation ... aux parties prenantes.

Pensez à effectuer une "course contrôlée" pour un ou deux sprints, en suivant les efforts de développement et de test séparément. À la fin d'une telle analyse, analysez les données collectées pour déterminer le niveau d'effort que vous consacrez aux tests.

Si vous découvrez que les tests nécessitent beaucoup d’efforts, transmettez ces données à la direction - ce sera une preuve convaincante à l’ appui de votre demande (beaucoup plus convaincante qu’elle ne l’a actuellement).

Sinon (si vous trouvez que votre test prend peu de temps), songez à investir davantage d’efforts pour le faire mieux (ou à apprendre à le faire). Négociez les efforts supplémentaires que vous envisagez avec votre direction, car ils pourraient préférer engager un testeur à la place. :)


... nous avons recommandé à l'entreprise de faire appel à un nouveau testeur. Quelqu'un dont le travail serait tester et tester seulement. Un testeur professionnel officiel.

Cependant, le problème est que, Scrum Master et les parties prenantes estiment qu'un développeur (ou un concepteur) devrait également être un testeur.

Je dois admettre que la gestion de votre entreprise me semble très boiteuse. Je veux dire - d'accord, il peut être très difficile de savoir combien de testeurs conviendraient le mieux pour le projet, très bien.

Mais avoir au moins un testeur est une valeur sûre - vraiment drôle, ils hésitent à essayer, tout en se réclamant scrum / agile .


9

Nous avons eu des tests croisés entre deux développeurs après que le premier eut apporté des modifications à un écran de saisie. C'était à l'époque où notre testeuse régulière était en congé de maternité.

Il a fondamentalement modifié l’écran de liste de facturation utilisé par les utilisateurs pour sélectionner les factures avant d’agrandir pour effectuer des modifications via un bouton "Modifier". La liste originale a été jetée et une nouvelle grille a été insérée, avec filtrage, regroupement, tri et toutes sortes de fonctionnalités intéressantes.

Les tests se sont bien déroulés et ils ont transféré les modifications au client le lendemain. Deux semaines plus tard, le client appelle et dit: "Nous aimons vraiment le nouveau document que vous avez inséré, nous pouvons maintenant voir toutes sortes d'informations. Mais ... euh ... où allons-nous maintenant pour modifier les factures?" ?? "

Il s'avère que le développeur a décoché la case à cocher (pour la sélection) et le bouton d'édition. Comme les développeurs ont toujours double-cliqué pour sélectionner un élément, aucun d'entre eux n'a rien trouvé d'anormal ......

Les développeurs et les utilisateurs vivent dans des mondes différents. Il est préférable de faire des tests croisés que de faire tester son travail par le développeur, mais ce n'est pas tout à fait la même chose.


3
Je ne dirais pas "ils vivent dans des mondes différents", mais les gens ont des habitudes et un code de développeur fonctionnera s'il est utilisé par une personne ayant les mêmes habitudes. Je ne peux pas compter combien de fois je ne peux pas reproduire un bogue trouvé par un testeur, j'ai regardé par-dessus son épaule pendant qu'il reproduisait le bogue et m'a dit: "Waouh, je n'aurais jamais fait ce que tu viens de faire".
gnasher729

4

Comme d'autres l'ont déjà dit, les développeurs peuvent tester mutuellement le code de chacun (tests unitaires ou fonctionnels). Peut-être que votre Scrum Master et le propriétaire du produit peuvent vous aider pour les tests d'intégration, mais pour les tests d'acceptation des utilisateurs, vous devez vous assurer que vous obtenez beaucoup de commentaires de la tests effectués par le client - ce qui signifie que les déploiements fréquents qu'ils peuvent travailler avec la manière que les vrais utilisateurs font et une communication vraiment ouvert canal.


2

Vous devez concevoir en gardant à l’esprit la testabilité, mais si vous n’avez pas de testeur dédié, certaines choses risquent de glisser, car il n’ya pas assez d’heures dans la journée pour concevoir, mettre en œuvre et tester un logiciel.


2

Tester un logiciel est un travail professionnel à temps plein. Il faut un bon cerveau, du talent et beaucoup d'expérience pour devenir un bon testeur. Il est ridicule de supposer qu'un développeur de logiciel, aussi intelligent soit-il, peut s'approcher d'un testeur professionnel lorsque le test n'est qu'un petit élément de son travail quotidien.

En plus de cela, il y a le problème que le développeur de logiciels ne veut pas, inconsciemment, trouver des bogues.


1

Je suis d'accord avec leur point de vue que les développeurs / concepteurs devraient tester leur code, avec le cavaet que le concepteur / développeur qui a fait une section de code ne soit pas la seule série de "yeux" sur ce code avant de s'engager à vivre. Même si cela ne va pas tout prendre, cela vous aidera au moins à éviter l'aveuglement qui se crée lorsque vous testez et testez à nouveau votre propre code tout en se développant.

De la mention de cas d'utilisation, je suppose que vous utilisez également des outils de couverture de code? Si ce n'est pas le cas, cela pourrait aider à voir quel code pourrait ne pas être testé, et risquerait de générer des bogues inattendus dans certaines conditions.

Cela étant dit, si le volume de travail est suffisant ou si votre organisation est de taille décente, je conviens qu'un professionnel de l'assurance qualité est nécessaire, cela aiderait à cibler un peu plus les rôles de chacun, et ils pourraient également voir s'il existe des tendances en ce qui concerne est manqué, et plus important encore, comment y remédier.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.