Pourquoi automatiser mon développement logiciel?

Temps de lecture estimé: 9min

L’automatisation des processus de développement est primordiale pour consolider l’utilisation des méthodologies Agiles dans le domaine du développement logiciel. Le Scrum Guide 2020 qui vient de sortir, plus court, moins prescriptif, ne fait que renforcer ce postulat.

Le monde du développement logiciel ne cesse d’évoluer, en ayant comme but de mieux comprendre les besoins clients, gagner en stabilité et bien sûr optimiser les coûts. Les méthodes Agiles sont une bonne illustration de ce changement d’approche, impliquant plus de dynamisme et de flexibilité dans la manière de définir et modéliser les besoins clients.

Pour le rendre possible, l’équipe de développement doit se munir des bons outils et appliquer les pratiques appropriées. L’automatisation des processus y joue un rôle prépondérant.

De quelle manière l’automatisation consolide-t-elle l’approche Agile? Les en-têtes de paragraphes ci-dessous sont inspirées des valeurs de base du manifeste Agile.

L’automatisation de la compilation du logiciel, de l’exécution des tests ainsi que de son packaging, permet à l’équipe de développement de produire une nouvelle version à la demande. Le numéro de version peut aussi être généré automatiquement (par exemple, en y ajoutant le numéro de build). Chaque version est à considérer comme candidate à être installée en production.

Source: Icube SA

L’automatisation permet de valoriser la collaboration avec le client.
L’automatisation de la création d’environnements d’intégration virtuels hébergés dans le cloud permet d’accélérer la récolte du feedback client. À tout moment un système de démonstration peut être déployé et utilisé pour présenter la fonctionnalité en cours de développement, afin de récolter le plus tôt possible le feedback des intervenants.

Source: Icube SA

L’automatisation permet de s’adapter au changement.
Un projet contient plusieurs types de tests. Leur nombre est en général inversement proportionnel à leur temps d’exécution. Ensemble, ils constituent un bouclier contre la régression qui permet d’envisager sereinement de faire évoluer le système. Par ailleurs, l’isolation des environnements de développement par fonctionnalité permettent de travailler sur plusieurs fonctionnalités en parallèle.

L’identification des types de tests laisse de la place à l’interprétation et de ce fait, est constamment sujette à débat dans la communauté des développeurs. Il faut en retenir que un maximum de tests doivent être implémentés au niveau unitaire pour permettre aux couches supérieures de se focaliser sur la validation des besoins business, tout en étant confiant que les limites, les paramètres et algorithmes sont consolidés par la couche inférieure.

La complexité de l’environnement testé augmente proportionnellement à la hauteur où l’on se situe dans la pyramide. On passe plus de temps à mettre en place le système, à démarrer les tests et à les exécuter. Une gestion adéquate du nombre de tests par niveau est nécessaire.

Les types de tests en détail
Les tests “unitaires” testent les algorithmes du système. Ils ne prennent que quelques secondes à être exécutés. Le développeur les exécute également directement sur sa machine, à la demande. Ils sont aussi exécutés par l’automation.

Les tests “d’intégration” interagissent sur les composants du système. Cela signifie que le composant testé est en cours d’exécution. Plusieurs sous-groupes peuvent être identifiés:

• Les tests sur composants isolés
  • Interfaces (API)
  • Persistance
• Les tests avec plusieurs composants
  • Applicatif + base de données
  • Multiple services web
• Les tests “end-to-end” (e2e) incluant tous les composants du système, tels que:
  • Les composants en charge de la persistance
  • Les composants serveur (Backend)
  • Les composants de l’interface utilisateur (Frontend)
  • Les composants tiers (réseau, portail web, etc)

Un autre type de tests d’intégration vient se greffer dans la pyramide. Il s’agit des tests “d’acceptance” (communément AC en anglais pour “acceptance tests”) qui sont élaborés en collaboration avec le client lors de la définition des besoins, en décrivant des exemples concrets pour formaliser une compréhension commune de la fonctionnalité à implémenter. Il en résulte des scénarios composés de phrases qui sont in-fine transformées en tests automatiques.

Enfin, les tests “non-fonctionnels” (performance, scalabilité, sécurité, chaotiques) viennent s’ajouter à la liste des tests précités pouvant être automatisés.

• Dans la mesure du possible, automatiser tout ce qui peut l’être, et ce, dès le début du projet. L’investissement devient vite rentable et permet aux équipes de concentrer leur énergie à délivrer de la valeur.

• Optimiser les temps d’exécution des tests, ainsi que leur fiabilité. Comme ces processus sont amenés à être exécutés souvent, une perte de temps ou un manque de stabilité peut avoir un impact non-négligeable sur le rendement de l’équipe. Une couverture de test théorique de 80% est à envisager.

• Utiliser des outils afin de mesurer le taux de couverture de test. Si du “vieux” code est présent dans le système, investir du temps périodiquement afin de gagner en couverture et mettre la priorité sur les portions de code les plus parcourues.

•  Finalement, automatiser la gestion de la traçabilité et des rapports de test afin d’identifier les fonctionnalités impactées en cas d’échec et de réagir de manière adaptée..

Conclusion

“Ce qui est bien fait n’est plus à REfaire”
De nos jours, les tâches répétitives n’ont plus leur place dans le monde du développement logiciel. Les automatiser permet de concentrer les forces de l’équipe de développement sur ce qui apporte de la valeur au client, avec agilité, tout en préservant la stabilité de l’existant.

Choisir un partenaire qui maîtrise ce savoir-faire est la garantie d’obtenir un logiciel de qualité, évolutif, répondant précisément aux besoins clients.