Est-il correct de corriger les bogues sans ajouter de nouvelles fonctionnalités lors de la publication du logiciel pour les tests du système?

Cette question s'adresse aux testeurs expérimentés ou aux responsables de test. Voici un scénario d'un projet logiciel:

Supposons que l'équipe de développement ait terminé la première itération de 10 fonctionnalités et l'a mise à l'essai du système. L'équipe de test a créé des cas de test pour ces 10 fonctionnalités et estimé 5 jours pour les tests. L'équipe de développement ne peut bien sûr pas rester inactive pendant 5 jours et elle commence à créer 10 nouvelles fonctionnalités pour la prochaine itération. Pendant ce temps, l'équipe de test a trouvé des défauts et soulevé quelques bugs. Les bogues sont priorisés et certains d'entre eux doivent être corrigés avant la prochaine itération. Le hic, c'est qu'ils n'accepteraient pas la nouvelle version avec de nouvelles fonctionnalités ou des modifications des fonctionnalités existantes jusqu'à ce que tous ces bugs soient corrigés. L'équipe de test dit que c'est ainsi que nous pouvons garantir une version stable pour les tests si nous introduisons également de nouvelles fonctionnalités avec le correctif de bogue. Ils ne peuvent pas non plus effectuer de tests de régression de tous leurs cas de test à chaque itération.

Cela signifie que l'équipe de développement doit créer une branche de code uniquement pour la correction de bogues et une autre branche où elle poursuit le développement. Il y a plus de frais généraux de fusion spécialement avec le refactoring et les changements architecturaux.

Pouvez-vous convenir s'il s'agit d'un principe de test commun. La préoccupation de l'équipe de test est-elle valable? Avez-vous rencontré cela dans la pratique dans votre projet.

Je dirais plutôt que chaque version de nouvelles fonctionnalités devrait être sur une branche distincte. Cela permet de découpler le développement et les versions.

Comment votre version destinée aux utilisateurs finaux intervient-elle dans ce processus? Votre équipe de test du système devrait être moins concernée par le calendrier de développement et se concentrer à la place sur le calendrier des versions client.

Il est inutile d'essayer formellement de nouvelles fonctionnalités pendant que le développement se poursuit, car il est probable que vos 10 prochaines fonctionnalités toucheront la même fonctionnalité et les obligeront à tester à nouveau ces zones.

Ils peuvent continuer à tester de manière informelle les versions internes provisoires pendant le développement et étoffer leur conception de test (en espérant attraper la plupart des bogues dans ces nouvelles fonctionnalités), mais ils auront besoin d'une période supplémentaire à la fin du développement pour tester formellement les nouvelles fonctionnalités et la régression essai.

Lorsqu'ils estiment que 5 jours sont nécessaires pour tester vos 10 nouvelles fonctionnalités, ce qu'ils devraient considérer, c'est qu'ils ont besoin de 5 jours à la fin du cycle de développement, avant la mise à disposition des clients, pour valider les nouvelles fonctionnalités (et probablement plus de temps pour itérer). si des bugs sont détectés). Pendant cette période, la version client peut être dérivée pour les tests et le développement de nouvelles fonctionnalités peut se poursuivre pour la prochaine version.

Nous utilisons une approche hybride. Pour la version client, nous avons définitivement sa propre branche qui est strictement réservée aux corrections de bogues critiques.

Le développement régulier se poursuit sur plusieurs versions logicielles. Par exemple, disons que la dernière version stable est 2.0. Toutes les fonctionnalités risquées seront ajoutées à la branche 3.0. Seules les corrections de bugs sont introduites dans les branches 2.0. Les tests par une équipe QA dédiée sont effectués uniquement sur des succursales stables. Les versions client sont bien sûr effectuées à partir d'une autre branche basée sur 2.0. Les fonctionnalités de longue durée comme le développement de la prochaine génération de plate-forme seront effectuées dans 4.0, pas même 3.0.

Tout cela semble bien sur papier. Mais si un client souhaite une fonctionnalité spécifique, elle doit être ajoutée à la branche 2.0 elle-même, car la 3.0 n'est pas suffisamment stable pour être proposée aux clients. Cela signifie que l'équipe d'assurance qualité devra réexécuter l'intégralité de la suite de régression.

Une chose que nous faisons est de couvrir le code de chaque cas de test de régression. Seuls les cas de test de régression sont exécutés et seront affectés par les modifications de code de la fonctionnalité. Bien sûr, pour une version client, une suite de régression complète est exécutée.

Cela dépend vraiment du lien étroit entre les nouvelles fonctionnalités et les parties qui nécessitent des corrections de bogues. Par exemple, si vous ajoutez une nouvelle fonctionnalité de glisser-déposer à une petite partie de l'interface utilisateur, cela "ne devrait pas" affecter le bogue lié à l'analyse du fichier chargé par l'utilisateur.

Cela dit, il est compréhensible (pas nécessairement justifié) pour les testeurs de vouloir tester les correctifs «Ceteris paribus» (toutes «autres» choses égales par ailleurs).

Il pourrait y avoir d'autres préoccupations concernant le mode de publication et les attentes des utilisateurs finaux. Par exemple, vous devrez peut-être publier uniquement après une itération de corrections de bogues + tests et une nouvelle fonctionnalité + tests, car les utilisateurs souhaitent UNIQUEMENT réinstaller ou mettre à niveau lorsqu'il existe de nouvelles fonctionnalités. Certains pourraient exiger des correctifs comme priorité absolue dès que possible.

Vous pouvez résoudre ce problème (courant) en fusionnant les deux équipes.

Les testeurs au sein de l'équipe de développement, les tests au fur et à mesure que les fonctionnalités sont produites, peuvent aider la plupart des équipes à améliorer la qualité de la sortie.

Je vous suggère de lire cet excellent article de blog d' Henrik Kniberg qui explique Kaban . Vous trouverez de nombreuses idées dans le processus Scrum (un livre gratuit également par Henrik Kniberg ).

Il a également écrit un excellent article Kanban VS Scrum sur son blog.

Prendre plaisir.

L'équipe de test a certainement une préoccupation valable, mais je remets en question la nécessité de plusieurs itérations de test pour chaque version. Pourquoi passer par une série complète de tests sur une version de code que les utilisateurs ne verront jamais?

Si les testeurs tentent d'obtenir une version définie pour un client, qui n'attend pas les nouvelles fonctionnalités, leur demande est raisonnable, justifiée et vous devez vous pencher en arrière pour la livrer.

Si c'est juste pour aider dans leurs "processus" pendant les phases de développement normales, et pour s'assurer que la liste des bogues ne soit pas hors de contrôle, sans en faire un problème, demandez au responsable des tests si cette contrainte peut être assouplie un peu jusqu'à on se rapproche du point de sortie.

Pensez à changer votre système de contrôle de code source en un produit distribué. Cela facilitera la livraison d'une telle version.

"Pouvez-vous être d'accord s'il s'agit d'un principe de test commun.

Yes

La préoccupation de l'équipe de test est-elle valable

Yes

Avez-vous rencontré cela dans la pratique dans votre projet. "

Yes

:

and Yes Merging is the downside of it 

Vous n'avez pas demandé qui en est responsable, mais c'est la responsabilité de Configuration Manager. Cette stratégie de flux devrait être dans son CMP. Sinon, renvoyez-le. Je pense que la réponse de Pierre 303 est également très bonne mais bien sûr si possible techniquement (par exemple en pensant à une version Siebel ...) et organisationnelle.

Le problème est que s'ils testent les bogues sur une branche, ils doivent encore retester et régresser les tests sur le tronc une fois qu'ils sont fusionnés (à moins qu'ils ne fassent très confiance aux bons testeurs rarement). Cela ne fait pas que travailler davantage pour les développeurs, cela fait plus de travail pour les testeurs.

Il n'y a pas de bonne réponse ici mais quelques points à considérer:

• Ces versions de bogues (sans la nouvelle fonctionnalité) pourraient-elles jamais aller aux utilisateurs? Si c'est le cas, alors oui, il doit être ramifié et testé et tout le monde doit l'accepter comme une surcharge.

• Est-il possible de diviser la nouvelle fonctionnalité de telle sorte qu'elle existe dans des zones entièrement distinctes de l'application aux blocs précédents qui ont été travaillés? Si tel est le cas, cela vous donne des options - les testeurs peuvent effectuer les nouveaux tests de bogues et les parties de test de régression de l'application. Ce n'est pas idéal, mais c'est un compromis qui pourrait fonctionner et leur donner une partie de ce qu'ils veulent.

• Combien de travail est-ce vraiment de leur proposer une version? En général, c'est une douleur, mais la quantité réelle de travail n'est généralement pas si grande. De toute évidence, vous en auriez besoin pour confirmer que ce n'est pas seulement plus de travail pour eux aussi (voir la toute première chose que je dis), mais j'ai vu des endroits faire ce travail.

• Y a-t-il une meilleure façon d'utiliser le contrôle de version ici? Quelque chose comme Mercurial (voir http://hginit.com/ - lisez-le, c'est bien) ou un autre système de contrôle de version distribué se branche et fusionne d'une manière différente et peut vous permettre de contourner le problème. Vraiment, jetez-y un œil car je pense que cela pourrait être la réponse à votre problème.

Mais bonne chance, c'est pénible. Surtout, n'oubliez pas que la meilleure façon de progresser dépendra beaucoup de votre entreprise, de votre produit et de votre situation, alors pensez-y et ne vous contentez pas de retirer quelque chose de l'étagère et de croire que vous devez y adhérer à 100%.

Si les bogues que vous décrivez sont des défauts réels et non des optimisations de conception , alors oui, vous devriez vraiment essayer de les corriger avant de commencer à travailler sur de nouvelles fonctionnalités.

Si vous créez de nouvelles fonctionnalités en plus des bogues connus, vous créez un château de cartes. Vous pouvez probablement développer des logiciels fragiles et imprévisibles. Selon le niveau d'isolement entre le code buggy et vos nouvelles fonctionnalités, les bugs peuvent également avoir un impact sur vos nouvelles fonctionnalités. Si oui, comment sauriez-vous si vos nouvelles fonctionnalités fonctionnent correctement?

Si vous corrigez d'abord vos bogues, vous aurez une base plus solide pour toutes les nouvelles fonctionnalités que vous ajoutez.

Certes, il y a des moments où des forces extérieures vous poussent à aller à l'encontre de votre meilleur jugement. Essayez d'aider les décideurs à prendre une décision éclairée lorsqu'ils sont conscients des conséquences de l'une ou l'autre des mesures (c.-à-d. Défauts non résolus par rapport aux dates de livraison des fonctionnalités manquées) et leur permettre d'exercer leur jugement. Il y a parfois des raisons juridiques et financières pour lesquelles une ligne de conduite, bien que non préférable, est nécessaire.

Essayez toujours de corriger les bugs avant d'ajouter de nouvelles fonctionnalités!

Là où je travaille, nous gérons ce scénario où chaque version prévue pour la production a sa propre branche. Par exemple, supposons une seconde qu'il y aura une sortie fin juin et une autre fin juillet. La version de juin aurait sa propre branche, et toutes les fonctionnalités y seraient ajoutées et envoyées à QA. À ce stade, nous commencerions à travailler sur la version de juillet et à créer une branche à partir de la branche de juin. Lorsque QA trouve des bogues, nous les corrigeons dans la branche de juin et une fois que les correctifs ont été poussés vers QA, ils sont fusionnés dans la branche de publication de juillet. Cela ajoute un peu de surcharge pour gérer ces fusions, mais généralement les fusions sont assez indolores. De temps en temps, il est très difficile de savoir quoi, mais cela ne se produit que lorsque des changements en gros sont effectués, et ceux-ci ne devraient pas se produire pendant le cycle d'AQ (mais ils se produisent, plus que j'aime l'admettre). Mais avec une bonne suite de tests (unitaires et d'intégration), et une couverture de code et tous les autres mots à la mode TDD, les risques sont un peu atténués. Pour vous aider, nous avons généralement une personne qui gère les fusions pour chaque projet.