Comment combiner les tests manuels et l'automatisation quand on travaille en DevOps?
Le temps passe vite dans le monde trépidant du développement de logiciels. Les équipes QA et d'ingénierie ont rarement l'occasion de prendre le temps et de réfléchir à ce qui s'est passé au cours des dernières semaines ou des derniers mois. C'est exactement ce que nous allons faire dans cet article.
Un bref historique du développement de logiciels
Bien que les frameworks de développement agile, tels que Kanban, aient été inventés dans les années 1940, le modèle en cascade est resté la méthode la plus populaire pendant longtemps. Cependant, avec l'émergence de nouvelles technologies et la mondialisation des marchés entraînant une concurrence accrue, les consommateurs ont commencé à revoir leurs exigences et leurs attentes à la hausse. Dans le même temps, la durée de vie moyenne des produits a commencé à diminuer. Pour faire court : le modèle en cascade a lentement commencé à perdre du terrain.
Les méthodes et frameworks agiles ont rapidement gagné en popularité, jusqu'à devenir aujourd'hui largement utilisés dans la plupart des projets de développement de logiciels. Grâce à ceux-ci[CC1] , les entreprises peuvent réagir et s'adapter plus rapidement aux facteurs externes en constante évolution, et intégrer rapidement leurs découvertes dans leurs processus de développement. Dans un monde « VUCA » (ou VICA en français, pour volatile, incertain, complexe, ambigu), être Agile est devenu un avantage concurrentiel.
À l'heure actuelle, la majorité des entreprises (pas seulement dans le domaine de la technologie) utilisent ces méthodes. Ainsi, les entreprises espèrent être en mesure de réagir rapidement à l'évolution des besoins. Les publications fréquentes sont devenues la nouvelle norme, et le facteur vitesse a perdu son statut d'avantage concurrentiel. Quelle est donc la prochaine étape ?
Une brève introduction au DevOps
Ne nous focalisons pas sur ce que nous réserve le futur, mais plutôt sur ce qui se passe actuellement. Et la réponse est : DevOps. DevOps correspond à la capacité à garantir une disponibilité opérationnelle et organisationnelle complète, à tout moment. Il s'agit d'un ensemble de pratiques visant à automatiser et gérer la totalité des processus d'ingénierie de bout en bout entre les équipes de développement de logiciels, QA et d'opérations informatiques. Cette méthode permet à ces équipes de construire, tester et publier des logiciels de manière continue et plus fiable. Cela aide les équipes à obtenir une vision plus holistique de leurs processus internes et renforce l'approche externe et orientée vers les besoins des clients des frameworks agiles. Pour les entreprises souhaitant garantir une qualité élevée et un processus de déploiement harmonieux tout en faisant collaborer plusieurs équipes sur les mêmes produits, DevOps représente une option attrayante et moderne.
Automatisons tout !
Dans le passé, le département QA était informé dès que le développement était terminé et qu'une nouvelle version était prête à être testée, que ce soit avec les méthodes en cascade ou Agile. L'équipe QA poursuivait ses tests de régression manuels, réalisait des tests basés sur les caractéristiques pour tous les nouveaux composants et ajoutait quelques tests exploratoires. Une fois les tests terminés, le build retournait en phase de développement pour être retravaillé, ou était publié par l'entreprise.
Cette approche n'est plus viable si elle est étendue à plusieurs équipes. La nécessité de constamment jongler avec des builds différents sur plusieurs environnements intermédiaires peut entraîner une certaine confusion.
Par conséquent, les équipes QA doivent s'adapter et s'aligner davantage. Pour ce faire, voici comment procéder:
- Standardiser les environnements
- Automatiser les déploiements
- Automatiser les tests (y compris les tâches de pré-test et de post-test)
- Automatiser et regrouper les cas de test en ensembles efficaces (Smoke-Tests, suites de régression) pour obtenir une couverture de code de 100 %
- Réaliser des tests timeboxing fiables
Pour être clair, les équipes doivent automatiser autant que possible le processus de test afin de fonctionner automatiquement au besoin, de manière efficace et efficiente. L'automatisation réduit le travail manuel et rassemble les équipes QA et d'infrastructure informatique, notamment grâce à des outils spécifiques d'automatisation spécialisée et de CI/CD. En outre, un framework d'automatisation mature devient primordial pour que les équipes puissent rapidement écrire des scripts et ajouter de nouveaux cas de test.
Est-il vraiment possible d'automatiser l'ensemble du processus de test ?
Malheureusement, même s'il est possible d'atteindre une couverture de code de 100 %, vous ne pouvez jamais être sûr et certain qu'il n'y aura pas de bugs ou autres problèmes. La réponse à la question ci-dessus est donc "non", pour les trois raisons suivantes :
1. Vous ne pouvez pas tout savoir
Les cas de tests automatisés ont un réel défaut potentiel : ils sont écrits par des humains. Il ne s'agit pas d'être méchant, mais réaliste : un individu ne peut penser qu'à un nombre limité de scénarios. Et même si l'ensemble du code est couvert, les différentes manières de le traiter avec d'autres variables/données de test ou sur d'autres environnements de test peuvent le compromettre. De plus, après un certain temps, votre solide expérience peut se retourner contre vous et vous rendre aveugle sur le plan opérationnel. Il est possible que vous ne vous attendiez pas à des problèmes dans certains domaines n'ayant jamais causé de soucis. Le problème, c'est que vous ne savez pas ce que vous ne savez pas.
2. Vous ne pouvez pas tout faire
Maintenant, imaginons que vous soyez une exception et que vous connaissez tout ! (Vous faites beaucoup d'envieux, croyez-moi.) Il existe cependant des limites technologiques. Ainsi, même si vous le souhaitez, il vous sera impossible d'automatiser certains cas de test. Un exemple concret : un scénario dans lequel le téléphone doit être éteint et rallumé sans cesse. Dommage !
3. Vous ne ferez pas tout
Oh ! Vous êtes un petit malin, et avez suggéré de construire un robot qui prend en charge les interactions physiques, par exemple en appuyant sur le bouton de mise en marche continuellement à l'aide d'un capteur d'empreintes digitales. Cela pourrait fonctionner, mais tout le monde doit généralement faire face à des ressources limitées, en argent et en temps. D'une part, l'achat de tous les appareils pour effectuer les tests serait tout simplement trop coûteux. D'autre part, cette méthode prendrait beaucoup trop longtemps et, pour cette raison, bloquerait le processus.
Vous opterez donc très probablement pour une liste d'appareils à couvrir en priorité, ainsi que pour une fraction spécifique des variantes de cas test à exécuter.
En outre, les tests dans le monde réel ne consistent pas seulement à couvrir la fonctionnalité. Il y a beaucoup plus à couvrir, comme l'utilisabilité, l'intégration des paiements, la localisation, etc. dont une grande partie dépasse le champ d'application habituel du DevOps.
La clé de la réussite des tests en DevOps : trouver la bonne combinaison de tests
Le monde n'est pas noir et blanc, et le chemin du bonheur ne suffit pas toujours. En DevOps, l'automatisation est essentielle, et évoluer dans cette direction est vital pour toutes les entreprises qui cherchent un avantage concurrentiel dans le domaine du numérique.
Pourtant, la plupart des entreprises ne peuvent pas simplement automatiser tout ce qui pourrait l'être. Le risque d'échec serait trop élevé dans de nombreux domaines, tels que :
- dans les domaines non fonctionnels
- lorsqu'il existe une large clientèle avec des systèmes différents
- pour les scénarios qui n'ont pas été pris en compte lors de la rédaction des cas de test
C'est pourquoi les tests manuels, en particulier les tests exploratoires avec de vrais utilisateurs et de vrais appareils, sont un excellent complément pour s'assurer que tous les domaines et facteurs externes sont couverts.
Intégrer les tests manuels en DevOps
Le fait que le DevOps mette l'accent sur l'automatisation des processus donne l'impression qu'il n'y a plus de place pour les tests manuels. C'est faux, et comme l'illustrent les points ci-dessus, les tests manuels restent une partie très importante dans le processus de test global pour la plupart des entreprises.
Afin de trouver le bon équilibre entre les tests manuels et l'automatisation, n'hésitez pas à utiliser des indicateurs de fonctionnalités. Ces indicateurs sont utilisés pour activer, désactiver ou masquer la fonctionnalité en cours de production. Ainsi, le code peut être envoyé en production et passer par tous les processus de test et de déploiement automatisés, garantissant un haut niveau de qualité.
Ensuite, lors de la production (ou en phase intermédiaire, etc.), les indicateurs de fonctionnalités peuvent être activés pour un certain pourcentage de la base utilisateur ou pour l'équipe QA, afin que des tests manuels soient mis en place. De cette façon, des informations supplémentaires peuvent être obtenues et communiquées à l'équipe de développement. La durée de ces tests n'a pas non plus d'incidence sur les nouveaux processus DevOps et constitue, pour cette raison, un réel avantage.
Pour en savoir plus sur notre solution de tests fonctionnels intégrés, découvrez comment combiner avec cohérence les tests manuels et l'automatisation des tests.
