QA vs Ratio de développement
Je travaille en tant que développeur de logiciels et j'ai eu une querelle aujourd'hui avec notre équipe QA sur les points suivants:
Dans quelle mesure les membres de l'équipe QA doivent-ils dépasser le nombre de développeurs qui travaillent sur le même produit?
Je sais que ce n'est pas une question sur la façon de programmer quelque chose, mais je pense que cette question est à peu près liée au développement logiciel. J'espère donc que cette question ne sera pas close. Au lieu de cela, j'obtiendrai des réponses de programmeurs professionnels qui ont une bonne expérience de travail dans des sociétés de développement SW afin que je puisse faire de bonnes statistiques.
La réponse est très subjective, mais voici mon expérience.
Chez Microsoft, nous avons une solide organisation de développement de tests. C'est un peu différent de l'assurance qualité traditionnelle, car nous embauchons des programmeurs pour les tester et les impliquer dans le processus dès la phase de conception. Leur travail consiste à tester et surtout à automatiser les tests du produit. D'après mon expérience, le testeur prend environ autant de temps pour tester et automatiser une fonctionnalité que le développeur pour coder et corriger les bogues du produit. Cela implique un mappage 1: 1. Ceci est très similaire à la règle de base selon laquelle l'écriture de tests unitaires prend aussi longtemps que l'écriture du code.
Ce mélange variera en fonction de plusieurs critères:
- Combien de tests unitaires les développeurs font. Plus ils en font, moins le test doit faire.
- Combien les développeurs écrivent à partir de zéro par rapport à l'exploitation des bibliothèques existantes. S'il y a beaucoup de code préexistant utilisé et que les testeurs doivent également vérifier cette fonctionnalité, ce coût de développement irrécupérable doit être pris en compte pour le mappage 1: 1.
- La dynamique du développement. Si vous écrivez une interface utilisateur où des ajustements de développeur relativement petits provoquent un changement important de la surface testable, vous aurez besoin de plus de testeurs.
- À quel point la fonctionnalité est essentielle à la mission. Pour écrire quelque chose comme GMail où il est utilisé avec désinvolture et où les bogues peuvent être tolérés et corrigés sur le terrain, moins de testeurs sont nécessaires. À l'autre extrême, si vous travaillez sur appareils d'imagerie médicale , vous avez besoin de beaucoup plus de tests car les bugs sont difficiles à corriger sur le terrain et très mauvais lorsqu'ils se produisent.
Pour la plupart des projets de l'entreprise, je travaille avec un rapport de 1: 1. Mais cela peut varier sur plusieurs facteurs:
- Sortie Dev. J'ai vu un développeur qui avait une grande quantité de sortie et avait 3 QA travaillant sur ses fonctionnalités.
- Barre de qualité pour le produit. Un système critique et hautement fiable devrait avoir une barre d'AQ plus élevée qu'un site Web de reporting interne, et aura besoin de plus de personnes d'AQ.
- Certains projets doivent être testés dans un plus grand nombre de configurations et de scénarios. Les développeurs peuvent rester constants, mais vous aurez évidemment besoin de plus d'AQ pour couvrir la matrice de test complète.
- Comment le test est automatisable. Si les tests ne peuvent pas être facilement automatisés, vous aurez besoin de plus de personnes pour effectuer des passes manuelles.
Mon lieu de travail est actuellement d'environ 8: 1 dev: qa. La raison en est que nous prenons très au sérieux les tests automatisés. Tous les travaux doivent avoir une couverture de test unitaire presque complète. Nous nous engageons également dans des tests fonctionnels avec Fitnesse (toutes les histoires d'utilisateurs doivent avoir un test fitnesse), les connexions déclenchent des tests complets avec un serveur CI, les développeurs s'enregistrent fréquemment, nous publions fréquemment.
Tout cela sur une ÉNORME application avec plusieurs milliers de classes et d'innombrables scénarios. L'avantage est la vitesse, l'agilité et bien sûr le coût. Quel que soit le temps supplémentaire qu'un développeur (même cher) passe à écrire des tests, c'est moins que le capital humain d'embaucher/gérer plus de personnel QA, ou de trouver des bugs en production (même le personnel QA est humain après tout).
Le peu de personnel d'AQ dont nous disposons arrive à passer son temps à écrire ses propres tests automatisés avec Selenium ou à se lancer dans de nouvelles fonctionnalités. Ils passent relativement peu de temps à répéter encore et encore les mêmes fonctionnalités.
D'après mon expérience, il existe deux types principaux de personnel d'assurance qualité: ceux qui suivent simplement un script écrit et interagissent avec une application dans le but de trouver des cas Edge, et ceux qui peuvent réellement écrire eux-mêmes du code de test automatisé, et chercher à trouver de nouveaux et des moyens innovants (fuzzing, Selenium, écriture de clients API) pour casser le code de l'équipe de développement.
Si votre équipe d'assurance qualité est composée principalement de personnes du premier type, un ratio 1: 1 ou mieux par rapport à vos développeurs est probablement un must. Sinon, ils auront du mal à suivre les nouvelles fonctionnalités introduites par l'équipe de développement et résisteront souvent à tout changements apportés au produit, car cela complique davantage leur flux de travail de test.
Le dernier type (c'est-à-dire les ingénieurs de test qui peuvent coder), d'autre part, est un aubaine pour toute équipe de développement productif. Les codeurs peuvent communiquer avec eux en tant qu'homologues et les testeurs peuvent trouver des moyens utiles d'automatiser et d'améliorer leurs propres processus en écrivant des faisceaux de tests et des utilitaires plus intelligents et mieux abstraits. Un très bon ingénieur de test peut probablement prendre en charge le travail de 2-3 développeurs, surtout si ces développeurs écrivent déjà eux-mêmes des tests unitaires et d'intégration utiles que le testeur peut utiliser comme point de départ.
De nombreux facteurs entrent en jeu pour y répondre.
- Avez-vous des tests automatisés?
- Comment sont structurés vos cycles de sortie?
- Quelle est votre couverture de test unitaire%?
- Quelle est la qualité de votre personnel (QA et Dev)?
- Incluez-vous l'AQ dans le cycle de vie complet du projet ou les jetez-vous à la fin?
- Faites-vous des versions incrémentielles de QA?
J'ai travaillé dans des endroits où cela variait de 3: 1 (QA/DEV) à .5: 1 (QA/DEV). Cela se résume au nombre de ressources d'AQ nécessaires pour tester correctement le produit et il n'y a pas de réponse fourre-tout à cela.
Il existe de nombreux facteurs, le plus important étant le niveau de qualité requis pour l'application, s'agit-il d'un petit site Web? ou un instrument médical majeur? ou un système financier? Une seule ligne de code modifiée pour la navette spatiale pourrait nécessiter des semaines de test ...
Dans un atelier de développement progressif, les besoins en ressources d'AQ (en proportion du développement) devraient diminuer au fil du temps au fur et à mesure que des améliorations d'AQ sont mises en œuvre, telles que TDD, les revues de code, etc. être utilisé pour améliorer le processus et aider les développeurs à se sentir stupides (en supprimant les bogues avant la publication).
La quantité de personnel QA ne devrait pas dépendre de la quantité de développeurs. Cela devrait dépendre de la qualité souhaitable du produit, mais pas d'autre chose.
Beaucoup ici disent que "faire de l'AQ", le travail d'un bon développeur est une tâche plus facile que "faire de l'AQ" un travail d'un pire développeur. Enfer, pourquoi est-ce vrai? "Assurer la qualité" - et QA est "assurance qualité" - signifie concevoir un processus qui marque le produit avec "QA réussi" et "QA échoué". Je ne connais que deux processus qui dépendent du code lui-même: la vérification du code statique et la revue par les pairs. Alors que le premier est quelque peu utilisé, et qu'il a parfois besoin de gars de QA pour le maintenir, ce qui est appelé " qualité " du code n'est pas ce qui compte pour une machine sans âme. Et l'examen par les pairs est effectué par les programmeurs, pas par le contrôle qualité. J'espère que cela vous convainc que la quantité de QA ne dépend pas des développeurs, n'est-ce pas?
Dans le domaine où travaille notre entreprise, il n'y a pas de concurrence et le marché est très étroit. Par conséquent, nous obtenons toutes les informations nécessaires à partir des rapports de bogues et nous n'avons pas d'assurance qualité, donc le rapport est nul. Tous les tests sont effectués par des développeurs. Pourtant, nous vivons, car la qualité requise n'a pas besoin de travailler avec des gars de l'assurance qualité.
Cela dépend de l'organisation et du site Web/de l'application en cours de développement. Toutes les entreprises ont leur propre ratio dev: QA en fonction de leurs besoins.
En bref, cela dépend de la taille du projet et des ressources disponibles dans l'organisation.
Dans notre organisation, le ratio est dev: QA est 5: 2, et pour cela, nous devons comprendre plus de scénarios comme
qui travaille sur les tests unitaires, dans notre cas, une personne est entièrement dédiée à la rédaction du plan de test unitaire et une équipe de 5 membres exécute des cas de test unitaire et corrige les bugs notre PL n'est pas du tout impliqué dans le codage, il ne fait que traiter/réviser choses orientées
les tests fonctionnels sont effectués par des testeurs à temps partiel, vous pouvez dire une demi-ressource et un cycle de tests fonctionnels effectués par les développeurs
Cela dépend donc de la taille du projet, des ressources LOC écrites et de l'entreprise en fonction de leur niveau CMM
En ce moment où je travaille, il y a 3 développeurs pour chaque personne QA. Cela a ses hauts et ses bas car QA trouvera parfois un problème mais il existe des solutions en dehors des changements de code, par exemple. ne cliquez pas là où il est inutile de le faire.
À quelques reprises, il n'y a pas d'AQ où j'ai travaillé, ce qui est parfois presque comme une recette pour un désastre, car les clients deviennent alors l'AQ lorsque leurs problèmes deviennent des problèmes de développeur.
Pensez en termes d'heures passées par rapport au nombre de personnes. Il est tout à fait possible que pour une application bien testée et "approuvée", pour chaque heure de développement, il puisse y avoir une heure d'effort d'AQ. Je me réfère spécifiquement au rôle d'AQ technique, pas aux tests fonctionnels. Une équipe d'AQ et une équipe de développement doivent être en mesure de travailler en étroite collaboration, afin que l'équipe d'AQ puisse écrire des cas de test en même temps que le développement se produit. Cela signifie que tout doit être écrit dans un contrat d'implémentation (noms de fonction, paramètres d'entrée, etc.).