QA vs rapport de développement [fermé]
Je travaille en tant que développeur de logiciels et j'ai eu une querelle aujourd'hui avec notre équipe QA à propos de ce qui suit:
Combien les membres de L'équipe QA doivent 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 du logiciel. J'espère donc que cette question ne sera pas fermé. Au lieu de cela je vais obtenir des réponses de programmeurs professionnels qui ont une bonne expérience sur le travail dans les entreprises en développement SW afin que je puisse faire une bonne statistique.
12 réponses
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 parce que nous embauchons des programmeurs pour les tester et les impliquer dans le processus dès la phase de conception. Leur travail est de tester et surtout d'automatiser les tests pour le produit. Dans mon expérience, il faut au testeur à peu près aussi longtemps pour tester et automatiser une fonctionnalité que le développeur pour coder et corriger les bugs dans le produit. Cela implique une cartographie 1:1. Ceci est très similaire à la règle empirique selon laquelle l'écriture de tests unitaires prend à peu près aussi longtemps que l'écriture du code.
Ce mélange varie en fonction de plusieurs critères:
- Combien de tests unitaires les développeurs font. Plus ils font, moins le test doit faire.
- Combien les développeurs écrivent à partir de zéro par rapport à tirer parti des bibliothèques existantes. S'il y a beaucoup de code préexistant en cours d'utilisation et que les testeurs doivent vérifiez également cette fonctionnalité, que le coût de développement irrécupérable doit être pris en compte pour le mappage 1: 1.
- Quelle est la dynamique du développement. Si vous écrivez une interface utilisateur où des réglages de développeur relativement petits provoquent un changement important de la surface testable, vous aurez besoin de plus de testeurs invovled.
- la mission critique de la fonctionnalité est. Pour écrire quelque chose comme GMail où il est utilisé avec désinvolture et les bugs 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 dispositifs d'imagerie médicale , vous avez besoin de beaucoup plus de tests parce que les bugs sont difficiles à corriger sur le terrain et très mauvais quand ils se produisent.
Pour la plupart des projets de l'entreprise que je travaille au rapport est de 1: 1. Mais cela peut varier sur plusieurs facteurs:
- Sortie Dev. J'ai vu un dev 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 de haute fiabilité et essentiel à la mission devrait avoir une barre D'assurance qualité plus élevée qu'un site Web de reporting interne, et aura besoin de plus de personnes D'Assurance Qualité.
- certains projets doivent être testés dans un plus grand nombre de configurations et de scénarios. Les Devs peut rester constant, mais vous aurez évidemment besoin de plus D'assurance qualité pour couvrir la matrice de test complète.
- Comment automatisable le test est. Si les tests ne peuvent pas être facilement automatisés, vous aurez besoin de plus de personnes pour faire des passes manuelles.
D'après mon expérience, il existe deux types principaux de personnel QA: ceux qui suivent simplement un script écrit et interagissent avec une application dans le but de trouver des cas de bord, et ceux qui peuvent écrire eux-mêmes du code de test automatisé, et cherchent à trouver des moyens nouveaux et innovants (fuzzing, Selenium, écriture de clients API) pour casser le code
Si votre équipe QA est composée principalement de personnes du premier type, alors 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 aux Modifications apportées au produit, car cela complique encore leur flux de travail de test.
Ce dernier type (c'est-à-dire, les ingénieurs de test qui peuvent coder), d'autre part, sont une aubaine pour toute équipe de développement productif. Les codeurs peuvent communiquer avec eux en tant que pairs, et les testeurs peuvent trouver des moyens utiles pour automatiser et améliorer leurs propres processus en écrivant plus intelligemment et des harnais de test et des utilitaires mieux abstraits. Un très bon ingénieur de test peut probablement soutenir le travail de 2-3 développeurs, surtout si ces développeurs écrivent déjà des tests d'unité et d'intégration utiles eux-mêmes que le testeur peut utiliser comme point de départ.
Mon lieu de travail est actuellement autour de 8: 1 dev: qa. La raison en est que nous prenons les tests automatisés très au sérieux. Tout le travail est nécessaire pour 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), checkins trigger test complet s'exécute avec un serveur CI, les développeurs vérifient fréquemment, nous libérons fréquemment.
Tout cela est sur une énorme application avec plusieurs milliers de classes et d'innombrables scénarios. Le 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 coûteux) passe à écrire des tests, c'est moins que le capital humain d'embaucher/gérer plus de personnel D'assurance qualité, ou de trouver des bogues en production (même le personnel D'Assurance Qualité est humain après tout).
Le peu de personnel QA que nous avons passe son temps à écrire ses propres tests automatisés avec du sélénium ou à s'engager dans de nouvelles fonctionnalités. Ils passent relativement peu de temps à ressasser la même fonctionnalité encore et encore Encore une fois.
Il y a beaucoup de facteurs qui entrent dans la réponse à cela.
- avez-vous des tests automatisés?
- Comment sont structurés vos cycles de publication?
- Quelle est votre couverture de tests unitaires % ?
- Quelle est la qualité de votre personnel (à la fois QA et Dev)?
- incluez-vous L'assurance qualité dans tout le cycle de vie du projet ou videz - vous sur eux à la fin?
- Faites-vous des versions incrémentielles vers QA?
J'ai travaillé des endroits où il variait de 3: 1 (QA/DEV) à .5: 1 (QA / DEV). Il se résume à combien de ressources QA il faut pour tester adéquatement le produit et il n'y a pas de réponse fourre-tout à cela.
En ce moment où je travaille, il y a 3 développeurs pour chaque personne QA. Cela a ses hauts et ses bas car parfois QA trouvera 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 fois, il n'y a pas D'Assurance Qualité où j'ai travaillé, ce qui est parfois presque comme une recette pour un désastre car les clients deviennent alors L'assurance qualité lorsque leurs problèmes deviennent des problèmes de développeur.
La quantité de personnel QA ne doit pas dépendre de la quantité de développeurs . Cela devrait dépendre de la qualité souhaitable du produit, mais pas de quoi que ce soit d'autre.
Beaucoup ici disent que "QA" un travail d'un bon développeur est une tâche plus facile que "QA" un travail de pire développeur. L'enfer, pourquoi est-ce vrai? Pour "assurer la qualité" - et QA est "assurance de la qualité" - signifie pour concevoir un processus qui marque le produit avec "QA passé" et "QA échoué". Je ne connais que deux processus qui dépendent de le code lui-même: vérification de code statique et examen par les pairs. Alors que le premier est quelque peu utilisé, et il a parfois besoin de gars QA pour le maintenir, la chose qui s'appelle "quality " du code n'est pas ce qui compte pour une machine sans âme. Et l'examen par les pairs est effectué par des programmeurs, pas QA. J'espère que cela vous convainc que la quantité D'assurance qualité ne dépend pas des développeurs, n'est-ce pas?
Dans le domaine dans lequel notre entreprise travaille, 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 de QA , donc le ratio est nul. Tous les tests sont effectués par les développeurs. Pourtant, nous vivons, parce que la qualité requise n'a pas besoin d'embaucher des gars QA.
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 à écrire un plan de test unitaire et une équipe de 5 membres exécute des cas de test unitaires et corrige les bogues notre PL n'est pas du tout impliqué dans le codage, il ne fait que des choses orientées processus/ examen
-
Les tests fonctionnels sont effectués par un testeur à 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 écrites et des ressources de l'entreprise en fonction de leur niveau CMM
Il y a beaucoup de facteurs, le plus important étant le niveau de qualité requis pour l'application, est - ce 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 tests...
Dans un atelier de développement progressif, les besoins en ressources D'AQ (en rapport avec le développement) devraient diminuer au fil du temps à mesure que des améliorations D'AQ sont mises en œuvre, telles que TDD, révisions de Code, etc. Je pense que L'assurance qualité axée sur les tests pratiques purs est un déchets, QA devrait être utilisé pour améliorer le processus et aider les développeurs à se sentir stupide (en supprimant les bugs avant la publication).
Cela dépend de l'organisation et du web / de l'application en cours de développement. Toutes les entreprises ont leur propre dev: QA ratio selon leurs besoins.
En bref, cela dépend de la taille du projet et des ressources disponibles dans l'organisation.
Pensez en termes d'heures passées par opposition 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 y ait une heure d'effort D'Assurance Qualité. Je me réfère spécifiquement au rôle D'AQ technique, pas aux tests fonctionnels. Une équipe D'assurance qualité et une équipe de développement doivent pouvoir travailler en étroite collaboration, afin que l'équipe D'Assurance Qualité puisse écrire des cas de test en même temps que le développement. Cela signifie que tout doit être écrit à un contrat d'implémentation (noms de fonctions, Paramètres d'entrée, etc.).
Eh Bien cela dépend de la qualité du personnel à la fin de la journée. Si un programmeur fait autant de travail que deux QA, alors le rapport est de 1: 2, et vice versa. La qualité du personnel ici serait #1.