Libérer plus rapidement sans défauts : le jeu de l'automatisation

L'augmentation de la fréquence des versions aide les entreprises à accéder plus rapidement au marché, mais cela s'accompagne de son lot de défis. Cet article examine ce qui a changé dans l'industrie et comment l'automatisation peut accélérer les cycles de publication et garantir des conditions de concurrence équitables pour tous les membres de l'équipe, y compris les tests.

Réduire les délais de mise sur le marché est une décision commerciale dont la logique repose sur la concurrence, la demande des clients, la situation économique, les exigences de conformité ou de sécurité, ou une combinaison de tout cela. Le marché dicte les règles, ce qui a un double impact sur le monde du logiciel. Il existe une opportunité pour les start-ups d'émerger et de répondre à la demande tandis que la pression sur les acteurs du marché existants augmente de façon exponentielle, de minute en minute.

Quand nous àStudio d'essaisParlez aux clients et demandez-leur les raisons de la décision d'introduire l'automatisation des tests, nous obtenons encore et encore la même réponse, presque à chaque entretien :Nous devons publier plus rapidement, plus tôt et plus fréquemment et répondre aux attentes des clients, des parties prenantes ou du marché.

Cependant, l'augmentation de la fréquence des cycles de publication augmente le risque de défauts de production, ce qui n'est pas idéal. Avec les cycles de mise sur le marché extrêmement rapides et la demande croissante de qualité, le plus grand défi des tests de logiciels est de suivre le rythme de développement des logiciels.

Dans cet article, nous étudierons ce qui a changé dans l'industrie et comment l'automatisation aide à créer des conditions équitables pour tous les membres de l'équipe, y compris les tests.

Les 3 pièges des tests logiciels

Il existe plusieurs aspects non techniques apparemment basiques et pourtant importants des tests de logiciels où les gens échouent. Les reconnaître et prendre les mesures appropriées est la première étape du voyage.

Manque de stratégie de test et de priorisation

En réalité, vous n'avez jamais le temps de tout tester et de couvrir tous les scénarios possibles. Avec la fréquence de publication accrue et les cycles de publication plus courts, la plupart des équipes peuvent à peine tester les fonctionnalités essentielles, voire de base, pour les régressions.

Si vous souhaitez minimiser le nombre de bogues critiques glissant dans la production, vous devez planifier très soigneusement ce qu'il faut tester, quand le tester, qui charger de le tester et de quels outils vous avez besoin.maximiser les testset relâchez avec succès, aussi souvent que nécessaire.

Ne pas sélectionner les outils de test appropriés

De nombreux testeurs et ingénieurs moins expérimentés s'égarent en croyant que l'automatisation peut résoudre et résoudra tous leurs problèmes. L'automatisation des tests est indispensable pour la plupart des projets de test, mais après tout, ce n'est qu'un outil. Pour réussir les tests, les équipes doiventévaluer et choisir le bon ensemble d'outilsen tenant compte de leurs compétences et de leur expérience ainsi que des spécificités du projet ou de l'application testée.

Souvent, ils finiront par automatiser seulement une partie des scénarios de test et les exécuter dans leurs pipelines CI/CD en combinaison avec des tests exploratoires effectués manuellement. Oui, il y a et il y aura toujours besoin d'unbonne proportion de tests manuelsinstallé comme une porte de qualité supplémentaire, et c'est la bonne façon d'aller de l'avant.

Mauvaise communication

Que ce soit pour comprendre les exigences des fonctionnalités, les scénarios utilisateurs, les spécificités des applications, la morphologie des bugs, ou simplement pour obtenir l'aide d'un collègue développeur sur certains problèmes d'automatisation, la communication est un élément clé pour la réussite de l'ingénieur de test moderne.

Cela semble clair, mais on voit tellement de cas de fragmentation d'équipe où une simple conversation de cinq minutes aurait pu faire gagner des heures de travail. Sans oublier d'avoir mis en place des processus appropriés pour surveiller les résultats, partager les commentaires,signaler et corriger les bugsqui relève également de la communication.

Un autre aspect intéressant ici est de comprendre l'importance des tests et d'allouer suffisamment de temps aux opérations de test. Surprenant ou non, les ingénieurs de test dont nous parlons se plaignent que les tests sont toujours sous-évalués et traités comme un goulot d'étranglement par les propriétaires de produits ou les responsables de niveau supérieur. Par conséquent, bien communiquer et mettre en valeur le rôle des tests est vital pour le succès de tout projet de test.

Construire des portes de qualité dans vos pipelines

À condition que nous ayons exclu les pièges évoqués ci-dessus, tout se résume à la question de savoir comment accélérer les cycles de publication et augmenter la fréquence des publications sans sacrifier la qualité (et la sécurité).

Concentrez-vous sur les petites versions

Notre expérience montre qu'il n'y a pas de formule magique applicable à toutes les organisations. Mais s'il y en a une qui a fait ses preuves, c'est de se concentrer sur les petites versions, soutenues par des builds et des intégrations fréquentes, voire continues.

Diviser le travail en bits et expédier ces bits dans des délais courts, voire égaux, a ses avantages : la charge de travail est gérable, les ressources sont réparties en fonction des priorités, il est beaucoup plus facile d'éviter la densité des ressources et les pics de capacité, tandis que les équipes reçoivent un retour d'information en temps opportun. afin de prévenir les problèmes avant qu'ils ne surviennent.

Ajoutez des vérifications automatisées à vos pipelines

La pratique CI (intégration continue) consistant à extraire fréquemment le code source du référentiel pour compiler les étapes de liaison nécessaires à la création complète d'un logiciel a gagné en popularité dans l'industrie pour une raison, ce qui a entraîné l'évolution du CD (déploiement/livraison continus) .

Pousser ces builds fréquents de CI vers des environnements déployables appropriés où d'autres vérifications automatisées peuvent être effectuées garantit que le code qui ne passe aucune des différentes portes de qualité manuelles ou automatisées (tests unitaires, tests de build et d'intégration, bout en bout automatisé ou tests d'API, analyse de code statique, tests de régression ou exploratoires, etc.) n'avance pas plus loin dans le pipeline de livraison.

Ces concepts de CI/CD ont été créés et promus en premier lieu pour atténuer les risques dans des environnements où les équipes ne fusionneraient ou n'intégreraient pas traditionnellement des éléments de travail pendant de plus longues périodes, jusqu'à des mois parfois.

L'idée de petites versions fréquentes n'est pas nouvelle, mais la façon dont les organisations la gèrent dans la pratique évolue. Ce qui manquait depuis trop longtemps, mais qui gagne lentement du terrain, c'est leintégration de l'interface utilisateur ou des tests de bout en bout dans le pipeline CI/CD . Et c'est la seule voie à suivre en matière de qualité et de sécurité.

Tout le monde a un siège à la table DevOps

Intégrer des builds plusieurs fois par jour ne suffit pas à lui seul à accélérer les releases et à garantir la qualité du logiciel. L'inclusion de portes de qualité supplémentaires dans le cadre du processus d'automatisation est ce qui fait passer l'assurance qualité au niveau supérieur –tests d'intégration continue – ou, par souci de simplicité, nous l'appellerons test continu. Recevoir des commentaires plus tôt dans le processus aide chacun à mieux comprendre ce qui est en cours de construction et garantit que l'équipe dispose des instruments et des informations appropriés pour faire le travail et atteindre ses objectifs.

Décalage vers la gauche pour faire assez de place pour les tests

Adopter un état d'esprit « décaler vers la gauche » pour introduire les tests plus tôt dans le cycle de livraison aide à résoudre les problèmes avant même qu'ils ne surviennent, ce qui est l'un des principes fondamentaux derrière DevOps et DevSecOps.

Le déplacement vers la gauche implique un effort continu pour remplacer la pratique traditionnelle des tests après avoir terminé tout le développement en exécutant un ensemble de tests après l'intégration de chaque build. Ici, nous ne voulons pas nous limiter aux tests unitaires ou d'intégration, qui font traditionnellement partie du processus de développement et constituent un élément très important pour garantir que le code fait ce qu'il doit faire.

Cependant, dans les applications destinées aux utilisateurs finaux, et pas seulement, il est extrêmement important de s'assurer que les fonctionnalités critiques du site Web ou de l'application sont couvertes et que les régressions ne se produisent pas après le déploiement d'un nouveau morceau de code. En utilisant un serveur de build, les utilisateurs peuvent exécuter des tests statiques et dynamiques 24 heures sur 24 pour surveiller la qualité de la build, ce qui donne souvent un aperçu de la santé globale de la version, non seulement avant la sortie, mais chaque fois que ces informations sont nécessaires et peuvent aider à améliorer les choses. .

Outils de test : le bon cocktail de vitamines

Les outils de test offrent aujourd'hui une sorte d'intégration avec les plates-formes CI/CD populaires telles qu'Azure DevOps, Jira, Jenkins, Bamboo, TeamCity et autres. Lorsqu'il s'agit d'intégrer l'automatisation des tests d'interface utilisateur dans CI/CD, il est important de pouvoir planifier des tests et de les exécuter à distance, souvent dans le cadre de builds nocturnes.

C'est la seule façon de faire de la place pour les tests dans le cadre du concept de livraison continue et d'éviter les goulots d'étranglement inutiles. Ici, la clé est la stabilité de l'automatisation des tests. Faire en sorte que des tests aléatoires interrompent la construction nocturne, lorsque la vitesse est critique, est la dernière chose qu'une équipe de développement souhaiterait. Cependant, l'automatisation des tests progresse assez rapidement en offrant une solution – en fait, plus d'une.

Test sans tête est l'un des meilleurs amis de DevOps. Il garantit que le rendu de l'interface utilisateur d'un navigateur n'entraînera pas l'échec de la suite de tests en éliminant simplement la nécessité d'exécuter le test dans un navigateur traditionnel. Si la vitesse est aussi critique qu'il y paraît, plus un pour les tests sans tête, ce qui peut accélérer l'exécution des tests trois fois et au-delà.

La pyramide des tests

S'il y a une chose sur laquelle ce modèle continue d'avoir tout à fait raison, c'est que plus le processus de livraison se rapproche du sommet de la pyramide, plus il est essentiel de s'assurer que les transactions commerciales qui se déroulent via l'interface utilisateur de l'application fonctionnent de manière transparente.

L'interface utilisateur a un impact énorme sur la façon dont vos clients atteindront leurs objectifs en interagissant avec votre application. Plus haut dans la pyramide signifie une plus grande valeur des tests effectués, mais cela implique également une augmentation des coûts, que les organisations doivent prendre en compte et intégrer dans la planification des ressources, la budgétisation, etc. Oui, la qualité coûte cher, mais permet aux défauts de se glisser dans la production. en raison des économies de coûts est, pour la plupart, une entreprise risquée.

Le rôle de l'automatisation dans la sécurité

En matière de sécurité, la complexité augmente. La sécurité nécessite de disposer d'un processus d'assurance qualité clair et facilement traçable, ce qui, pour certaines organisations qui opèrent sous des lois gouvernementales strictes, peut même impliquer une conformité totale et une préparation à l'auditabilité. Toutes les plates-formes CI/CD offrent une sorte de fonctionnalité de piste d'audit avec des contrôles de sécurité conformes aux meilleures pratiques sur les tâches exécutées par qui et à quel moment.

L'inclusion d'informations sur les tests automatisés qui ont été intégrés dans le pipeline CI/CD est généralement également prise en charge par certains des outils logiciels d'automatisation propriétaires, permettant aux organisations de contrôler et de documenter leur processus, y compris les problèmes de sécurité/conformité, et de disposer d'informations critiques sur la santé de leurs produits et procédés.

L'automatisation offre des pistes d'audit, une couverture de conformité et une élimination des risques pour toutes les tâches et étapes impliquées dans la création, le test et le déploiement de logiciels.

Sommaire

Il faut plus qu'un bon raisonnement pour intégrer les tests d'interface utilisateur dans CI/CD et DevOps. Cela demande du temps et du dévouement. Heureusement, la plupart des entreprises ont largement dépassé le stade de la réflexion. Le fait qu'il ait sa propre discipline appelée QAOps parle de lui-même. Avec le bon ensemble d'outils, il est non seulement possible mais pratique que QAOps puisse générer des résultats formidables, affectant à la fois la vitesse de publication et la qualité des logiciels, et, en fin de compte, réduire les délais de mise sur le marché.