Un développeur doit-il également agir en tant que testeur?
Nous sommes une équipe Scrum de 3 développeurs, 1 designer, le Scrum Master et le propriétaire du produit. Cependant, nous n'avons pas de testeur officiel dans notre équipe. Un problème qui est toujours avec nous, c'est que, tester l'application et réussir ces tests et supprimer les bogues a été défini comme l'un des critères pour considérer un PBI (Product Backlog Item) comme terminé.
Mais le problème est que, peu importe combien nous (3 développeurs et 1 concepteur) essayons de tester l'application et les cas d'utilisation implémentés, certains bogues ne sont toujours pas vus et ruinent notre présentation ( loi de Murphy ) pour les parties prenantes.
Comme remède, nous avons recommandé à l'entreprise d'embaucher un nouveau testeur. Quelqu'un qui aurait du travail ferait des tests, et des tests seulement. Un testeur professionnel officiel.
Cependant, le problème est que, Scrum Master et les parties prenantes pensent qu'un développeur (ou un concepteur) devrait également être un testeur.
Ont-ils raison? Les développeurs (aussi les concepteurs) devraient-ils également ê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 pendant qu'il le crée, il doit vérifier qu'il fonctionne. Il/elle ne peut pas le remettre à 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 bogues. Ces bogues ne peuvent être détectés plus tard dans le cycle de développement que 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 manière dont il devrait être utilisé.
Un bon testeur d'autre part, essaie de torturer l'application. Son intention première est de la 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 du développeur et ont souvent une approche différente pour tester un flux de travail.
De plus, l'utilisation de développeurs comme testeurs augmente les coûts de développement et ne profite pas autant à la qualité du produit que d'avoir un testeur dédié. Je ne laisserais pas les développeurs contre-tester leurs travaux quand je peux le faire mieux par un testeur pour pas cher. Seulement si la boucle de rétroaction entre les développeurs et les testeurs devenait trop chère, les développeurs se croiseraient le code les uns des autres, mais selon 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 bâclé et laisser tout au testeur. Le logiciel doit être sauvegardé par des tests unitaires et les erreurs techniques doivent être réduites au minimum avant de remettre le logiciel au testeur. Toujours , parfois vous avez corrigé ici, cassé des problèmes ou d'autres bogues qu'aucun développeur ne pouvait prévoir, c'est ok. De plus, les tests d'intégration devraient être effectués principalement par les développeurs. Le principal objectif 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, en écrivant des tests unitaires et des tests d'interface utilisateur. Vous devriez certainement en louer un.
Mais plus important que le testeur sont les gels/branches réguliers. Ne présentez rien qui n'a 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'obtiendrez une mauvaise réputation que si votre entreprise ne le fait pas. Ne libérez pas quelque chose d'instable. Lorsque le client souhaite disposer du logiciel à une certaine date, alors arrêtez de développer suffisamment tôt et testez-le correctement, afin que vous ayez 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 implémenter mal ou de les publier sans tests appropriés.
Les développeurs peuvent être des testeurs - du code d'autres développeurs.
Mais tester votre propre code n'est pas une bonne chose - les développeurs ont tendance à avoir des blocages mentaux sur leur propre code, et ont donc du mal à concevoir des tests complets ou appropriés.
Il y aura toujours des développeurs qui pensent qu'ils le font bien, mais ce n'est généralement pas le cas (et je sais que j'ai de nombreux angles morts).
Si vous VOULEZ VRAIMENT embaucher un testeur, puis demandez aux développeurs de se tester mutuellement - c'est-à-dire, si A écrit le code et fait des tests unitaires, puis demandez à B de regarder ces tests unitaires et de voir s'il y a d'autres choses à ajouter . Et demandez à B d'essayer et 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 essayant de tout faire.
Parfois, vos collègues peuvent vraiment bien casser votre logiciel, car ils en profitent et s'en moquent tellement - parce que ce n'est pas LEUR code.
Le journaliste doit-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 une vérification orthographique par eux-mêmes. Néanmoins, le correcteur est une profession distincte et importante.
Il en va de même pour les développeurs et les testeurs, sauf que le QA est une partie encore plus importante du développement. Même si vous êtes un bon développeur, vous n'avez tout simplement pas le temps de tester soigneusement tous les cas de test, pour couvrir tous les environnements, navigateurs et systèmes d'exploitation pris en charge par votre produit.
Si quelqu'un, en plus de se développer, de faire constamment ce travail aussi, cela signifie simplement un fait simple - il est un testeur à temps partiel.
peu importe combien nous (3 développeurs et 1 concepteur) essayons de tester l'application et les cas d'utilisation implémentés, certains bugs ne sont toujours pas vus et ruinent notre présentation ... aux parties prenantes.
Envisagez d'effectuer une "course contrôlée" pour un sprint ou deux, en suivant séparément les efforts de développement et de test. À la fin d'une telle analyse, analysez les données collectées pour savoir combien d'efforts vous consacrez aux tests.
Si vous découvrez que les tests demandent beaucoup d'efforts, transmettez ces données à la direction - ce sera une preuve convaincante soutenant votre demande (beaucoup plus convaincante que vous ne l'avez fait) maintenant).
Sinon (si vous trouvez que vos tests prennent peu de temps), envisagez d'investir des efforts supplémentaires pour mieux le faire (ou d'apprendre à le faire). Négociez cet effort supplémentaire que vous prévoyez avec votre direction - car ils préféreront peut-être engager un testeur à la place. :)
... nous avons recommandé à l'entreprise d'embaucher un nouveau testeur. Quelqu'un qui aurait du travail ferait des tests, et des tests seulement. Un testeur professionnel officiel.
Cependant, le problème est que, Scrum Master et les parties prenantes pensent qu'un développeur (ou un concepteur) devrait également être un testeur.
Je dois admettre que la gestion de votre entreprise me semble assez boiteuse. Je veux dire - ok, il peut être vraiment difficile de savoir combien de testeurs seraient les meilleurs pour le projet, très bien.
Mais avoir au moins un testeur est juste une valeur sûre - vraiment drôle qu'ils hésitent pour l'essayer, tout en se revendiquant scrum/ agile.
Eh bien, nous avons eu deux tests croisés pour les développeurs après que le premier ait apporté des modifications à un écran d'entrée. C'est à ce moment que notre testeuse régulière était en congé de maternité.
Il a fondamentalement changé un écran de liste de factures que les utilisateurs utilisaient pour sélectionner les factures avant de zoomer pour effectuer des modifications via un bouton "Modifier". La liste d'origine a été supprimé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 téléchargé les modifications sur le client le lendemain. Deux semaines plus tard, le client appelle et dit "Nous aimons vraiment le nouveau truc que vous mettez, nous pouvons voir toutes sortes d'informations maintenant. Mais ... euh ... où allons-nous pour éditer les factures maintenant? ?? "
Il s'avère que le développeur a retiré la case à cocher (pour la sélection) et le bouton d'édition et puisque les développeurs ont toujours double-cliqué pour sélectionner un élément de toute façon, aucun d'eux n'a trouvé quelque chose de mal avec lui ......
Les développeurs et les utilisateurs vivent dans des mondes différents, avoir des tests croisés est mieux que d'avoir le développeur tester son propre travail, mais ce n'est pas tout à fait la même chose.
Comme d'autres l'ont dit ici, les développeurs peuvent effectuer des tests croisés mutuels (tests unitaires ou fonctionnels), et peut-être que votre scrum master et le propriétaire du produit peuvent vous aider avec les tests d'intégration, mais pour les tests d'acceptation des utilisateurs, vous devez vous assurer d'obtenir beaucoup de commentaires du test du client - ce qui signifie déploiements fréquents avec lequel ils peuvent travailler de la même manière que les vrais utilisateurs et communications vraiment ouvertes canal.
Le test de logiciels est un travail professionnel à plein temps. 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 logiciels, aussi intelligent soit-il, peut se rapprocher d'un testeur professionnel lorsque les tests ne sont qu'une petite composante de son travail quotidien.
En plus de cela vient le problème selon lequel inconsciemment le développeur du logiciel ne veut pour trouver des bogues.
Vous devez concevoir en gardant à l'esprit la testabilité, mais si vous n'avez pas de testeur dédié, certaines choses passeront simplement à travers les mailles du filet car il n'y a pas assez d'heures dans la journée pour concevoir, mettre en œuvre et tester le logiciel.
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 le seul "oeil" sur ce code avant de s'engager à vivre. Bien que cela ne va pas tout saisir, cela aidera au moins à éviter la cécité qui se glisse lors des tests et des retests de votre propre code lors du développement.
De la mention du cas d'utilisation, je suppose que vous utilisez également des outils de couverture de code? Sinon, cela pourrait aider à voir quel code pourrait ne pas être testé et pourrait apparaître dans des bogues inattendus dans certaines conditions.
Cela étant dit, s'il y a suffisamment de travail ou si votre organisation est de taille décente, je conviendrais qu'une personne professionnelle en AQ est nécessaire, aiderait à concentrer un peu plus les rôles de chacun, et ils pourraient également voir s'il y a des modèles de ce est manqué, et plus important encore, comment y remédier.