Le coût d'un délai plus long entre le développement et le contrôle qualité

À mon poste actuel, l'assurance qualité est devenue un goulot d'étranglement. Nous avons eu la malheureuse apparition de fonctionnalités retenues dans la version actuelle afin que le contrôle qualité puisse terminer les tests. Cela signifie que les fonctionnalités en cours de développement peuvent ne pas être testées pendant 2 à 3 semaines après que le développeur est déjà passé. Avec le développement plus rapide du QA dev, cet écart de temps ne fera que s'agrandir.

Je continue à feuilleter ma copie de Code Complete, à la recherche d'un extrait de "données dures" qui montre que le coût de la correction des défauts augmente de façon exponentielle plus il existe. Quelqu'un peut-il m'indiquer quelques études qui soutiennent ce concept? J'essaie de convaincre les pouvoirs en place que le goulot d'étranglement de l'AQ est beaucoup plus coûteux qu'ils ne le pensent.

Vous n'avez pas besoin de références, à mon humble avis. Voici ce que vous pourriez (plutôt devriez ) faire:

Quantifiez le coût du retard! Supposons qu'il faut 1 semaine pour tester la ou les fonctionnalités. Un délai de 2-3 semaines implique que la fonctionnalité ne sera pas disponible avant au moins la 4e semaine. Et cela aussi en supposant un succès à 100%. Ajoutez un délai de fixation d'une autre semaine pour un délai d'environ 5 semaines.

Maintenant, si possible, accédez à l'échéance prévue du projet / de la fonctionnalité. D'ici quand le client s'y attend-il? Va-t-il glisser? Sinon, les autres glisseront-ils en conséquence? Donc, de combien la «libération» sera-t-elle retardée en conséquence?

Quel est le «coût pour l'entreprise» de cette version, c'est-à-dire combien le client s'attend-il à tirer profit de cette version? S'ils s'attendent à un bénéfice de 5200 $ / an de cette version, chaque semaine de glissement leur coûte 100 $ de revenus perdus. C'est l'avis du client. Vous pouvez ou non avoir accès à ces données, mais cela vaut la peine de prendre en considération et d'indiquer comment le retard peut affecter la relation.

Maintenant, quelle est la perte pour les développeurs? Une fois que le développeur passe à d'autres fonctionnalités, vous lui demandez de rompre son cycle et de «corriger» la fonctionnalité précédente. Quelle est la perte de temps / effort? Convertissez-le en coût pour l'entreprise en utilisant le salaire comme un multiple pour chaque heure perdue. Vous pouvez utiliser cela pour dire le montant des "bénéfices / revenus" que les déchets "consomment".

Ce sur quoi vous êtes tombé peut être facilement quantifié à l'aide du «coût du retard» - préconisé par Don Reinerstein dans les principes du flux de développement de produits et également par Dean Leffingwell dans Agile Software Requirements. Vous devriez être en mesure de soutenir chacune de ces revendications par des facteurs économiques pour convaincre les `` puissances supérieures '' dont la langue principale est $$ - vous devez parler leur langue pour les convaincre :)

Bête de chance! (jeu de mots volontaire :)

Je ne pense pas vraiment que Code Complete soit la bonne ressource pour vous ici. Ce n'est pas un problème de code, c'est un problème de processus et peut-être un problème de gestion.

Si une partie de votre processus est particulièrement faible, il est temps de sortir de la théorie des contraintes :

1. Identifiez la contrainte.

   Cela signifie trouver la partie la plus lente ou la plus inefficace du processus global. Dans votre cas, c'est un test. Mais quelle partie du test? Est-ce:

   • Vous préparez l'environnement de test?
   • Déterminer quoi tester?
   • Tests fonctionnels (d'acceptation)?
   • Tests de régression?
   • Essais exploratoires?
   • Signaler des bugs / défauts des tests?
   • Déterminer les étapes pour reproduire un bug?
   • Obtenir des clarifications de la part des développeurs ou des chefs de projet?
   • Vous résolvez les problèmes rencontrés à l'étape de l'AQ?

   Ce sont tous des problèmes très différents et appellent des solutions différentes. Vous devez décider lequel est le plus coûteux / le plus important. Il ne devrait pas être difficile de le justifier auprès de la direction, car toutes les activités ci-dessus coûtent du temps (argent AKA) et seules quelques-unes sont du temps à valeur ajoutée.

2. Exploitez la contrainte.

   En d'autres termes, optimisez autour du processus contraignant. Ne laissez jamais les testeurs inactifs. Cela revient essentiellement à:

   • Mettre les testeurs au sein des équipes de développement, s'ils ne le sont pas déjà, il y a donc une boucle de rétroaction continue avec les développeurs.
   • Ayant des déploiements de tests fréquents, il y a donc toujours quelque chose de nouveau / fixe à tester.
   • Rendre la communication plus rapide et plus fréquente. Par exemple, privilégiez la messagerie instantanée sur les fils de discussion.
   • S'assurer que les testeurs disposent des meilleurs outils disponibles (machines rapides, plusieurs moniteurs, suivi des bogues rationalisé, etc.)

   Cette étape ne consiste pas (encore) à optimiser le processus de test lui-même, mais plutôt à réduire les frais généraux. Ne perdez pas le temps des testeurs. L'élimination du temps vraiment perdu devrait également être facile à vendre pour la direction.

3. Subordonnez les autres activités à la contrainte.

   À ce stade, les testeurs sont aussi productifs que possible par eux-mêmes, nous devons donc commencer à emprunter la productivité dans d'autres domaines:

   • Demandez aux développeurs et au personnel d'exploitation de donner la priorité aux testeurs, peu importe sur quoi ils travaillent.
   • Si vous ne disposez pas d'équipes multifonctionnelles, réservez une salle de réunion tous les jours à une heure prédéfinie afin que les testeurs n'aient pas à perdre de temps à en réserver une.
   • Détourner un pourcentage plus important du temps du développeur (et éventuellement des opérations) du travail sur les fonctionnalités; par exemple, concentrez-vous sur les corrections de bogues, l'endettement technique / la refactorisation, la révision du code et les tests unitaires.
   • Testez en continu et par incréments - ne développez pas pendant 3 semaines, puis envoyez-le aux testeurs. Demandez aux développeurs de travailler à rendre leur code immédiatement testable, par exemple avec des échafaudages ou des prototypes d'interfaces utilisateur.

4. Élevez la contrainte.

   Si les testeurs fonctionnent à pleine capacité - à la fois en termes de productivité et de frais généraux minimaux - et que ce n'est toujours pas assez rapide, alors vous devez commencer à investir davantage dans les tests.

   • Si vous comptez sur des déploiements de tests manuels, automatisez-les grâce à l'utilisation de scripts d'intégration continue et de gestion de la configuration.
   • Si la mise en place des plans de test prend du temps, essayez d'obtenir de meilleurs critères d'acceptation (c.-à-d. INVESTIR ). La plupart des organisations sont initialement très mauvaises à ce sujet.
   • Si les tests d'acceptation prennent trop de temps, commencez à les automatiser. Utilisez un outil comme Cucumber ou FitNesse, ou écrivez des tests de type xUnit si vous le devez. Il existe également Selenium, Watij et d'autres outils d'automatisation du navigateur si les tests d'interface utilisateur prennent du temps.
   • Si les tests de régression prennent trop de temps, automatisez cela également. S'il ne peut pas être automatisé, concentrez-vous sur l'amélioration de la qualité dès le départ, c'est-à-dire en mettant davantage l'accent sur la révision du code, les tests unitaires, les outils d'analyse statique, etc. Les développeurs doivent être assez confiants qu'il y a très peu de bogues réels avant de le passer à l'AQ (les défauts de produit sont une autre histoire).
   • Si les tests exploratoires sont le goulot d'étranglement, vous pouvez potentiellement en différer une partie jusqu'à la sortie, ou sous-traiter à une société de tests pour effectuer des tâches hautement parallélisables, comme tester le même flux de travail dans plusieurs navigateurs.
   • Si les testeurs ne sont pas en mesure de reproduire un grand nombre de bogues, envisagez de créer un environnement de test de capacité pour pouvoir commencer à reproduire les erreurs intermittentes. Ou essayez simplement d'exécuter vos tests d'acceptation automatisés en parallèle et en continu, toute la journée, en conservant des journaux détaillés.
   • S'il faut trop de temps pour corriger les bogues, alors commencez à partitionner vos projets et / ou envisagez sérieusement de réarchitecturer vos solutions. Ou, alternative, ne corrigez pas certains d'entre eux; tous les bogues ne sont pas critiques, vous devriez pouvoir les hiérarchiser en parallèle du travail sur les fonctionnalités.
   • Si tout le reste échoue, embauchez plus de testeurs.

5. Revenez à l'étape 1.

Je voudrais dire que tout cela relève du bon sens, mais ce n'est malheureusement pas le cas, du moins pas dans la plupart des organisations. Si vous rencontrez beaucoup de résistance de la part de la direction, une technique inestimable est le Value Stream Mapping (une technique issue de la fabrication sans gaspillage), que vous pouvez utiliser pour montrer combien de temps et donc d'argent est réellement gaspillé chaque jour par un candidat à la version incapable. pour passer à l'étape suivante. Le coût d'opportunité est difficile à comprendre, mais c'est l'un des meilleurs moyens que j'ai trouvés pour le visualiser et le démontrer.

Et si rien de tout cela ne fonctionne ... alors peut-être que vous êtes dans une entreprise dysfonctionnelle, sortez avant qu'il ne soit trop tard!

Mais vous ne résoudrez pas ce problème simplement en déposant quelques papiers sur le bureau du gestionnaire et en leur demandant de jeter de l'argent sur le problème, car ils supposeront (correctement) que jeter de l'argent dessus ne le résoudra peut-être pas réellement, et pourrait même faire c'est pire. Vous devez fournir des solutions , et c'est de cela qu'il s'agit. Si vous présentez le problème comme "voici une liste de façons dont nous pouvons commencer à résoudre ce problème, par ordre décroissant de coût / avantage" plutôt que "nous avons besoin de plus de testeurs", alors vous aurez beaucoup plus de succès.

Les pages 29 et 30 peuvent contenir les données que vous recherchez, bien qu'un suivi puisse être nécessaire.

Je voudrais examiner les recherches mentionnées dans cette phrase à la page 30:

Des dizaines d'entreprises ont constaté que le simple fait de se concentrer sur la correction des défauts plus tôt que tard dans un projet peut réduire les coûts et les calendriers de développement de deux facteurs ou plus (McConnell 2004).

BTW, c'est ta question qui m'a fait reprendre le livre pour le rafraîchir :-)

Ce que vous décrivez est un goulot d'étranglement dans un processus. La théorie Lean indique qu'il y aura toujours un goulot d'étranglement dans un processus, mais sa gravité peut varier considérablement. Si QA en a embauché un de plus, le développement pourrait devenir le goulot d'étranglement.

Pour comprendre le coût, imaginez la situation suivante. Vous avez choisi l'un des développeurs. Son travail ne serait jamais de qualité garantie, mais toujours mis en file d'attente indéfiniment. Imaginez que cela signifie que l'AQ pourrait assurer la qualité du travail du reste des développeurs en temps opportun et qu'il n'y aurait aucun coût de retard.

Dans ce scénario, le coût du retard est le coût du salaire du développeur, car son travail serait gaspillé.

La raison pour laquelle je discute en termes de coût et non de valeur créée par le processus, est tout simplement parce qu'il est plus difficile de documenter la valeur d'un processus, même s'il est bien meilleur.

Je continue à feuilleter ma copie de Code Complete, à la recherche d'un extrait de "données dures" qui montre que le coût de la correction des défauts augmente de façon exponentielle plus il existe. Quelqu'un peut-il m'indiquer quelques études qui soutiennent ce concept?

Le coût exponentiel de la découverte d'un bug semble être basé sur une étude du NIST . L'étude était une enquête qui suppose des stades de cascade distincts:

Software Development Stage         | Cost
-----------------------------------+------
Requirements and Design            | 1X
Code and Unit Testing              | 5X
Integration and System Testing     | 10X
Beta Testing                       | 15X
Post Release                       | 30X

( tableau ici d'ici )

L'un des objectifs des méthodologies de développement logiciel Agile est de supprimer ces étapes distinctes et de réduire ces coûts. Les chiffres ne s'appliquent pas lors de l'utilisation d'autres méthodologies pour la cascade.

Votre problème n'est pas avec l'AQ, en fait, si votre AQ fait des tests, les retards sont à peu près le moindre de vos soucis. S'il vous plaît laissez-moi vous expliquer (encore une fois, car c'est une idée fausse courante dans l'industrie de la programmation) ... QA Assure la qualité du produit en supervisant l'ensemble du SDLC, depuis les exigences (peut-être plus tôt), en passant par le développement, la vérification, la publication et le support. Le test garantit qu'aucun défaut évident n'existe dans le code. Il y a une différence très grande et importante. Si vous aviez un véritable AQ, ils seraient partout dans le département Test / V&V pour demander pourquoi ils coûtaient du temps (et donc de l'argent) pour retarder les versions, ou dans toute la gestion du projet en s'assurant qu'ils géraient correctement la planification du projet, ou dans toute la gestion. sûr qu'il y avait assez de testeurs pour le code en cours de production etc ...

Donc, en supposant par QA que vous voulez vraiment dire Test, revenons à la question initiale. Code Complete l'a bien compris - le coût d'un défaut est le temps pris de l'insertion à la correction. La détection précoce n'est utile que si vous la corrigez également tôt, mais l'interprétation de la plupart des gens est erronée.

(Remarque: je joue l'avocat des Diables ici, ne prenez pas cela au pied de la lettre car je ne sais rien de vous) Le retard causé par votre service de test est un coût, cependant, je dois absolument vous demander si vous êtes en attendant qu'ils trouvent vos défauts, que faites-vous - ne devriez-vous pas trouver vos propres défauts? Peut-être que s'ils avaient moins de travail (grâce à une entrée de meilleure qualité avec moins de défauts de votre part), le délai ne serait pas aussi important et le coût moins élevé - en tant que gestionnaire, je vous demanderais comment vous prévoyez de réduire les défauts du code que vous livrez à test, car (sur la base de votre argumentation) ces défauts coûtent plus cher s'ils sont détectés par test, puis vous-même.

De plus, en tant que gestionnaire, je pourrais dire que ce n'est pas le test qui recherche vos défauts, leur travail consiste à trouver qu'il n'y a pas de défauts - si vous vous attendez à ce qu'ils trouvent des défauts, peut-être n'avez-vous pas fait votre travail assez bien.

Soyez prudent dans votre approche. Si vous n'avez pas de solution au problème, vous vous classerez probablement en deuxième position.