Quand le développement doit-il s'arrêter et que le contrôle qualité doit commencer?

Nous rédigeons une spécification fonctionnelle complète pour notre équipe de développement de deux personnes. Nous n'avons pas de testeurs professionnels, mais nous avons rédigé l'aide de notre personnel d'assistance disponible pour effectuer des «tests d'assurance qualité».

Nous avons eu des problèmes dans le passé où des blocs de fonctionnalités complets ne fonctionnent pas, ou le code est livré n'est tout simplement pas conforme aux spécifications.

Mes questions sont les suivantes: à quel stade les développeurs doivent-ils cesser de coder à la place de l'équipe QA? Est-ce trop demander aux développeurs de revoir leur code par rapport aux spécifications avant de le remettre à l'équipe QA?

Ça ne devrait pas!

Il est très difficile de faire tout le travail, d'arrêter, puis de résoudre tous les problèmes. Lorsque vous allez résoudre un problème que vous rencontrez au cours du processus d'AQ, vous pouvez apprendre qu'il serait préférable de faire quelque chose différemment.

Au lieu de tout considérer comme un processus de verrouillage, essayez de le rendre plus cyclique. Codez certaines fonctionnalités et testez-les. Codez un peu plus et testez-le (et les anciennes choses fonctionnent toujours). Ce processus plus fluide soulage la difficulté de tenter de tout charger par l'avant. Vous pouvez toujours avoir le concept d'un gel de code (il suffit de corriger les bugs) lorsque vous approchez de la date limite, mais le point est de tester tôt et souvent.

Eh bien, si des sections entières de code sont remises à QA dans un état non fonctionnel, vous devriez peut-être envisager d'ajouter une sorte de test unitaire / d'intégration à votre processus. N'abusez pas vos employés de l'assurance qualité en leur faisant découvrir que vous n'avez pas réussi à tester ou à tester votre code.

C'est une ligne fine, car si le code est livré selon les spécifications, cela signifie qu'il n'y a pas de bugs (et pas besoin de QA!). Le fait que le code ne soit pas systématiquement livré aux spécifications est la raison pour laquelle nous faisons de l'AQ en premier lieu.

Mais je ne pense pas que ce soit ce dont vous parlez. Ce que vous voulez dire, c'est que l'équipe de développement semble un peu trop paresseuse avec son codage, et il y a de grandes choses évidentes qui ne semblent pas fonctionner. Présenter à l'avance que les tests unitaires doivent être présents pour chacune des fonctionnalités A, B et C (dans la spécification), puis faire réviser le code et les tests de manière indépendante (par une équipe lean ou un gestionnaire) devrait aider à atténuer ce type de problème .

Je dirais qu'à tout le moins, les développeurs auraient dû tester le «chemin heureux». Que s'ils entrent les données attendues, cela fait ce que la spécification dit qu'il devrait faire. Les développeurs qui ne font pas grand-chose devraient être interrogés.

Je suis également déçu si un développeur n'a pas testé les cas de bord évidents: une chaîne trop longue pour la base de données, du texte évidemment invalide, si vous entrez des lettres où un nombre devrait être, etc. Si cela se produit souvent, des questions doivent à nouveau être posées .

Cependant, en supposant qu'il ne soit pas spécifiquement mentionné dans la spécification, si un développeur limite un nom aux lettres majuscules et minuscules, mais oublie que certains noms ont des apostrophes ou autorise une date du 29 février 2011 - c'est un peu plus compréhensible . À moins qu'ils ne commettent la même erreur à maintes reprises.

L'équipe QA devrait ramasser les cas extrêmes. Je préfère que le contrôle qualité soit un testeur de singe: il suffit de saisir des déchets aléatoires pour voir s'ils peuvent casser l'application de cette façon.

Dans le développement Web, le contrôle qualité doit essayer différents navigateurs et rechercher des plugins susceptibles d'affecter le code. Ils devraient désactiver Javascript et CSS et voir avec quoi ils peuvent s'en tirer. Ce genre de chose. Si vous vous attendez à ce que les développeurs fassent cela, vous dépensez trop d'argent pour cela.

Si une fonctionnalité livrée ne fonctionne pas, le problème n'est pas entre le développement et le contrôle qualité, mais entre le développement et les propriétaires de produits.

Les propriétaires de produits et les développeurs doivent faire partie de la même équipe et doivent travailler ensemble pour définir ce qui doit fonctionner pour considérer qu'une fonctionnalité est «terminée» et pour s'assurer que le code répond à ce besoin.

Lorsque le code est livré, les tests devraient être une simple formalité, car les propriétaires de produits auraient dû travailler avec les développeurs en cours de route pour s'assurer que tous les cas d'utilisation sont couverts.

(Si vous avez des testeurs professionnels, ils devraient faire partie de l'équipe et devraient être impliqués à chaque étape.)

Nous avons un processus de sélection pour les projets où nous demandons aux développeurs de donner une présentation / démonstration de leur code avant qu'il n'entre en QA. Nous incluons non seulement les testeurs QA, mais le (s) propriétaire (s) du code, du service client et du marketing / design. Cela tend à se concentrer sur les développeurs sur au moins les cas d'utilisation faciles, et parfois la discussion qui en résulte entre les différentes équipes entraîne des modifications des spécifications et un retard dans l'entrée en AQ. Lorsque nous le pouvons, nous impliquons l'AQ beaucoup plus tôt dans le processus, ce qui permet de corriger les bogues pendant que le code est encore chaud - mais nous faisons toujours la procédure pas à pas avant le démarrage de l'AQ «officiel».

J'ai parfois dit que le code ne devrait pas être soumis à QA si vous seriez contrarié s'il était par erreur mis en production au lieu de QA. Le code avec dysfonctionnement majeur n'appartient pas à l'AQ (sauf dans des circonstances spécifiques)