Ratio AQ/développement

Question

Je travaille en tant que développeur de logiciels et j'ai eu une dispute aujourd'hui avec notre équipe d'assurance qualité à propos de ce qui suit :

Dans quelle mesure les membres de l'équipe d'assurance qualité 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 assez liée au développement de logiciels. J'espère donc que cette question ne sera pas fermée. Au lieu de cela, j'obtiendrai des réponses de programmeurs professionnels qui ont une bonne expérience de travail dans des entreprises de développement de logiciels, afin que je puisse faire de bonnes statistiques.

Answer 1

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

Chez Microsoft, nous disposons d'une solide organisation de développement de tests. C'est un peu différent de l'AQ traditionnelle car nous engageons des programmeurs pour tester et les impliquons dans le processus dès la phase de conception. Leur travail consiste à tester et surtout à automatiser les tests pour le produit. D'après mon expérience, il faut au testeur à peu près autant de temps pour tester et automatiser une fonctionnalité qu'il en faut au développeur pour coder et corriger les bogues du produit. Cela implique une correspondance 1:1. Cela est très similaire à la règle empirique selon laquelle l'écriture des tests unitaires prend à peu près autant de temps que l'écriture du code.

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

1. La quantité de tests unitaires effectués par les développeurs. Plus ils en font, moins les tests doivent en faire.
2. La quantité de code que les développeurs écrivent à partir de zéro par rapport à l'utilisation de bibliothèques existantes. Si beaucoup de code préexistant est 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.
3. Le dynamisme du développement. Si vous écrivez une interface utilisateur où des modifications relativement mineures apportées par le développeur entraînent un changement important de la surface testable, vous aurez besoin de plus de testeurs.
4. Le degré de criticité de la fonction. Pour écrire quelque chose comme GMail, qui est utilisé de manière décontractée et dont les bogues peuvent être tolérés et corrigés sur le terrain, moins de testeurs sont nécessaires. A l'autre extrême, si vous travaillez sur dispositifs d'imagerie médicale vous avez besoin de beaucoup plus de tests, car les bogues sont difficiles à corriger sur le terrain et très mauvais lorsqu'ils se produisent.

Answer 2

Pour la plupart des projets de l'entreprise dans laquelle je travaille, 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 production et avait 3 QA travaillant sur ses fonctionnalités.
• Barre de qualité pour le produit. Un système à haute fiabilité, essentiel à la mission, devrait avoir un niveau d'assurance qualité plus élevé qu'un site Web de rapports internes, et nécessitera davantage de personnel d'assurance qualité.
• 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 de QA pour couvrir la matrice de test complète.
• Le degré d'automatisation des tests. Si les tests ne peuvent pas être facilement automatisés, vous aurez besoin de plus de personnes pour effectuer des passages manuels.

Answer 3

D'après mon expérience, il existe deux grands types de personnel d'assurance qualité : ceux qui se contentent de suivre un script écrit et d'interagir avec une application dans le but de trouver des cas limites, 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 de l'équipe de développement.

Si votre équipe d'AQ est principalement composée de personnes du premier type, un rapport de 1:1 ou plus avec vos développeurs est probablement indispensable. Dans le cas contraire, ils auront du mal à suivre les nouvelles fonctionnalités introduites par l'équipe de développement et résisteront souvent à la tentation de s'adapter aux nouvelles technologies. cualquier les changements apportés au produit, car cela complique encore plus le déroulement de leurs tests.

Ces derniers (c'est-à-dire les ingénieurs d'essai qui savent coder), en revanche, sont un groupe de personnes qui ne sont pas des ingénieurs d'essai. cadeau du ciel à toute équipe de développement productive. Les codeurs peuvent communiquer avec eux comme des pairs, et les testeurs peuvent trouver des moyens utiles d'automatiser et d'améliorer leurs propres processus en écrivant des harnais de tests et des utilitaires plus intelligents et mieux abstraits. Un très bon ingénieur de test peut probablement soutenir le travail de 2 ou 3 développeurs, surtout si ces derniers écrivent déjà eux-mêmes des tests unitaires et d'intégration utiles que le testeur peut utiliser comme point de départ.

Answer 4

Sur mon lieu de travail, le ratio dev/qa est actuellement de 8:1. La raison en est que nous prenons les tests automatisés très au sérieux. Tous les travaux doivent avoir une couverture de tests unitaires quasi complète. Nous effectuons également des tests fonctionnels avec Fitnesse (toutes les histoires d'utilisateurs doivent avoir un test fitnesse), les checkins déclenchent des tests complets avec un serveur CI, les développeurs font des checkins fréquents, nous publions fréquemment.

Tout cela sur une ÉNORME application comportant plusieurs milliers de classes et d'innombrables scénarios. L'avantage est la vitesse, l'agilité et bien sûr le coût. Le temps supplémentaire qu'un développeur (même coûteux) consacre à l'écriture de tests est inférieur au capital humain nécessaire pour embaucher et gérer davantage de personnel d'assurance qualité, ou pour trouver des bogues en production (même le personnel d'assurance qualité est humain après tout).

Le peu de personnel d'AQ que nous avons passe son temps à écrire ses propres tests automatisés avec Selenium ou à s'engager dans de nouvelles fonctionnalités. Ils passent relativement peu de temps à ressasser la même fonctionnalité, encore et encore.

Answer 5

De nombreux facteurs entrent en ligne de compte pour répondre à cette question.

1. Avez-vous des tests automatisés ?
2. Comment vos cycles de publication sont-ils structurés ?
3. Quel est le pourcentage de couverture de vos tests unitaires ?
4. Quel est le niveau de compétence de votre personnel (tant pour l'assurance qualité que pour le développement) ?
5. Incluez-vous l'AQ dans le cycle de vie complet du projet ou vous en déchargez-vous à la fin ?
6. Faites-vous des versions incrémentales pour l'assurance qualité ?

J'ai travaillé dans des endroits où ce rapport variait de 3:1 (AQ/DEV) à 0,5:1 (AQ/DEV). Tout se résume à savoir combien de ressources d'AQ sont nécessaires pour tester le produit de manière adéquate et il n'y a pas de réponse universelle à cette question.