Ratio QA vs Development [fermé]

Question

Je travaille en tant que développeur de logiciels et j'ai eu une querelle aujourd'hui avec notre équipe d'assurance qualité sur les points suivants:

Dans quelle mesure les membres de l'équipe d'assurance qualité doivent-ils dépasser le nombre de développeurs travaillant sur le même produit?

Je sais que ce n’est pas une question de programmation, mais je pense que cette question est plutôt liée au développement de logiciels. J'espère donc que cette question ne sera pas close. Au lieu de cela, je vais obtenir des réponses de programmeurs professionnels qui ont une bonne expérience du travail dans les sociétés de développement SW afin que je puisse faire de bonnes statistiques.

Answer 1

La réponse est très subjective, mais voici mon expérience.

Microsoft possède une organisation de développement de tests solide. C'est un peu différent de l'assurance qualité traditionnelle car nous engageons 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, il faut environ autant de temps au testeur pour tester et automatiser une fonctionnalité que pour permettre au développeur de coder et de corriger les bogues du produit. Cela implique une correspondance 1: 1. Ceci est très similaire à la règle empirique voulant que l'écriture de tests unitaires prenne aussi longtemps que l'écriture du code.

Ce mélange varie en fonction de plusieurs critères:

1. Combien d'unités testent les développeurs. Plus ils en font, moins le test doit être fait.
2. Combien de fois les développeurs écrivent-ils par rapport aux librairies existantes? Si de nombreux codes préexistants sont utilisés et que les testeurs doivent également vérifier cette fonctionnalité, vous devez prendre en compte ce coût de développement irrécupérable pour le mappage 1: 1.
3. Le développement est dynamique. Si vous écrivez une interface utilisateur dans laquelle des modifications de développeur relativement minimes entraînent une modification importante de la surface à tester, vous aurez besoin de davantage de testeurs.
4. À quel point la fonctionnalité est-elle critique? 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'opposé, si vous travaillez sur des dispositifs d'imagerie médicale , vous avez besoin de beaucoup plus tester parce que les bugs sont difficiles à corriger sur le terrain et très mauvais quand ils se produisent.

Answer 2

Pour la plupart des projets de l'entreprise, le rapport est de 1: 1. Mais cela peut varier en fonction de plusieurs facteurs:

• Sortie Dev. J'ai vu un développeur qui avait une grande quantité de sortie et 3 AQ qui travaillaient sur ses fonctionnalités.
• Barre de qualité pour le produit. Un système critique et à haute fiabilité doit avoir une barre d’Assurance Qualité supérieure à celle d’un site Web de reporting interne et nécessiter davantage de personnel d’AQ.
• Certains projets doivent être testés avec un nombre plus élevé de configurations et de scénarios. Les développeurs peuvent rester constants, mais vous aurez évidemment besoin de plus d’assurance qualité pour couvrir toute la matrice de test.
• 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.

Answer 3

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 rechercher des cas extrêmes, et ceux qui peuvent écrire eux-mêmes du code de test automatisé et qui cherchent à trouver des moyens nouveaux et innovants (fuzzing, Selenium, écrire des 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 de 1: 1 ou supérieur par rapport à vos développeurs est probablement indispensable. Autrement, ils auront du mal à suivre toutes les nouvelles fonctionnalités introduites par l'équipe de développement et résisteront souvent à toutes les modifications apportées au produit, car cela compliquerait encore leur flux de tests.

Ce dernier type (par exemple, les ingénieurs de test capables de coder), d’autre part, est une aubaine pour toute équipe de développement productive. Les codeurs peuvent communiquer avec eux en tant que pairs et les testeurs peuvent trouver des moyens utiles d'automatiser et d'améliorer leurs propres processus en écrivant des faisceaux et des utilitaires de test plus intelligents et plus abstraits. Un très bon ingénieur de test peut probablement prendre en charge le travail de 2 ou 3 développeurs, en particulier si ces développeurs écrivent déjà des tests unitaires et d’intégration utiles que le testeur peut utiliser comme point de départ.

Answer 4

Mon lieu de travail est actuellement aux alentours de 8: 1. dev: qa. La raison en est que nous prenons les tests automatisés très au sérieux. Tous les travaux doivent avoir une couverture de test unitaire presque complète. Nous effectuons également des tests fonctionnels avec Fitnesse (toutes les user stories doivent comporter un test d’ajustement), les checkins déclenchent des tests complets avec un serveur de CI, les développeurs s’enregistrent fréquemment, nous publions fréquemment.

Tout cela est sur une application énorme avec plusieurs milliers de classes et d'innombrables scénarios. L'avantage est la rapidité, l'agilité et bien sûr le coût. Quelle que soit la durée supplémentaire passée par un développeur (même coûteux) à la rédaction des tests, il n’est pas plus humain que d’embaucher / gérer davantage de personnel d’assurance qualité ou de rechercher des bugs dans la production (même le personnel d’assurance qualité est humain après tout).

Le peu de personnel d’AQ que nous avons a le temps passé à écrire ses propres tests automatisés avec Selenium ou à s’engager dans de nouvelles fonctionnalités. Ils passent relativement peu de temps à redéfinir sans cesse les mêmes fonctionnalités.

Answer 5

De nombreux facteurs entrent en jeu pour y répondre.

1. Avez-vous des tests automatisés?
2. Comment sont structurés vos cycles de publication?
3. Quel est le pourcentage de couverture de votre test unitaire?
4. Quelle est la qualité de vos collaborateurs (QA & Dev)?
5. Incluez-vous l'assurance qualité dans le cycle de vie complet du projet ou effectuez-vous des analyses à la fin?
6. Faites-vous des versions incrémentielles pour le contrôle qualité?

J'ai travaillé dans des endroits où il variait de 3: 1 (QA / DEV) à .5: 1 (QA / DEV). Cela se résume au nombre de ressources d’assurance qualité nécessaires pour tester le produit de manière adéquate et il n’ya pas de solution miracle à cela.

Answer 6

Actuellement, sur mon lieu de travail, il y a 3 développeurs pour chaque personne responsable du contrôle qualité. Cela a des hauts et des bas, car parfois le contrôle de la qualité trouve un problème, mais il existe des solutions autres que les modifications de code, par exemple. ne cliquez pas là où il est inutile de le faire.

Quelques fois, il n’ya pas d’assurance qualité dans laquelle j’ai travaillé, ce qui est parfois presque une recette pour un désastre puisque les clients deviennent alors l’assurance qualité alors que leurs problèmes deviennent des problèmes de développement.

Answer 7

Le nombre d'employés chargés de l'assurance qualité ne doit pas dépendre du nombre de développeurs . Cela devrait dépendre de la qualité souhaitable du produit, mais de rien d’autre.

Nombreux sont ceux qui disent ici "à l'assurance qualité". un travail de bon développeur est une tâche plus facile que "faire de l'assurance qualité" un travail d'un développeur pire. Enfer, pourquoi est-ce vrai? "Assurer la qualité" - et l'AQ est "l'assurance de la qualité" - signifie concevoir un processus qui marque le produit avec le "QA réussi" et "QA a échoué". Je ne connais que deux processus qui dépendent du code lui-même: la vérification de code statique et l'examen par les pairs. Tandis que l'ancien est un peu utilisé et qu'il a parfois besoin d'aide de la part du personnel d'assurance qualité, ce que l'on appelle "qualité" quality " du code n'est pas ce qui compte pour une machine sans âme. Et l'évaluation par les pairs est effectuée par les programmeurs, pas par l'AQ. J'espère que cela vous convainc que le montant de l'assurance qualité ne dépend pas des développeurs, n'est-ce pas?

Dans le domaine dans lequel notre société travaille, il n’ya pas de concurrence et le marché est très étroit. Par conséquent, nous obtenons toutes les informations nécessaires dans les rapports de bogues et nous n’avons pas de QA , le rapport est donc nul. Tous les tests sont effectués par les développeurs. Pourtant, nous vivons, car la qualité requise n’a besoin d’aucun type d’AQ.

Answer 8

Dans notre organisation, le ratio est le suivant: QA est de 5: 2 et, pour cela, nous devons comprendre plusieurs scénarios tels que

.

1. qui travaille sur les tests unitaires, dans notre cas, une personne est entièrement dédiée à la rédaction du plan de tests unitaires et une équipe de 5 membres exécute des scénarios de tests unitaires et corrige les bugs. notre PL n'est pas du tout impliqué dans le codage, il ne fait que des choses orientées processus / revue

2. 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, de la lettre de crédit écrite et des ressources de l'entreprise en fonction de leur niveau de CMM

Answer 9

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 tests ...

Dans un atelier de développement progressif, les besoins en ressources d’assurance qualité (en proportion du développement) devraient diminuer avec le temps, au fur et à mesure de l’amélioration de l’assurance qualité, tels que TDD, Code Review, etc. , L’Assurance Qualité devrait être utilisée pour améliorer les processus et aider les développeurs à se sentir stupides (en supprimant les bogues avant la publication).

Answer 10

Cela dépend de l’organisation et du site Web / de l’application en cours de développement. Toutes les entreprises ont leur propre rapport dev: QA selon leurs besoins.

En bref, cela dépend de la taille du projet et des ressources disponibles dans l'organisation.

Answer 11

Pensez en termes d'heures passées par opposition au nombre de personnes. Il est tout à fait possible que, pour un produit "testé et approuvé", application, pour chaque heure de développement, il peut y avoir une heure d'effort QA. Je fais spécifiquement référence 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 rédiger des scénarios de test en même temps que le développement. Cela signifie que tout doit être écrit dans un contrat d'implémentation (noms de fonctions, paramètres d'entrée, etc.).

Answer 12

Cela dépend de la qualité du personnel en fin de journée. Si un programmeur effectue autant de travail que deux agents d'assurance qualité, le rapport est égal à 1: 2, et inversement. La qualité du personnel ici serait numéro 1.