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

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?

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.

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.

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.

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 .

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.

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.

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.

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.

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.