Tests externalisés de la société; Comment pouvons-nous encourager les programmeurs à cesser de s'appuyer trop sur des testeurs?
Un de mes amis travaille dans une entreprise de 200 personnes. Les affaires de la société n'ont rien à voir avec cela, mais ils ont un service informatique de travailler, entre autres, sur leur site Web, utilisés par les clients.
Le site Web a commencé avec une idée principale que les programmeurs doivent tester les applications elles-mêmes en utilisant des tests automatisés. Cependant, il a rapidement commencé à être problématique, car les programmeurs dépensaient trop de temps à écrire des tests fonctionnels avec sélénium (et plus tard cyprès.io ) Essayer de gérer Les interactions complexes, telles que le glisser-déposer ou les téléchargements de fichiers, ou d'essayer de déterminer pourquoi les tests échouent au hasard. Pendant un certain temps, plus de 25% du temps a été dépensé pour ces tests; De plus, la plupart des programmeurs ont été énervés par ces tests, car ils souhaitaient produire une valeur réelle, n'essayez pas de déterminer pourquoi les tests échouaient au hasard.
Il y a deux ans, il a été décidé de payer une société de Bulgarie pour effectuer les tests fonctionnels de niveau d'interface manuellement. Les choses se sont bien déroulées, alors que de tels tests étaient assez peu coûteux. Dans l'ensemble, les programmeurs fournissaient des fonctionnalités plus rapidement, avec moins de régressions, et tout le monde était heureux.
Cependant, au fil du temps, les programmeurs ont commencé à être excessifs. Ils écrivaient moins d'intégration ou même de tests unitaires, et marqueraient parfois des caractéristiques comme toutes faites sans même vérifier si elles fonctionnent dans un navigateur: puisque les testeurs attraperont les erreurs, pourquoi déranger? Cela crée deux problèmes: (1) il faut plus de temps pour résoudre les problèmes lorsqu'ils sont découverts par des testeurs il y a quelques jours (par rapport à quand ils sont découverts en quelques minutes par des programmeurs eux-mêmes) et (2) le coût global des testeurs externalisés. pousse constamment.
Récemment, l'équipe principale tente de changer ce comportement en:
Mesure, par personne, combien de billets sont rouverts par les testeurs (et partageant les résultats à toute l'équipe).
Donner des félicitations aux personnes qui ont effectué le meilleur, c'est-à-dire ceux qui ont les billets les moins billets rouverts.
Passez la programmation de paires de temps avec ceux qui ont effectué le pire, essayant de comprendre pourquoi sont-ils si réticents à tester leur code et à leur montrer que ce n'est pas si difficile.
Expliquant qu'il est beaucoup plus rapide de résoudre un problème maintenant que d'attendre plusieurs jours jusqu'à ce que la fonctionnalité soit testée.
Expliquant que les testeurs effectuent uniquement des tests système et le manque de tests d'unité rend difficile la localisation de l'emplacement exact du problème.
Cependant, cela ne fonctionne pas:
Les métriques ne sont pas toujours pertinentes. On peut travailler sur un ticket peu clair ou complexe qui se fait réouvert plusieurs fois par les testeurs à cause des cas de bord et un collègue peut parfois travailler sur un ticket si simple qu'il n'y a aucune chance d'introduire une régression.
Les programmeurs hésitent à tester le code, car (1) ils le trouvent juste ennuyeux, et parce que (2) s'ils ne testent pas le code, celui-ci semble Ils livrent la fonctionnalité plus rapidement.
Ils ne voient pas non plus pourquoi la réalisation d'un problème des jours après le développement d'une fonctionnalité serait un problème. Ils comprennent la théorie, mais ils ne se sentent dans la pratique. En outre, ils croient que même si cela prendrait un peu plus longtemps, il est toujours moins cher que la société de payer des testeurs externalisés peu coûteux plutôt que de dépenser le temps de programmeurs sur des tests. Leur dire à plusieurs reprises que ce n'est pas le cas n'a aucun effet.
En ce qui concerne les tests système contre le système, les programmeurs répondent à ce qu'ils ne dépensent pas beaucoup de temps à trouver l'emplacement exact d'un problème rapporté par un testeur de toute façon (ce qui semble être réellement vrai).
Que peut-on faire d'autre pour encourager les programmeurs à cesser de se comporter sur des testeurs?
En bout de ligne: c'est un problème culturel.
Je viens du point de vue selon lequel les programmeurs compétents écrivent au moins des tests d'unité pour les parties plus complexes de leur code. Le problème n'est pas tout le monde partage mon point de vue. J'ai connu des personnes qui ont développé du code plus longtemps que ce que j'avais été en vie et ils testent également leur code - tout simplement pas nécessairement avec des tests automatisés. Il existe un certain nombre de choses dans le développement de logiciels trop simples à tester afin que ces tests ne soient pas une valeur réelle.
Cela dit, il existe différents niveaux de test avec différents pourcentages d'échecs aléatoires pouvant arriver. D'une perspective de gestion, vous devez comprendre où vous gagnez de la valeur.
- Tests unitaires : Vérifier les détails de l'implémentation et la manipulation des erreurs aussi proche que possible de la logique.
- Tests d'intégration : Vérifiez que les spécifications du système fonctionnent correctement
- Tests d'interface utilisateur: Vérifiez que l'application se comporte en fonction des exigences
Sans surprise, plus vous vous éloignez des unités de code individuels, plus vos tests sont fragiles. Plus vous avez de morceaux que vous devez travailler ensemble, plus on change de chance de tomber par intermittence. Cela signifie que c'est le plus proche du test de l'unité, vous pouvez attraper des problèmes les tests les plus fiables et les plus précieux.
coût de l'automatisation
L'automatisation coûte du temps. Le temps coûte de l'argent. Il faut plus de temps pour écrire des tests automatisés que pour tester manuellement une fonctionnalité. Cependant, chaque fois que le test automatisé est exécuté, il fonctionne dans une fraction du temps des tests manuels. D'un point de vue de la gestion, vous souhaitez vous assurer de bien avoir un bon retour sur votre investissement. Je recommande vivement que le code de risque le plus élevé - s'il casse que la demande est inutile - il faut avoir des tests automatisés pour vous assurer de prendre des régressions (code brisé) dès qu'ils se produisent. Si l'unité teste ne pas passer, le développeur ne peut pas pousser leur code.
En général, il aide à avoir des lignes directrices et un moyen de garantir que le code à risque élevé est couvert.
- Les tests d'unités doivent avoir au moins Couverture de 25%. (Je préfère personnellement plus haut, mais pour une équipe sans tests de l'unité, c'est un bon point de départ)
- Les tests d'unité et d'intégration doivent être priorisés sur le code à haut risque en premier.
- Définition de fait doit avoir une ou les deux exigences: [.____]
- Code Perser Review (Les demandes de traction sont un excellent moyen d'organiser ces)
- La couverture du test unitaire répond aux critères minimum
coût des tests manuels
Coûts de test manuels. Le temps coûte de l'argent. Bien qu'il soit plus rapide de tester manuellement une fonctionnalité une fois, il faut le même temps pour tester la fonction à chaque fois. Vous voulez continuer à tester les fonctionnalités finies pour protéger des régressions. Les régressions sont des fonctionnalités de votre application qui fonctionnaient plus.
Le coût caché des tests manuels est que les testeurs sont des personnes et parfois les gens ignorent des tests sur accident. Si vous pensez que l'écriture de tests automatisés était fastidieuse, essayez de tester les mêmes fonctionnalités avec tout le bouton clique sur le temps après.
optimiser votre investissement
Voici où la direction et le développement doivent être sur la même page. Si la qualité est importante pour la société, la société doit alors être disposée à investir dans la qualité. Si la qualité n'est pas importante, alors éliminez les tests. Vos utilisateurs se plaindront et vous risquez de ne pas être gêné par les problèmes qu'ils se plaignent. Cela dit, si l'application est critique de la mission, la qualité devrait être importante.
- Automatiser tester le code à haut risque [.____]
- Le risque peut être élevé en raison de la complexité de la solution
- Le risque peut être élevé en raison de la manière dont la fonctionnalité est nécessaire
- Le risque peut être élevé en raison du nombre élevé de dépendances sur le code
- N'écrivez pas les tests pour le code trop simple pour échouer (comme getters et setters)
- Test manuellement des choses trop compliquées pour tester automatiquement (comme glisser/goutte)
- Investir dans la simplicité
- Une exigence seul pourrait être assez simple, mais peut entrer en conflit avec d'autres exigences.
- Soyez prêt à supprimer les fonctionnalités afin que l'application serve les besoins actuels.
- Définir "fait" donc il est clair et sans ambiguïté
- Lorsque le travail à faire n'est pas clair, les développeurs et les testeurs ont des opinions différentes sur ce qui est juste.
- Quelques minutes de plus dans une réunion avec trois personnes peuvent sauver des jours de travail et retravailler en raison de définitions différentes de fait.
Résumé
La culture de la société est actuellement dans une situation sans gagnant. Les changements de culture sont plus faciles lorsque la direction a une buy-in. C'est également plus facile lorsque l'équipe introduit des disciplines qui les aident à être plus efficaces. À cette fin, je donnerais la priorité à la définition faite avant de donner la priorité à faire de la manière dont les tests sont effectués.
C'est génial que vous collectionionnez des métriques. Ce n'est pas formidable comment ces métriques sont actuellement utilisées. Un meilleur moyen est de regarder les tendances des métriques lorsque vous introduisez plus de structure dans la manière dont votre équipe développe des logiciels. Par exemple, si le temps d'achèvement est amélioré et que le nombre d'échecs de test diminue parce que vous passez plus de temps à définir ce qui doit être fait, c'est une victoire. Si vous augmentez votre couverture de test automatisée à 50% et que vous ne voyez aucune amélioration du nombre d'échecs de test, peut-être peut-être 25% suffit à 25%.
Le développement de logiciels est une activité d'équipe. Plus vous travaillez ensemble en équipe, la meilleure attitude de tout le monde deviendra. Plus votre équipe est créée pour réussir, plus votre équipe sera de succès.
D'accord, nous partageons tous l'objectif commun de la protection et de la défense des développeurs, mais il y a des choses dans votre question qui me rendent un peu mal à l'aise ...
Ils ne voient pas non plus pourquoi la réalisation d'un problème des jours après le développement d'une fonctionnalité serait un problème. Ils comprennent la théorie, mais ils ne le sentent pas dans la pratique.
Je suis désolé de casser la nouvelle, mais des programmeurs expérimentés ressentent la valeur de la capture d'un virus tôt dans la pratique .
En ce qui concerne les tests système contre le système, les programmeurs répondent à ce qu'ils ne dépensent pas beaucoup de temps à trouver l'emplacement exact d'un problème rapporté par un testeur de toute façon (ce qui semble être réellement vrai).
C'est un manuel Talk défensif (sent quelque peu passif-agressif). Et bien sûr, c'est vrai ... jusqu'à ce que vous le mettiez en perspective. Vous pouvez demander aux programmeurs ... utilisez-ils des signets dans leurs navigateurs? Est-ce qu'ils font une page d'accueil un moteur de recherche? Utilisent-ils l'onglet Alt + pour basculer entre les applications/Windows? Toutes ces choses sont des excuses pitoyes des gains de productivité ... c'est si vous les faites [~ # ~] une fois [~ # ~] . Lorsque vous le faites tout le temps , ces quelques secondes gagnaient facilement à une somme d'innombrables jours d'homme de productivité. Il faut vos programmeurs sur quoi, 1 minute pour trouver la source d'un problème rapporté par le testeur? C'est le temps qu'ils se sentent . Le temps réel comprend l'heure du testeur, le temps de préparer le rapport/fichier le ticket, le temps potentiellement dépensé pour communiquer les détails et le temps fermer le billet/le signaler comme résolu. Et le temps est de l'argent, non?
Pensez à cela comme oublier d'acheter du lait lorsque vous allez acheter de la nourriture. Pendant que vous êtes dans le magasin, c'est une minute de marche. Lorsque vous êtes à la maison, c'est exponentiellement plus. Maintenant, pour la mettre en perspective, c'est ainsi que 1 minute de temps en feutre traduit à environ 30 minutes de problèmes réels pour toutes les personnes concernées (bien qu'elle soit probablement beaucoup plus en réalité). Si la direction savait que des tests appropriés pouvaient sauvegarder l'entreprise quelque 30 fois de temps en temps consacré à la situation actuelle, comment se sentiraient-ils?
En outre...
Pendant un certain temps, plus de 25% du temps a été dépensé pour ces tests; De plus, la plupart des programmeurs ont été énervés par ces tests, car ils souhaitaient produire une valeur réelle, sans essayer de déterminer pourquoi le test échouerait au hasard.
Encore une fois, je suis désolé de casser la nouvelle, mais des programmeurs expérimentés comprennent que il y a une valeur réelle dans les tests plus 25% du temps n'est pas si mauvais un pourcentage. De bons tests valent leur longueur en or! En outre, Les tests n'échouent pas aléatoirement , du moins pas aussi souvent que cette déclaration audacieuse vous aurait pensé. Non Bon Tests, au moins, la qualité des tests est également une chose qui devra être sérieusement envisagée. Pensez à la Mark CE , par exemple, qui est tout sur le test! Les programmeurs sont-ils également en désaccord qu'il ajoute une valeur réelle aux produits?
Le problème réel avec cette dernière déclaration OP citée, cependant, est qu'il semble indiquer que la gestion a réellement a pris des conseils des programmeurs à l'externalisation des tests, ou Au moins été affectée par l'aversion des programmeurs à tester, contrairement à la manière dont les autres réponses peuvent suggérer que la direction a vissé cela tout seul.
Les programmeurs hésitent à tester le code, car (1) ils le trouvent simplement ennuyeux, et parce qu'ils ne testent pas le code, on dirait qu'ils fournissent la caractéristique plus rapidement.
Eh bien, la direction bousille de temps en temps, n'est-ce pas? Il semble que la pression ait été construite sur la délivrance des fonctionnalités rapidement, ce qui a été un peu envahi la culture. Les coins de coupe et les tests de chute vont de la main lorsque, sous pression excessive pour livrer, malheureusement.
Les programmeurs expérimentés iraient un long chemin sur la valeur des tests vaut la peine , plutôt que de se plaindre qu'ils mangent leur temps et qu'ils ne reçoivent pas valeur, comme on dit. Je suis dans l'avocat du diable, la position de devoir donner l'explication simple que les programmeurs sont relativement inexpérimentés, mais aussi, l'ensemble du système qu'ils jonglent ne sont pas ce complexe, ils n'ont donc pas encore eu trop de problèmes, pour vraiment sentir le valeur des tests automatisés appropriés.
Il n'y a qu'une seule suggestion ici, je serais en mesure de donner et ceci est à SHRIVE Pour faire ressentir les développeurs la valeur réelle des tests à tout prix. De plus, pendant, gardez les testeurs externes et composent des tests automatisés appropriés dans la mesure du possible. Si la sortie n'est pas aussi compliquée, la sécurité-critique, etc. L'entreprise pourrait probablement DO SANS SAN Testeurs externes, mais cela dépend toujours des détails.
Ne présumez pas seulement que vous avez raison de dépendre des tests d'intégration. Vous poussez pour les mauvaises choses. Soyez très prudent de conduire des personnes à des résultats mesurables et des résultats réels.
Mesure, par personne, combien de billets sont rouverts par les testeurs (et partageant les résultats à toute l'équipe).
Je suis désolé mais c'est juste stupide. Le travail des programmeurs n'est pas terminé lorsque le code est entre les mains d'un testeur. Compter combien de fois le code revient entre eux contre le programmeur est contre-productif. Vous voulez des programmeurs engagés avec des testeurs. Ne les punissez pas pour le faire. Les bons programmeurs encouragent leurs testeurs. Ils ne se cachent pas d'eux.
Donner des félicitations aux personnes qui ont effectué le meilleur, c'est-à-dire ceux qui ont les billets les moins billets rouverts.
Ce n'est pas une bonne mesure de mieux. Vous en récompensez ceux qui peuvent cacher leurs insectes, pas ceux qui travaillent pour les voir éliminés.
Passez la programmation de paires de temps avec ceux qui ont effectué le pire, essayant de comprendre pourquoi sont-ils si réticents à tester leur code et à leur montrer que ce n'est pas si difficile.
Tous ceux qui dirigent leur code testent leur code. Quand les gens ne comprennent pas comment ils sont jugés, les intelligents n'essayent même pas de deviner. Ils se soumettent rapidement à l'arrêt et espèrent apprendre quelque chose d'utile du résultat. Nous avons un terme de fantaisie pour ce comportement. Ça s'appelle agile.
Maintenant, s'il vous plaît ne prenez pas cela pour dire que je n'aime pas la programmation par paire. Je l'aime. J'ai appris plus assis avec d'autres codeurs qui frappent un problème puis de n'importe quel livre ou blog. Je ne peux pas attendre que cette chose coovidante disparaisse pour que je puisse le récupérer.
Mais ce n'est pas une programmation par paire si tout ce que vous faites est prêché. Si vous faites cela, arrêtez-vous et écoutez votre partenaire. Vous pouvez apprendre quelque chose et trouver votre problème n'est pas ce que vous pensez que c'est.
Expliquant qu'il est beaucoup plus rapide de résoudre un problème maintenant que d'attendre plusieurs jours jusqu'à ce que la fonctionnalité soit testée.
Eh bien voici votre problème. Il ne faut pas prendre plusieurs jours pour tester une fonctionnalité. Pensez au code comme le ciment. Plus il se trouve, plus il est difficile de bouger. Obtenez-moi des commentaires du testeur plus rapidement. De préférence avant de commencer à penser à d'autres caractéristiques.
Plus il faut beaucoup de choses pour attraper un bug le plus cher qu'il est de corriger.
Expliquant que les testeurs effectuent uniquement des tests système et le manque de tests d'unité rend difficile la localisation de l'emplacement exact du problème.
Arrêtez d'expliquer et de faire Test de l'unité de pair. Cela leur montre ce que vous voulez. Les programmeurs communiquent le mieux avec le code. Cela leur permet de le faire.
Fonctionne comme ceci: j'écris un test de l'unité. J'écris le code de production qui transmet mon test d'unité. Vous examinez le code, remarquez quelque chose de Hinky et vous écrivez un test de l'unité qui prouve le hinkyness. Vous m'envoyez votre test de l'unité, je le regarde et que vous le faites passer ou nous parlons de ce que devrait être la réelle exigence. Est-ce que les tests d'unité homologues et vos testeurs de l'unité faibles apprendront de votre plus forte. Assez étrangement, les forts vont également apprendre des faibles.
Oh et vous pouvez le faire lorsque vous pairez un programme. Rend le tout je vais vite.
En parlant d'exigences, si le testeur d'intégration fait partie de la discussion sur les exigences et lesquelles sont testables, avant que ce codage ne commence votre esprit. Ils appellent l'appel sur les exigences d'intégration testable. Les codeurs devraient savoir comment cela tremblait avant même de commencer une conception.
Vous envoyez un code aux testeurs d'intégration après son examen par les pairs et des tests de pairs. Maintenant, deux codeurs ont choisi ceci au plus tôt et les deux devraient être enracinement pour les testeurs de trouver des bugs restants. Ils ne devraient pas essayer de les cacher. Ils devraient signaler ouvertement tout ce qui pourrait aider le testeur d'intégration à les trouver.
Ce ne sont pas des programmeurs vs testeurs. C'est nous tous contre les insectes.
ARREZ ARRÊTEZ DE RÉCOMPORTER LES PERSONNES POUR CRÉER UN CODE UNTERBLIQUE.
Je suis fermement dans le camp de couverture 100% automatisé. Je pense que cela m'aide vraiment à aller plus vite à long terme, et je haine Avoir des choses me ramenées d'un testeur.
Cela étant dit, si les gens détestent faire des tests automatisés, vous devez fournir une incitation à ne pas avoir à les écrire. S'ils pensent qu'ils peuvent toujours maintenir la qualité sans tests automatisés, laissez-les le prouver. J'aurais besoin de tests automatisés pour tous les bugs qui leur sont renvoyés des testeurs et les rendent facultatives autrement. En d'autres termes, ils doivent rédiger un test qui échoue si le bogue signalé est présent, puis montrent qu'il passe avec leur correctif, comme une condition préalable à la rétablie par les testeurs.
Ce que j'espère que cela se produirait, les programmeurs les plus pollentés finiront par avoir à écrire le plus de tests, ce qui devrait les encourager à prendre plus de soins. Code qui est le plus facile à casser finira par la meilleure couverture. Les gens commenceront probablement à écrire des tests de manière préemptive pour des choses difficiles à tester manuellement et de faire des tests manuels plus approfondis pour les tests plus difficiles à automatiser. J'espère qu'il y aura également des investissements dans la réalisation de tests plus faciles à écrire et à courir. Très peu changera pour les programmeurs déjà prudents.
Quelques points que je ne vois pas vraiment dans les autres réponses.
Les ensembles de compétences pour le développement et les tests peuvent se chevaucher mais Certaines personnes font de grands testeurs et parfois, ce n'est pas les mêmes personnes qui font de grands développeurs. En tant que développeur, un bon département QA est Ça vaut son poids en or; me forçant à faire Tout Les tests moi-même, en particulier dans un environnement où Code de quelqu'un d'autre Pourriez changer le comportement d'une page Web Entre quand je Testez-le et lorsque le jeu combiné de changements va en direct est ... le contraire. Donc, si vous avez un flux constant de modifications, testez le résultat final Après avoir été fusionné est un peu plus important.
Un développeur sera probablement en mesure de vous dire Quoi Besoin de tests, ce qui pourrait aller mal, et ainsi de suite. Écoute-les.
Un autre point que je vois dans l'OP est qu'à un moment donné, une fois que vos développeurs avaient été utilisés pour utiliser un cadre de test, il y avait une décision de passer à un autre, ce qui se vante sur son site Web de réduction du volume des tests d'intégration, et bientôt.
Vous NON mentionner les raisons de cette décision, ni si une formation ou un délai d'apprentissage n'a été mis de côté pour ce changement. S'ils s'attendaient-ils à apprendre ce nouveau cadre au-dessus de Continuer à travailler au rythme attendu sur le développement des fonctionnalités, la fixation de bugs, etc.?
Envisagez de l'adopter dans la Gestion de projet thread.
Mais aussi - dis-leur simplement que leur travail ne sera pas accepté à moins d'être accompagné de tests automatisés. "Oui, cela est une partie de votre travail." Les testeurs externes ne sont là que pour vous garder honnête.
En tant que développeur de logiciels à vie me-même ((ainsi qu'un chef de projet de conseil), Je peux parler directement au nombre de fois où je pense que "mon A * S a été sauvé" par les tests que j'ai écrites , même de mon propre code que personne d'autre ne fonctionnerait, comme je la consolidais. I Fréquemment "Échec de la réussite". Et j'étais parfois étonné quand un test précédent a soudainement commencé à échouer. J'ai trouvé et corrigé "Gotcha!" après l'autre ... avant que cela ait eu une chance. Et de cette façon, j'ai construit une couche sur couche de code sachant que c'était correct.
Obtenez un support de gestion derrière vous que "il n'est pas accepté tant que cela n'est pas testé, et nous nous réservons le droit de rejeter vos tests."
Les critiques peuvent mieux fonctionner dans cet environnement.
En tant que développeur, je ressens la même chose. Les tests d'écriture sont des morts ennuyeux (en particulier des tests unitaires). Et ils ne sont pas toujours efficaces (en particulier des tests unitaires). Cela dépend du type de logique que vous écrivez et sur le type d'entrée que vous obtenez. Les exigences spécifiées à 100% ne sont pas si courantes dans mon expérience alors quels seront vos tests, vraiment? Nécessitant des personnes d'écrire des tests d'unité juste parce que peut être démotivant. Les personnes qui produisent la plupart des "bugs" peuvent faire la peine de produire les mêmes "bugs" (ils peuvent bien être les mêmes produits de la plus grande valeur).
La pression des pairs est plus efficace. Vous devez vous habituer à l'autre et cela peut vous faire mal, mais à la fin, vous aurez une équipe. Vous n'obtiendrez pas une équipe en imposant des règles externes qui ne sont pas soutenues par les personnes qui doivent les suivre.
Je suggérerais même de saisir l'essai hors shore les gars tout à fait. Je veux dire, pourquoi j'essaierai-je difficile de donner un comportement sans défaut lorsque je ne suis pas fait confiance pour le faire de toute façon et il y a une autre couche de vérification sur mon travail de toute façon? Apparemment, c'est la façon dont nous travaillons, non? Bien qu'ils soient là, laissez-les faire ma vie un peu plus facile et trouver les fins lâches pour que je puisse réparer, je n'ai donc pas trop d'effort.
Si ce filet de sécurité n'était pas là ... Je serais plus prudent. Je me sentirais respecté et responsable. Avec une attitude comme "Vous allez livrer de la merde afin que nous ayons tout ce que vous produisez scruté", je ne me sentirais pas enclin à essayer très fort.
Notre organisation a résolu le problème des développeurs ne testant jamais ses changements eux-mêmes en faisant cette partie du processus:
- Donner une modification aux tests nécessite de fournir une documentation de vos modifications.
- La documentation doit être faite à l'aide du modèle standardisé.
- Ce modèle comprend les sections obligatoires suivantes:
- Quelle était la raison du changement?
- Qu'est-ce qui a été changé?
- Un "test de fonctionnalité" où le développeur effectue un test de base de la modification, documentina son exécution et ses résultats avec des captures d'écran d'une manière qui montre que l'objectif du changement a été atteint. Ce test ne devrait pas être aussi minutieux qu'un test effectué par l'équipe d'assurance qualité. Il est tout simplement censé démontrer que cela semble maintenant travailler en ce qui concerne le développeur.
De cette façon, chaque développeur est obligé d'exécuter leur code modifié au moins une fois.
Vous avez besoin d'un "Définition de Done"
Les "définitions de façonnées" généralement acceptées incluent non seulement le code de travail, mais également des tests d'unité de travail et non seulement des tests de travail et de la documentation. Jusqu'à ce que ces choses soient terminées, la tâche n'est pas effectuée et le code ne peut pas et ne devrait pas Soyez libéré au département des tests ou de Dieu interdit, vivez.
Pendant que vous trouverez souvent le concept sous le parapluie agile/Scrum, que le cadre de fonctionnement n'est pas nécessaire pour mettre en œuvre cette idée.
https://www.scruminc.com/definition-of-done/
https://www.agilealliance.org/glossary/definition-of-done/
Les testeurs sont là pour attraper les choses que vous n'avez pas pensées, des cas d'utilisation étranges, ou des choses manquées honnêtement manquées.
Vous pouvez encourager les développeurs à ne pas "trop compter" sur les testeurs en se concentrant sur les résultats que vous essayez vraiment de réaliser (des caractéristiques probablement qui équilibrent le coût du développement avec la valeur que la société en bénéficie d'un certain niveau de qualité) et Laisser les développeurs décider de la quantité de compter sur les testeurs afin d'atteindre cet objectif. En d'autres termes, sauf si vous faites partie de l'équipe de développement, vous essayez de gérer quelque chose que l'équipe de développement devrait être gérée.
Fixation "FAIT"
La première chose à faire est de résoudre votre définition de "fait". Vous dites que les développeurs,
... serait parfois marquer des fonctionnalités comme si elles sont réalisées sans même [vérifier] s'ils travaillent dans un navigateur: car les testeurs attraperont les erreurs, pourquoi déranger?
Tout d'abord, redéfinir "Terminé" comme ", le changement est prêt à se lancer dans la production, à utiliser par des clients réels." Deuxièmement, rendre chaque développeur responsable de la gestion du processus qui obtient un changement particulier à la phase "Terminé". Cela inclut de veiller à ce que tout essais que le développeur soit terminé, que ce soit en écrivant et en exécutant des tests automatisés, d'envoyer un code et des instructions de test aux testeurs humains et en examinant les résultats, ou quoi que ce soit d'autre à laquelle ils peuvent penser.
Si un changement est jugé défectueux d'une certaine manière une fois que le développeur l'a déclare "fait", c'est le moment de s'asseoir avec le développeur et de faire un examen. Cet examen devrait être entre le développeur et un ou plusieurs membres âgés de l'équipe de développement. (Cela pourrait également inclure ou non une personne du côté du propriétaire du produit; voir ci-dessous.) Cet avis ne devrait pas être conflictural et ne devrait certainement pas commencer en supposant que quelque chose a été fait mal, mais examine l'impact des libérés (ou sur le point d'être Sortie, si vous l'avez attrapé à temps) et examinez quelles mesures rentables auraient pu être prises pour éviter cela, c'est-à-dire ce que le développeur (et l'équipe de développement) devrait changer pour améliorer les choses. (La réponse pourrait bien être: "Rien. Le coût de la prévention de tout ou partie de cela est plus que le coût de la vie avec eux.")
Le propriétaire du produit dans de telles réunions, s'il est présent, n'est pas là pour pousser l'équipe pour des changements techniques ou procéduraux, mais pour deux autres choses: 1. Fournir des informations sur le coût de l'impact négatif sur les entreprises (ou des coûts estimés, si Le défaut a été attrapé dans le temps) et 2. Évaluer si le propriétaire du produit souhaite ou non payer des coûts supplémentaires pour empêcher ce type de problème. (Par exemple, les développeurs disent: "Nous pouvons réduire l'incidence de ce type de chose de 50%, mais il lit le développement de 5%"; le propriétaire du produit peut alors décider si la qualité accrue à la libération vaut le taux de réalisation plus lent. caractéristiques déployées.)
Les développeurs gèrent les tests
Envoi de modifications aux testeurs de l'homme est, à un niveau élevé, pas très différent de l'écriture de tests automatisés. Il y a une sorte de script pour les testeurs ou le système de test à suivre (même si c'est un simple comme "Aller à cette URL et dites-moi ce que vous pensez") et le développeur évalue les résultats pour décider si elle a fini ou qu'elle ait besoin de faire Plus de travail (que ce soit pour changer de code ou exécuter plus de tests).
Ce script doit être conservé quelque part où il peut être examiné par d'autres développeurs à (ou en préparation) les réunions que j'ai décrites ci-dessus. Et l'histoire des modifications apportées à cela doit également être conservée, de sorte que par ex. Si un développeur enleva quelque chose (peut-être parce qu'elle a ajouté des tests automatisés pour couvrir quelque chose qui posait problème ou à faire trop de temps pour que les testeurs humains soient effectués), l'examen peut examiner cette décision. (Personnellement, je tiendrais généralement ces informations dans le code source repo, dans des fichiers texte ou marquage, mais les développeurs devraient faire tout ce qui fonctionne bien pour eux et l'équipe de test.)
Le script initial inclurait probablement l'histoire du propriétaire du produit, des instructions sur la manière de configurer tout ce qui est nécessaire pour tester ce bit de code et toute autre notes que le développeur trouve utile pour lancer.
Comme avec quoi que ce soit, les développeurs n'ayant pas expérimenté avec cela auront probablement besoin d'un soutien des autres dans l'équipe de développement. Vous ne vous attendriez pas à un développeur avec peu d'expérience dans les tests unitaires pour pouvoir rédiger de bons tests unitaires directement sur la batte, voire de déterminer ce qui doit être testé; Il en va de même pour la gestion des tests manuels.
Mais les développeurs doivent garder leurs yeux sur le but ici: être capable de déclarer quelque chose comme "fait" avec le sens qu'ils pensent que tout essais d'acceptation effectué par le propriétaire du produit, ou qui serait fait par le propriétaire du produit. S'il ne faisait tellement confiance aux développeurs et même de tests que le propriétaire du produit pourrait penser après que le développeur a obtenu l'histoire et a commencé à le coder.
Acceptation
Il y a quelque chose qui a quelque chose qui a quelque chose qui a ci-dessus, ce qui est qu'il y a vraiment deux étapes "faites" sous le contrôle des équipes distinctes. Le premier est le stade "fait" de l'équipe de développement, ce qui signifie "je m'attends à ce que cela passe tous les tests d'acceptation", comme mentionné ci-dessus. Le second est le propriétaire du produit "J'accepte ce changement; libère-le." Combien de travail le propriétaire du produit fait sur ce côté dépend de la manière dont l'équipe de développement est bonne. Lorsqu'une équipe de développement s'est révélée très fiable lors de l'interprétation des exigences et du code d'écriture qui les rencontre, le propriétaire du produit peut effectuer des tests minimaux. Lorsque l'équipe de développement ne fait pas un si bon travail à cela, le propriétaire du produit devra plus de vérification.
Où vous vous tenez actuellement sur ce spectre n'est pas trop important: ce qui est important, c'est que, lorsque les tests d'acceptation échouent, l'équipe de développement examine la manière dont il a échoué (c'est-à-dire pourquoi ils se sentaient de manière incorrecte, c'est "fait" quand ce n'était pas) et se développe systèmes permettant d'éviter des échecs similaires futurs lors des tests d'acceptation. L'amélioration de cela dans une certaine mesure particulière peut être une affaire technique purement interne à l'équipe de développement à traiter, ou certaines défaillances peuvent être dues aux problèmes de communication entre le propriétaire du produit et l'équipe de développement, auquel cas ils doivent travailler ensemble pour comprendre Comment résoudre ce problème.
Sommaire
Écrire des tests automatisés et l'envoi de code d'envoi à une équipe de test ne constitue tout simplement que deux méthodes différentes consistant à atteindre l'objectif d'assurer un changement de qualité suffisante à libération. Ils sont presque invariablement utilisés ensemble et la décision concernant la quantité de chacun à utiliser doit tomber au développeur en faisant le changement, car elle est intimement affectée par la façon dont elle choisit d'écrire son code. Elle devrait donc être en train de s'engager et nécessite un soutien nécessaire pour pouvoir gérer cela.
Il semble que la politique passait d'un extrême à l'autre. Je n'ai jamais vu de travailler dans la pratique une couverture de test de 100%. Le compromis entre la quantité de temps et de détail requis pour rédiger un test pour une fonction et l'avantage du test lui-même est généralement très variable. Mandat de manière émoussée une couverture de test de 100% sans envisager le compromis finira par forcer les développeurs à prendre plus de temps que nécessaire pour écrire des tests.
Une approche flexible serait meilleure. Exiger un minimum de couverture de test et dire aux développeurs d'essayer de juger à quel point il serait difficile d'écrire le test pour une fonction. Cependant, une autre personne qui n'est pas le développeur lui-même devrait faire un examen, vérifier quelles fonctions sont soumises à des changements fréquents ou avoir des exigences aussi complexes qu'elles pouvaient être cassées facilement et signalent ces fonctions comme celles qui ont besoin d'un test, quoi que ce soit.
Une autre chose qui aiderait consiste à trouver le développeur le plus qualifié avec les outils de test et à lui demander de développer des modèles pour la partie la plus difficile. Trouvant souvent comment construire les moqueurs autour d'une fonction particulière prend vraiment beaucoup de temps. Un ensemble de motifs/une solution à portée de main économiserait beaucoup de temps.
Il y a une solution très simple.
Vous appelez une réunion avec vos développeurs. Dans cette réunion, vous leur dites: "Nous avons un problème avec notre processus en ce moment. Il semble que, pour le moment, le code qui soit soumis ne fonctionne très souvent pas correctement. Cela provoque une quantité de QA de dépenser trop de temps à écrire des rapports de bugs et alors coûte le temps de développement fixant ces bugs. Nous avons eu le problème auparavant que le développement était extrêmement de grande qualité, mais à un coût énorme. Nous devons obtenir plus à un point au milieu, où les développeurs passent un peu plus de temps pour s'assurer qu'il y ait Pas trop de problèmes passés à QA, afin que nous puissions travailler plus efficacement globalement ".
Certaines réponses sont trop concentrées sur la difficulté de trouver le meilleur point. Ce n'est pas nécessaire. Vous avez eu un point sur un point extrême qui était inefficace, vous avez un point à l'autre extrême maintenant, ce qui est inefficace, aller plus loin au milieu sera une amélioration. N'ignorez pas d'amélioration simplement parce que vous ne pouvez pas trouver le point optimal.
Vous venez de répondre à vos questions lorsque vous avez les deux sujets publiés: "Les programmeurs hésitent à tester le code, car (1) ils le trouvent simplement ennuyeux, et parce qu'ils ne testent pas le code, il semble qu'ils ne testent pas livrer la fonctionnalité plus rapidement. " Qu'est-ce que ça veut dire? Comment la livraison est effectuée, s'il n'y a pas de test, qui sont prévus. Tout projet/module peut être livré (même mettre à un git) sur un référentiel uniquement après que Maven ou Mradele ou quoi d'autre a exécuté tous les tests le long de la construction. Qu'est-ce qu'une contribution du développement d'une unité? Les analystes ou l'architecte doivent fournir une liste des cas, qui doivent faire l'objet de tests d'un composant, ou dans le pire des cas, les ingénieurs de test (sont responsables des tests) d'abord mettre des tests dans le référentiel et les développeurs les obtiennent lors de la demande de traction. Maven/Gradle fera le travail. Outre une livraison doit passer une critique de code avec une première attention au test. Et seulement alors, les changements peuvent être fusionnés avec une branche utilisée pour la construction industrielle. Aucun test - pas de livraison, le travail n'est pas terminé! C'est tout.
"Passez la programmation de paires de temps avec ceux qui ont effectué le pire, essayant de comprendre pourquoi sont-ils si réticents à tester leur code et à leur montrer que ce n'est pas si difficile." Vraiment, l'élément de XP en tant que programmation par paire n'est pas dédié à afficher ABC aux développeurs, qui hésitent à faire une partie du travail. Tests - n'est pas seulement des tests, c'est une partie (un important) de leur travail, qui doit être dans la définition de la position. L'approche que vous avez mentionnée - passe du temps non seulement des testeurs, mais également d'un autre développeur, à moins qu'il ne soit sur la première étape d'une adsorption de nouveaux arrivants (débutant!). Votre environnement, y compris Devops, doit être construit conformément au principe: seul un composant, qui passe tous les tests prédéfinis consiste à aller. Sinon, il n'est pas livré.