Publications de Olivier Mallassi

Méthode

Tester pour contruire le bon logiciel: la relève…

Posté le par Olivier Mallassi

Il y a quelques temps déjà que nous croyons aux méthodologies de développement pilotées par les tests. J'en entends déjà pester "encore un truc de geek"...Le pilotage par les tests se résume à ces deux points clés:

  • remplacer le cahier des charges, spécifications manuscrites riches, complexes et par expérience jamais complètes voire fausses du fait de l'ambiguïté du langage courant par des spécifications exécutables c'est à dire vérifiables concrètement et fournissant une réponse sans appel: "vert" ou "rouge".

  • Piloter non pas sur un "reste à faire" - concept obscur car que met on dans le "reste à faire"? - mais sur du réalisé (ie. nombre de tests passants sur le nombre total de tests prévus) représentant de facto le pourcentage du logiciel réalisé et opérationnel.

Partant de ce principe, il est nécessaire d'avoir un outil permettant aux "fonctionnels" d'écrire simplement - c'est à dire dans leur vocabulaire - les spécifications exécutables et permettant aux "managers" de piloter les développements.

Lire la suite
Archi & techno

De l’insuffisance de la couverture de tests

Posté le par Olivier Mallassi

Les besoins en terme de qualité de code amènent de plus en plus de projets à s'intéresser et à coder des Tests Unitaires. Et comme appréhender le logiciel en cours de production est complexe, des indicateurs dits "de couverture de tests" sont utilisés en complément.
Loin de moi l'idée de remettre en cause cet indicateur représentant le pourcentage de code métier exécuté par les tests. Il présente plusieurs intérêts:

  • fournir une valeur quantitative représentant la part de logiciel testé
  • fournir une visualisation (sous forme de rapport html maven ou autre) du code exécuté et surtout du code non exécuté. J'y vois là le double avantage :
  • de mieux maitriser le risque. Le code non testé est connu.
  • de permettre d'améliorer le test lui-même. En effet, du code peut ne pas être testé simplement parce qu'un cas un peu particulier a été omis et visualiser ces portions oubliées du code aide à affiner les tests. D'aucuns diront que si on fait du TDD ("Test Driven Development"), le code non testé est inutile et n'aurait donc pas du être écrit. Je peux les rejoindre dans cette approche extrême. Après, il y a la réalité des projets et du test aujourd'hui...
Reste que cet indicateur de "couverture de test" se contente de "voir" le code exécuté. That's all et ca n'est peut-être pas suffisant.

Lire la suite