Comment identifier un bon projet logiciel ?

J’écris cet article en réaction à ce qui est arrivé à des amis, à savoir qu’ils ont été « invités » à passer le week-end au boulot à l’occasion d’une mise en production. Et contrairement à ce qu’on pourrait penser ça se passe dans une entreprise où le vulgus pecum pourrait s’attendre à un maximum de rigueur… et où tout est fait de bouts de ficelle. Bref l’idée est de donner les moyens d’identifier si le projet logiciel sur lequel vous intervenez est bon… ou pas.

Débloque les + belles offres tech en 10 mins

La principale chose à savoir est qu’un bon projet logiciel est un projet dans lequel on a confiance. Autrement dit si demain on demande une mise en production vous pouvez la faire sans souci et sans bosser jusqu’à 2h du matin. Et pour ça il y a des règles assez simples à respecter.

Testez, testez, testez !

Ça tombe sous le sens et pourtant beaucoup de gens ne le font pas, soit par flemme soit à cause de la pression. Ou encore parce que le management a décrété que tester c’est douter donc seuls les tocards le font. La réalité est qu’un bon logiciel doit être testé en permanence, et comme ce n’est pas possible de le faire manuellement il faut le faire automatiquement à chaque changement dans le code.

Pour ce faire on ne peut clairement pas compter sur les humains, car entre les oublis et la précipitation la suite de tests risquerait de ne pas être jouée souvent. Bref pour ça il faut encore que tout soit fait automatiquement. Ça tombe bien, les serveurs d’intégration continue sont là pour ça !

Les différents niveaux de tests

Il existe différents niveaux de tests, nous les listons ici du niveau microscopique au niveau macroscopique. Pour rappel plus on monte en niveau plus il est difficile d’avoir une couverture de code correcte, alors qu’un niveau raisonnable de couverture est de l’ordre de 80%.

1. Les tests unitaires, couvrant généralement de simples fonctions ou méthodes du code. La couverture ici doit être d’au moins 80% mais en organisant bien votre code il est assez facile d’atteindre les 90%.
2. Les tests d’intégration : il s’agit ici de valider qu’un sous-ensemble de votre système fonctionne comme prévu. Ces tests impliquent d’avoir généralement un jeu de données de référence à maintenir, et une base de données à recharger fréquemment. Le budget à prévoir n’est donc plus le même que pour les tests unitaires mais ils sont très importants.
3. Les tests fonctionnels : à ce niveau il s’agit de vérifier que des scenarii d’utilisation passent. Contrairement aux catégories ci-dessus il peut être tolérable que certains ne passent pas mais pour les tests non passants il convient de valider les choses avec les équipes métier et au besoin adapter les cas d’usage. Ces tests fonctionnels doivent correspondre à des cas d’utilisation définis sous la forme Given / When / Then. Exemple : étant donné que je suis sur telle fenêtre, quand je clique sur OK sans avoir rempli tel champ, alors je dois avoir tel message d’erreur.
4. Les tests d’expérience utilisateur : ce sont les seuls tests qui ne peuvent être automatisés. Mais normalement ils ne devraient être exécutés que si les tests précédents sont passants. Rien ne sert de dépenser du budget si ce qui doit être fait en amont ne l’a pas été.

Je ne vais pas entrer en détail dans ces différentes catégories de tests, on l’a fait ici. Néanmoins il convient de rappeler que si le management ne veut pas mettre en place a minima des tests unitaires automatisés avec une couverture de 80%, il ne peut ensuite blâmer les développeurs pour la mauvaise qualité du logiciel produit. Bref la responsabilité du management à ce niveau est de s’assurer que tout le nécessaire est là pour mettre en place les tests automatisés, en charge aux développeurs de le faire ensuite correctement. Il va également de soi que le management par la pression empêche naturellement la mise en place de tests automatisés car en cas de rush les tests sont la première chose qui passe à la trappe.

La mise en production : automatisée

N’importe quelle équipe de production vous le dira : une mise en prod’ devrait se résumer à appuyer sur un bouton et jouer à Bomberman avec les collègues le temps que ça se passe. Éventuellement on devra appuyer sur un autre bouton pour lancer la configuration. Enfin il faudra redémarrer les services, cette étape étant nécessairement manuelle. Mais si ceux-ci doivent être redémarrés dans un ordre donné un script devrait se charger de faire le redémarrage.

Un processus plus compliqué est tout simplement inacceptable, car il n’est ni répétable ni traçable. Imaginons que votre document de mise en production soit fait au traitement de texte. Une erreur est faite dans une commande : est-ce une typo dans le document ou un mauvais copier-coller ? Ce genre de souci peut causer des heures de débogage avec un stress maximal.

En fait il peut y avoir quelques exceptions quand il y a de nombreuses machines à gérer, mais là encore certains outils d’automatisation permettent de grandement simplifier le travail. Je pense notamment à Ansible qui permet de lancer la même commande à un ensemble de serveurs donnés.

Je ne vais là encore pas m’étendre sur ce qui doit être fait pour une mise en production, tout a été développé ici.

Mais là encore tout le monde a sa part de responsabilité : les développeurs qui doivent bien avoir la notion de packaging en tête, les équipes de production qui ne doivent pas à chercher à tout prix à garder leur pré carré, et le management qui doit savoir imposer ça et être loyal avec les uns et les autres, autrement dit en ne profitant pas de l’occasion pour faire sauter quelques personnes. Sinon ce qui a fonctionné pour un projet ne fonctionnera plus jamais par la suite.

En bref…

Un bon projet logiciel est un projet dans lequel on a confiance. Cette confiance ne doit pas être uniquement au niveau du produit final, mais bien au niveau organisationnel car de toute façon on n’a jamais l’un sans l’autre. Et c’est au management de mettre en place cette confiance inter-équipes, personne d’autre.

Par ailleurs ce même management doit bien comprendre qu’on ne peut pas produire immédiatement de la feature dans un projet logiciel. Il faut d’abord mettre en place un socle technique, et accepter que le développement mette du temps à démarrer. Ensuite la responsabilité est du côté des développeurs pour qu’ils mettent en place les tests automatisés, et du côté de la production de bien communiquer les attendus. Et pour que tout cela fonctionne il faut à tout prix éviter le management par la pression, et la direction doit être loyale vis-à-vis de ses salariés. Dans trop d’entreprises hélas on constate que cette loyauté fonctionne dans un seul sens…

Débloque les + belles offres tech en 10 mins

Cet article vous a plu ? Vous aimerez sûrement aussi :

• Les mises en production
• La démarche DevOps
• a href= »/fr/articles/les-tests-automatises/ »>Les tests automatisés

Julien
Moi c’est Julien, ingénieur en informatique avec quelques années d’expérience. Je suis tombé dans la marmite étant petit, mon père avait acheté un Apple – avant même ma naissance (oui ça date !). Et maintenant je me passionne essentiellement pour tout ce qui est du monde Java et du système, les OS open source en particulier.

Au quotidien, je suis devops, bref je fais du dév, je discute avec les opérationnels, et je fais du conseil auprès des clients.

Son Twitter – Son LinkedIn