Tests des développeurs vs.Tests en équipe d'assurance qualité : quelle est la bonne division du travail ?[fermé]

Question

Tout en essayant de plaider davantage de tests de développeur, je trouve l'argument "n'est-ce pas le travail de QA?" est utilisé beaucoup.Dans mon esprit, cela n'a pas de sens de confier à l'équipe d'assurance qualité toutes les responsabilités en matière de tests, mais en même temps, Spolsky et d'autres disent que vous ne devriez pas utiliser les développeurs à 100 $/heure pour faire quelque chose qu'un testeur à 30 $/heure pourrait faire. .Quelles sont les expériences des autres dans une entreprise dotée d’une équipe QA dédiée ?Où faut-il situer la division du travail ?

Clarification:Je voulais dire QA en tant qu'équipe de validation et de vérification.Les développeurs ne devraient pas effectuer la validation (tests axés sur le client), mais où est le point de division de la vérification (tests fonctionnels) ?

Answer 1

C'est la différence entre les tests en « boîte noire » (où vous savez ce que le code est censé faire, mais pas comment il fonctionne) et les tests en « boîte blanche » (où savoir comment il fonctionne détermine la façon dont vous le testez).Les tests en « boîte noire » sont ce à quoi la plupart des gens pensent lorsqu’on parle d’assurance qualité.

Je travaille pour une entreprise où l'équipe QA est également composée de développeurs de logiciels.(Cela réduit le champ beaucoup si vous voulez deviner l'entreprise.) Je connais l'opinion de Joel, et mon expérience m'amène à être partiellement en désaccord :pour la même raison qu'un pirate informatique "chapeau blanc" est plus efficace pour détecter les failles de sécurité, certains types d'erreurs sont détectés plus efficacement par les testeurs de boîte blanche qui savent écrire du code (et donc quelles sont les erreurs courantes - par exemple, la gestion des ressources problèmes comme les fuites de mémoire).

De plus, étant donné que les développeurs orientés QA font partie du processus dès la phase de conception initiale, ils peuvent théoriquement contribuer à générer un code de meilleure qualité tout au long du processus.Idéalement, pour chaque développeur travaillant sur le projet en se concentrant mentalement sur la fonctionnalité, vous avez un développeur opposé qui se concentre mentalement sur la rupture du code (et ainsi sur son amélioration).

Vu sous cet angle, il s'agit moins d'utiliser des développeurs pour les testeurs que d'une sorte de programmation en binôme déconnectée où un développeur met l'accent sur le contrôle de la qualité.

D'un autre côté, de nombreux tests (tels que les fonctionnalités de base de l'interface utilisateur) ne nécessitent franchement pas ce genre de compétences.C'est là que Joel a raison.

Pour de nombreuses entreprises, je pourrais voir un système dans lequel les équipes de programmation échangent les tâches de révision et de test du code pour le code de chacune.Les membres de l'équipe Business Logic, par exemple, pourraient passer une visite occasionnelle à tester et réviser le code pour l'équipe UI, et vice versa.De cette façon, vous ne « gaspillez » pas les talents des développeurs en tests à plein temps, mais vous bénéficiez des avantages d'exposer le code à (espérons-le) un examen minutieux et des sanctions d'experts.Ensuite, une équipe d’assurance qualité plus traditionnelle peut se lancer dans les tests « boîte noire ».

Answer 2

Le cas échéant, les équipes de contrôle qualité doivent être en mesure d'effectuer des tests de sécurité, de régression, d'utilisabilité, de performances, de stress, d'installation/mise à niveau et non les développeurs.

Les développeurs doivent effectuer des tests unitaires avec une couverture du code pour le code en cours d'écriture comme objectif minimal.

Entre les deux, il reste encore pas mal de tests à faire

• test du chemin de code complet
• Test des composants
• Tests d'intégration (de composants)
• Tests de système (intégration)
• etc.

Les responsabilités en la matière sont partagées entre l'assurance qualité et le développement, sur la base d'un accord mutuel sur ce qui a le plus de sens.Certains tests de composants ne peuvent être effectués que par des tests unitaires, d'autres sont « suffisamment » testés lors des tests d'intégration, etc.

Parlez-vous, découvrez ce que chacun est le plus à l’aise de faire.Cela prendra du temps, mais cela en vaut la peine.

Answer 3

Il devrait toujours y avoir des tests de développement.Si un développeur produit trop de bogues, il perd du temps plus tard à corriger ces bogues.Il est important que les développeurs n'adoptent pas l'attitude qui dit : eh bien, si je laisse un bug, il sera détecté et j'aurai la chance de le corriger.

Nous essayons de garder un seuil pour les bugs produits.Si ce seuil est franchi lors des tests, le développeur en est responsable.C'est à vous de décider quel est ce seuil (pour nous, il peut varier d'un projet à l'autre).

De plus, tous les tests unitaires sont effectués par les développeurs.

Answer 4

Je ne suis dans l'industrie que depuis un an, mais d'après mon expérience, les développeurs sont responsables des tests unitaires de leurs fonctionnalités, tandis que le QA est responsable des tests des scénarios.L'assurance qualité devrait également tester toutes les conditions limites.

Answer 5

Je colle ma réponse à une question sur notre forum interne.Si vous avez une heure environ..écoutez Mary Poppendieck Concurrencer sur la base de la vitesse vidéo. Recommandé

Remarque (par les testeurs – je fais référence à l'équipe QA)

Développeur / Tests unitaires ________=_______ Tests d'utilisabilité et exploratoire essai

'==================================================================

Réception / Tests clients ___=_____ Tests de propriété

Imaginez que ce soit un carré avec quatre quadrants.:)

La moitié gauche devrait être automatisée.

• Les tests des développeurs vérifient que le code fonctionne comme le codeur le souhaitait.Outils:NUnit / xUnit / quel que soit l'outil fait maison
• Les tests clients vérifient que le code fonctionne comme le client le souhaitait.Les tests doivent être très faciles à écrire et ne doivent pas obliger le client à apprendre .NET/Java.Sinon, le client n'écrira pas ces tests (bien qu'il puisse avoir besoin de l'aide d'un développeur).Fit utilise par exemple des tableaux HTML pouvant être écrits dans Word.Outils:Les outils de régression d'ajustement se trouvent également ici.Enregistrement-replay.

La moitié droite utilise mieux le temps et les efforts des bons testeurs.par exemple.Aucun test automatisé ne peut vous dire si la boîte de dialogue X est utilisable.Les humains sont meilleurs que les machines dans ce domaine.

• Convivialité.Essayez de briser le système (détectez les scénarios de défaillance non gérés, entrez des valeurs nulles).En gros, capturez les choses que le développeur a manquées.
• Les tests de propriété nécessitent à nouveau des humains.Ici, vous vérifiez les propriétés mandatées par le client et requises par votre système.par exemple.Performances : votre boîte de dialogue de recherche respecte-t-elle le temps de réponse de 2 secondes ?Sécurité : quelqu'un peut-il pirater ce système ?etc.Disponibilité : votre système est-il en ligne 99,99 % du temps ?

Les testeurs ne devraient pas passer du temps à exécuter des plans de test sur la moitié gauche.Il incombe aux développeurs de s'assurer que le code fonctionne comme le client et le développeur l'ont prévu.Les testeurs peuvent en effet aider le client à formuler les tests d'acceptation.

Answer 6

Les tests doivent être aussi automatisés que possible, ce qui les transforme en travail de développement si les testeurs écrivent du code qui est ajouté à la suite de tests automatisés.

De plus, j'ai constaté que nous effectuons beaucoup de contrôle qualité lors de la révision du code, car les gens suggéreront des cas supplémentaires qu'ils souhaitent voir ajoutés aux tests unitaires en cours de révision (avec le code qu'ils testent bien sûr) .

Answer 7

Ma position générale est que les testeurs ne devraient jamais trouver de bogues au niveau de l'unité (y compris les cas limites).Les bogues détectés par les testeurs doivent se situer au niveau du composant, de l’intégration ou du système.Bien sûr, au début, les testeurs peuvent trouver des bugs du « chemin heureux » et d'autres bugs simples, mais ces anomalies doivent être utilisées pour aider les développeurs à s'améliorer.

Une partie de votre problème pourrait être l'utilisation de développeurs à 100 $ par heure et de testeurs à 30 $ par heure :}.Mais quel que soit le coût, je pense que sachant que les bogues détectés plus tôt dans le cycle de développement sont inévitablement moins chers, vous économiseriez probablement de l'argent en demandant aux développeurs de réaliser davantage de tests.Si vous disposez d'une équipe de développement et de testeurs de hack très bien payés, vous découvrirez probablement bon nombre des gros problèmes évidents, mais vous manquerez beaucoup de bugs les plus obscurs qui reviendront vous hanter plus tard.

Donc, je suppose que la réponse à votre question est que les testeurs doivent tester autant que vous le souhaitez.Vous pouvez licencier tous vos testeurs et demander aux développeurs de faire tous les tests, ou vous pouvez embaucher une armée de testeurs et laisser les développeurs vérifier ce qu'ils veulent.

Answer 8

Il existe 2 types de groupes qa, ceux qui veulent maintenir le statu quo.Nous l’avons toujours fait.Naturellement, ils détestent et se débarrassent de ceux qui tentent de rendre les choses plus efficaces et sortent ainsi de leur zone de confort.Cela m'est arrivé plus d'une fois.Malheureusement, les responsables qualité sont aussi incompétents que leurs équipes qualité.Ainsi, un responsable qualité qui gère depuis 6 ans supprimera toute automatisation et introduira de nombreux processus juste pour justifier leur existence. C'est une responsabilité de la haute direction de le reconnaître.Il y a des gens quelque peu techniques qui connaissent les outils.Malheureusement, un langage de programmation n'est pas un outil, mais une vision.Travailler avec ces personnes dépend vraiment de leur volonté d’apprendre et de la volonté de la direction de prendre le risque de changer les choses.Les tests doivent être écrits de la même manière qu’un code principal est écrit dans une structure orientée objet facile à maintenir.Je pense que les développeurs devraient revoir les tests de qualité.La plupart du temps, j’ai constaté que l’automatisation ne testait rien.Malheureusement, le travail est considéré comme la classe inférieure, donc les développeurs ne s'en soucient pas.J'ai moi-même de la chance lorsque je reçois le soutien d'un développeur influent dans un groupe, disposé à expliquer mes efforts à un manager.Malheureusement, cela ne fonctionne que la moitié du temps.Les testeurs à mon humble avis devraient rendre compte au responsable du développement.Et toute l'équipe doit assumer la responsabilité de ce que les tests d'assurance qualité testent réellement.

Answer 9

Voici quelques façons dont les tests des développeurs sont les plus efficaces et les plus rentables :

• Le développeur modifie une bibliothèque partagée tout en travaillant sur une fonctionnalité : le développeur a un aperçu des effets secondaires possibles que le contrôle qualité/validation n'a pas
• Le développeur n'est pas sûr des performances de l'appel de bibliothèque et écrit un test unitaire
• Le développeur découvre le chemin du cas d'utilisation non pris en compte dans les spécifications que le code doit prendre en charge, écrit le code, met à jour les spécifications, écrit le test

On peut se demander quelle quantité de tâches de test devrait être effectuée par le développeur dans le troisième exemple, mais je soutiens que c'est le plus efficace pour le développeur car tous les détails associés à de nombreuses couches de documentation et de code sont déjà dans sa mémoire à court terme.Cette tempête parfaite peut ne pas être réalisable par un testeur après coup.

Parlons-nous d’assurance qualité ou de validation ?Je pense à l'assurance qualité dans le sens des listes de contrôle d'inspection, de l'application des normes du code, des directives d'interface utilisateur, etc.Si nous parlons de validation, cela n'a pas de sens pour les développeurs de passer beaucoup de temps à créer et à exécuter des cas de tests formels, mais les développeurs doivent fournir toute la documentation de justification et de conception nécessaire pour créer de bons tests.