Explorer les tests décalés vers la gauche
Le test dans la gestion du cycle de vie des applications est essentiel pour optimiser la qualité du code et réduire les risques opérationnels associés au déploiement et à la mise à jour de logiciels. Le terme décalage vers la gauche dans ce contexte transmet l'idée de déplacer les activités de test dès que possible dans la phase de développement. L’organisation dans notre exemple de scénario doit envisager d’incorporer cette approche dans sa stratégie DevOps afin de réduire les problèmes de sécurité et de stabilité actuels. Dans cette unité, passez en revue différents types de tests qui pourraient être implémentés de cette façon, puis examinez leurs méthodes d’implémentation.
Quels sont les tests qui doivent faire partie des tests de décalage vers la gauche ?
Le développement de logiciels intègre un large éventail de types de test, mais ceux qui nous intéressent particulièrement sont les suivants :
tests unitaires: ces tests se concentrent sur les plus petites parties testables d’un code d’application, telles que des fonctions ou des méthodes individuelles. L’objectif est d’établir si chaque unité de code peut effectuer correctement son opération prévue en isolation à partir du reste du codebase et des dépendances externes. Ces tests doivent être entièrement automatisés, rapides (complets dans les 30 secondes) et fournir une couverture de code complète (ce qui signifie essentiellement que tous les tests unitaires doivent tester collectivement l’intégralité du codebase). Les tests unitaires conviennent à l'approche décalée vers la gauche. Nous vous recommandons de l’appliquer à tout le code le plus tôt possible dans le cycle de développement, de préférence au début de la phase de programmation.
Tests de validation rapide: Ces tests sont destinés à évaluer les fonctionnalités principales d’une application dans un environnement de test. Bien qu’ils testent l’application réelle (plutôt que ses composants individuels, isolés, comme les tests unitaires), leur objectif est de déterminer si la build ou le déploiement de l’application est suffisamment stable pour justifier des tests plus approfondis. Toutefois, ils ne vérifient pas l’interopérabilité entre les applications. Comme pour les tests unitaires, ils doivent être entièrement automatisés et relativement rapides (l’interaction utilisateur peut être simulée à l’aide d’outils d’automatisation de navigateur et d’infrastructures d’automatisation de l’interface utilisateur). Le terme test de fumée est censé évoquer l'idée de la fumée qui indique un problème majeur (incendie) devant être résolu le plus rapidement possible. Les tests de fumée doivent également être implémentés tôt dans le cycle de développement, de préférence dès qu’une version du logiciel fournissant ses fonctionnalités principales est disponible. Cela s’applique aux phases de génération et de déploiement de l’application.
tests d’intégration: ces tests valident l’interaction entre différents composants d’application. Contrairement aux tests unitaires, ils peuvent prendre beaucoup de temps. La durée prolongée de ces tests est couramment utilisée comme argument pour les exécuter tôt dans le cycle de vie du développement logiciel. En général, vous devez envisager des tests d’intégration dans des scénarios pour lesquels les tests unitaires ou de fumée ne conviennent pas. Toutefois, la recommandation est de les planifier pour qu'ils s'exécutent à intervalles réguliers. Cette approche offre un compromis raisonnable entre un délai potentiel de détection des problèmes d’intégration et un délai d’attente supplémentaire nécessaire pour les terminer.
Tests d’acceptation: ces tests déterminent si un produit logiciel répond aux exigences métier et est prêt à être remis à ses consommateurs. Les tests d’acceptation ne conviennent pas à la stratégie shift-left, mais il peut être possible d’incorporer certains de ses éléments au début du cycle de vie du développement logiciel. Par exemple, les critères d’acceptation et les récits utilisateur, qui sont des composants essentiels des tests d’acceptation, doivent être introduits au début du processus de développement. Cela facilite la collaboration entre les équipes de développement, les propriétaires de produits et les parties prenantes du projet. En outre, les consommateurs de logiciels et les parties prenantes du projet doivent être engagés dans les phases de test antérieures afin de partager leurs commentaires. Cela peut impliquer l’utilisation de méthodes telles que les tests alpha ou bêta, les tests d’utilisation ou les versions anticipées, avant le test d’acceptation formel.