Comment intégrez-vous les tests de système dans un processus agile? [fermé]

Question

Les descriptions classiques du développement agile ont un code libérable à la fin d'une itération. Si des tests et des validations supplémentaires sont nécessaires pour créer un produit libérable, comment l’intégrez-vous dans le processus?

Answer 1

Qu'est-ce qui vous empêche de créer votre propre processus? Si vous trouvez que quelque chose peut être mieux… faites-le. Si cela fonctionne, persévérez avec cela .. sinon essayez autre chose. Si vous voulez de l'agilité, il n'y a pas de processus d'installation fixe.
Le terme le plus fréquemment utilisé est " pouvant être expédié " à la fin de chaque itération. Cela signifie que vous pouvez le donner à l'utilisateur final (en tant que groupe de DLL pour copier un partage ou livrer lui-même un CD / DVD) et il obtiendra de la valeur en l'utilisant. Ce code a réussi tous les tests unitaires (développeurs) et tests de réception (clients / assurance qualité / analystes) jugés nécessaires pour qu'il soit "TERMINE!". Les tests d'acceptation sont des simulations de scénario client de bout en bout.

Je ne suis pas sûr de comprendre ce que vous entendez par "tests et validation supplémentaires". Je peux penser à d'autres activités de "pré-publication"

• certaines activités telles que "Conférences de formation". et création de contenu associé.
• Démonstrations ou déploiement sur les sites bêta pendant un mois avant la publication si les déploiements client sont rares ou impossibles à réaliser fréquemment.
• Clients, experts / services potentiels: découvrez le nouveau produit dont ils ont entendu parler.

Vous venez de l’empiler à la fin de la dernière étape de votre dernière itération (si vous êtes particulièrement pessimiste comme moi… prenez des moyennes historiques… si vous libérez plus tôt. Yay!) Donc si l’entreprise a décidé que la itération n ° 14 délimite un bon ensemble de fonctionnalités pouvant constituer une version .. Il s’agit simplement de «Ajouter n semaines» après la fin de l’itération 14. Il n’ya pas de calculs complexes ni d’incertitude à ce stade. Le point essentiel étant que les contacts avec les parties prenantes / clients, les commentaires et le maintien du niveau de qualité acceptable doivent être réguliers, il ne devrait y avoir aucune surprise de dernière minute.

Si besoin est, vous pouvez même faire un bon départ . Autrement dit, l'équipe de formation commence à travailler dès que l'équipe de développement entre dans la itération 13. Cela leur donne un mois en supposant une itération de 2 semaines .. et nous espérons que vous n’auriez pas une tonne de fonctionnalités entrant dans la dernière itération .. Donc au maximum 2 semaines après l’itération 14 et sous réserve de tous les alignements célestes / organisationnels, vous devriez avoir une libération et une pause bien méritée.

Answer 2

Commencez par reconnaître que la largeur / largeur des tests dont vous parlez augmente à mesure que le projet avance, et que le logiciel gagne en étendue et / ou en complexité. Essayer de mettre cet effort dans une itération ne fonctionne pas après une ou deux itérations à cause de cela. La règle du bien-être pour les itérations est un niveau de travail constant dans chacune, déterminé par la vitesse du projet.

Les solutions à cela peuvent alors prendre l'une des deux routes: avec ou sans automatisation. L'automatisation aux niveaux de test les plus élevés réduirait les efforts nécessaires pour exécuter les tests, ce qui rendrait le travail parfaitement à l'intérieur de l'itération, car chaque itération ne porterait que sur l'augmentation de la portée / de la complexité incrémentielle. Ce n'est pas toujours réalisable dans tous les contextes de projet, même si c'est ce que nous voulons. Surestimer l’automatisation des tests de haut niveau est un écueil que vous devez prendre au sérieux, c’est-à-dire, évitez de sous-estimer ce qu’un testeur exploratoire raisonnablement expérimenté apporte à la table.

Sans automatisation, le problème passe à un problème basé sur la gestion des tests. Des itérations de test parallèles et décalées dans le temps constituent une solution candidate. Par exemple, vous pouvez choisir de créer un arriéré de test pour les tâches de test du système, géré avec la même cadence que les itérations de développement, mais retardé ou décalé dans le temps d'une durée totale d'une itération. Cela permet aux testeurs de travailler de manière globale sur les nouvelles versions de leur propre bac à sable et sur leurs propres priorités.

Je recommanderais que les arriérés d'itération de test soient construits en collaboration avec les développeurs, tout comme les arriérés d'itération de développeur sont construits en collaboration avec les testeurs. Je recommanderais également une équipe de test possédant une expérience de l'automatisation afin de pouvoir automatiser l'ennui et travailler de manière plus exploratoire. Leur portefeuille de tests automatisés devrait augmenter à chaque itération. Ils doivent également avoir accès aux tests unitaires de développeur et pouvoir les exécuter sur les versions du sandbox de test.

Travailler en dehors de cette phase ne supprime pas le problème croissant de la portée et de la complexité du test, mais offre un mécanisme permettant de gérer cette complexité, car l'équipe crée des éléments de backlog, ajuste les priorités, en automatise, crée des listes de contrôle. , etc. en fonction de ce qu'ils pensent collectivement qu'ils devraient faire ensuite. Les chances sont qu'ils vont frapper les gros articles.

Préserver la capacité des testeurs à travailler de manière globale, à améliorer leur compréhension et à partager leurs connaissances du système par le biais de tests automatisés, tout semble valoir la peine d’être poursuivi.

Answer 3

Les tests automatisés après chaque génération automatisée vous permettent de parcourir au moins une partie du chemin.

Answer 4

Ajoutez des tests système à votre carnet de commandes de sprint (dans Scrum) ou l’équivalent.

Idem documentation utilisateur.

Answer 5

L'exécution des tests du système est généralement trop lente pour s'intégrer étroitement au développement agile. (Il existe des exceptions, par exemple, une série de tests de navigateur bien conçus peuvent ne pas être plus lents que les tests unitaires classiques.)

L’une des méthodes d’intégration consiste à créer une version du jour au lendemain ou continue, qui fonctionne tout le temps et qui peut prendre plusieurs heures pour générer et exécuter tous les tests. Si une version réussit tous les tests (test unitaire + tests système), elle devient libérable, vous pouvez livrer ce binaire ou l'instantané du code source. L'idée est de disposer de versions x de vos fichiers binaires / d'instantanés de code, de les vérifier de manière asynchrone et de fournir les versions écologiques. Cela devrait fonctionner aussi bien avec les tests de système automatisés que les tests manuels.