Stratégie de branchement Git intégrée au processus de test / QA

Question

Notre équipe de développement utilise la stratégie de branchement GitFlow et c’est génial!

Récemment, nous avons recruté deux testeurs pour améliorer la qualité de nos logiciels. L'idée est que chaque fonctionnalité doit être testée/QA par un testeur.

Auparavant, les développeurs travaillaient sur des fonctionnalités dans des branches de fonctionnalités distinctes et les fusionnaient dans la branche develop à la fin. Le développeur testera lui-même son travail sur cette branche feature. Maintenant, avec les testeurs, nous commençons à poser cette question

Sur quelle branche le testeur doit-il tester les nouvelles fonctionnalités?

De toute évidence, il y a deux options:

sur la branche de fonctionnalité individuelle
sur la branche develop

Tests sur la branche de développement

Au départ, nous pensions que c’était la voie à suivre pour les raisons suivantes:

La fonctionnalité est testée avec toutes les autres fonctionnalités fusionnées dans la branche develop depuis le début de son développement.
Tous les conflits peuvent être détectés plus tôt que plus tard
Cela rend le travail du testeur facile, il ne traite qu’avec une branche (develop) à la fois. Il n'a pas besoin de demander au développeur quelle branche correspond à quelle fonctionnalité (les branches de fonctionnalités sont des branches personnelles gérées exclusivement et librement par les développeurs concernés)

Le plus gros problème avec ceci est:

La branche develop est polluée par des bugs.

Lorsque le testeur trouve des bogues ou des conflits, il les signale au développeur, qui corrige le problème dans la branche de développement (la branche de fonctionnalité a été abandonnée une fois fusionnée), et des correctifs supplémentaires pourraient être nécessaires par la suite. Plusieurs sous-séquences commettent ou fusionnent (si une branche est recréée de nouveau sur la branche develop pour corriger les bogues), il est très difficile, si possible, de revenir à la fonctionnalité de la branche develop. Plusieurs entités fusionnent et sont corrigées sur la branche develop à des moments différents. Cela crée un gros problème lorsque nous voulons créer une version avec seulement certaines des fonctionnalités de la branche develop

Test sur la branche de fonctionnalité

Nous avons donc réfléchi à nouveau et décidé de tester les fonctionnalités dans les différentes branches. Avant de tester, nous fusionnons les modifications de la branche develop à la branche feature (rattrapons la branche develop.). C'est bon:

Vous testez toujours la fonctionnalité avec d'autres fonctionnalités dans le grand public
Les développements ultérieurs (résolution de conflit, résolution de bogues, par exemple) ne pollueront pas la branche develop;
Vous pouvez facilement décider de ne pas publier la fonctionnalité tant qu'elle n'est pas entièrement testée et approuvée.

Cependant, il y a quelques inconvénients

Le testeur doit fusionner le code et en cas de conflit (très probable), il doit demander de l'aide au développeur. Nos testeurs sont spécialisés dans les tests et ne sont pas capables de coder.
une fonctionnalité pourrait être testée sans l'existence d'une autre nouvelle fonctionnalité. par exemple. Les fonctionnalités A et B sont testées simultanément, les deux fonctionnalités ne se connaissant pas car aucune d’elles n’a été fusionnée avec la branche develop. Cela signifie que vous devrez tester à nouveau la branche develop lorsque les deux fonctionnalités seront fusionnées dans la branche develop. Et vous devez vous rappeler de tester cela à l'avenir.
Si les fonctionnalités A et B sont à la fois testées et approuvées, mais lorsqu'elles sont fusionnées, un conflit est identifié, les deux développeurs des deux fonctionnalités estiment qu'il ne s'agit pas de sa propre faute/tâche, car sa branche de fonctionnalité a dépassé le test. Il y a un temps système supplémentaire dans la communication, et parfois celui qui résout le conflit est frustré.

Ci-dessus est notre histoire. Avec des ressources limitées, je voudrais éviter de tout tester partout. Nous cherchons toujours un meilleur moyen de faire face à cela. J'aimerais savoir comment les autres équipes gèrent ce genre de situation.

Aspasia · Accepted Answer

La façon dont nous le faisons est la suivante:

Nous testons les branches après avoir fusionné le dernier code de branche développé. La raison principale est que nous ne voulons pas "polluer" le code de branche développé avant qu'une fonctionnalité ne soit acceptée. Au cas où une fonctionnalité ne serait pas acceptée après les tests mais que nous aimerions publier d'autres fonctionnalités déjà fusionnées sur develop, ce serait un enfer. Develop est une branche à partir de laquelle une libération est effectuée et devrait donc être dans un état libérable. La version longue est que nous testons en plusieurs phases. Plus analytiquement:

Le développeur crée une branche de fonctionnalité pour chaque nouvelle fonctionnalité.
La branche de fonctionnalité est déployée (automatiquement) sur notre environnement TEST avec chaque validation à tester par le développeur.
Lorsque le développeur a terminé le déploiement et que la fonctionnalité est prête à être testée, il fusionne la branche de développement de la branche de fonctionnalité et déploie la branche de fonctionnalité contenant toutes les dernières modifications de développement de TEST.
Le testeur teste sur TEST. Quand il a fini, il "accepte" l'histoire et fusionne la branche de fonctionnalités pour se développer. Étant donné que le développeur avait précédemment fusionné la fonctionnalité Développer la branche, nous n’attendons normalement pas trop de conflits. Toutefois, si tel est le cas, le développeur peut vous aider. C'est une étape délicate, je pense que le meilleur moyen de l'éviter est de garder les fonctionnalités aussi petites/spécifiques que possible. Différentes fonctionnalités doivent être finalement fusionnées, d'une manière ou d'une autre. Bien entendu, la taille de l'équipe joue un rôle dans la complexité de cette étape.
La branche develop est également (automatiquement) déployée sur TEST. Nous avons pour politique de ne jamais échouer, même si les versions de branche de fonctions peuvent échouer.
Une fois que nous avons atteint un gel des fonctionnalités, nous créons une version de develop. Ceci est automatiquement déployé sur STAGING. Des tests complets de bout en bout y ont lieu avant le déploiement en production. (ok peut-être que j'exagère un peu, ils ne sont pas très étendus mais je pense qu'ils devraient l'être). Dans l’idéal, les bêta-testeurs/collègues, c’est-à-dire les vrais utilisateurs, devraient y effectuer des tests.

Que pensez-vous de cette approche?

VonC · Answer

Avant le test, nous fusionnons les modifications de la branche develop à la branche feature

Non, surtout si "nous" est le testeur d'assurance qualité. La fusion impliquerait la résolution de conflits potentiels, ce qui est mieux fait par les développeurs (ils connaissent leur code), et non par le testeur QA (qui doit procéder au test le plus rapidement possible).

Faites que le développeur fasse une rebase de sa branche feature au-dessus de devel , et Poussez cette feature branche (validée par le développeur comme compilant et travaillant au-dessus de l'état de branche le plus récent devel) .
Cela permet:

Chaque fois que le testeur détecte un bogue, il le signale au développeur et delete à la branche de fonctionnalité actuelle.
Le développeur peut:

corriger le bug
rebase sur une branche de développement récemment récupérée (encore une fois, pour s'assurer que son code fonctionne en intégration avec d'autres fonctionnalités validées)
Appuyez sur la branche feature.

Idée générale: assurez-vous que la partie fusion/intégration est effectuée par le développeur, laissant les tests à l'AQ.

Johnny Z · Answer

La meilleure approche est intégration continue , où l’idée générale est de fusionner les branches d’entités dans la branche développeur aussi souvent que possible. Cela réduit les frais généraux liés à la fusion des douleurs.

Fiez-vous autant que possible aux tests automatisés et lancez automatiquement les versions avec les tests unitaires de Jenkins. Demandez aux développeurs de fusionner leurs modifications dans la branche principale et fournissez des tests unitaires pour tout leur code.

Les testeurs/les responsables de l'assurance qualité peuvent participer à la révision du code, cocher des tests unitaires et écrire des tests d'intégration automatisés à ajouter à la suite de régression à mesure que les fonctionnalités sont complétées.

Pour plus d'informations, consultez ceci lien .

Eric Twilegar · Answer

Nous utilisons ce que nous appelons "or", "argent" et "bronze". Cela pourrait s'appeler prod, staging et qa.

Je viens d'appeler cela le modèle du melting pot. Cela fonctionne bien pour nous car nous avons un besoin énorme d’AQ dans le domaine commercial, car les exigences peuvent être difficiles à comprendre par rapport aux techniques.

Lorsqu'un bogue ou une fonctionnalité est prêt à être testé, il passe en "bronze". Cela déclenche une génération jenkins qui pousse le code dans un environnement pré-construit. Nos testeurs (pas des super-techniciens en passant) ont juste mis le doigt sur un lien et ne se sont pas souciés du contrôle de source. Cette version exécute également des tests, etc. Nous avons déjà parcouru cette version en poussant le code dans l’environnement de test\qa si les tests (unité, intégration, Selenium) échouent. Si vous testez sur un système séparé (nous l'appelons lead), vous pouvez empêcher les modifications d'être transmises à votre environnement qa.

La crainte initiale était que nous aurions beaucoup de conflits entre ces fonctionnalités. Cela arrive si la fonctionnalité X donne l’impression que la fonctionnalité Y est en train de s’ouvrir, mais elle est assez peu fréquente et aide réellement. Cela aide à obtenir une large gamme de tests en dehors de ce qui semble être le contexte du changement. Plusieurs fois par chance, vous découvrirez comment vos changements affectent le développement parallèle.

Une fois qu'une fonctionnalité passe le contrôle de qualité, nous la déplaçons en "argent" ou en mise en scène. Une construction est exécutée et les tests sont exécutés à nouveau. Chaque semaine, nous transmettons ces modifications à notre arbre "or" ou à notre arbre de production, puis nous les déployons dans notre système de production.

Les développeurs commencent leurs modifications à partir de l'arbre d'or. Techniquement, vous pourriez commencer par la mise en scène, car celles-ci augmenteront bientôt.

Les correctifs d'urgence sont placés directement dans l'arbre d'or. Si un changement est simple et difficile à contrôler, il peut passer directement en argent, ce qui aboutira à l’arbre de test.

Après notre publication, nous plaçons les modifications de gold (prod) à bronze (test) juste pour que tout soit synchronisé.

Vous voudrez peut-être rebaser avant de placer votre nom dans le dossier intermédiaire. Nous avons constaté que la purge de l’arbre de test de temps en temps le maintient propre. Il arrive parfois que des fonctionnalités soient abandonnées dans l'arborescence de test, en particulier si un développeur s'en va.

Pour les grandes fonctionnalités multi-développeurs, nous créons un référentiel partagé séparé, mais nous le fusionnons dans l'arborescence de test de la même manière lorsque nous sommes tous prêts. Les choses ont tendance à rebondir du contrôle qualité, il est donc important de garder vos ensembles de modifications isolés afin que vous puissiez les ajouter, puis les fusionner/écraser dans votre arborescence intermédiaire.

"Baking" est aussi un bel effet secondaire. Si vous avez des changements fondamentaux que vous souhaitez laisser reposer pendant un moment, il existe un bel endroit pour cela.

Gardez également à l'esprit que nous ne conservons pas les versions antérieures. La version actuelle est toujours la seule version. Même dans ce cas, vous pourriez probablement avoir un arbre de pâtisserie principal où vos testeurs ou votre communauté pourront voir comment les différents contributeurs interagissent.

NateGreat8 · Answer

Je ne compterais pas uniquement sur les tests manuels. J'automatiserais les tests de chaque branche avec Jenkins. J'ai configuré un laboratoire VMWare pour exécuter des tests Jenkins sur Linux et Windows pour tous les navigateurs. C'est vraiment une excellente solution de test multi-navigateurs et multi-navigateurs. Je teste fonctionnel/intégration avec Selenium Webdriver. Mes tests de sélénium fonctionnent sous Rspec. Et je les ai spécialement écrites pour être chargées par jRuby sous Windows. Je réalise des tests unitaires classiques sous Rspec et des tests Javascript sous Jasmine. J'ai configuré les tests sans tête avec Phantom JS.