Publications de Olivier Mallassi

Méthode

Une approche de la qualité logicielle…

Posté le par Olivier Mallassi

Dans un papier pas tout récent puisqu'il date de 2003, they don't care about quality, Kathy Iberle expose un sentiment communément (en tout cas déjà par moi) ressenti: "Ils se foutent de la qualité!", "Ils" étant bien entendu les autres...
Kathy illustre ce jugement à l'emporte-pièce en comparant une définition de la qualité dans un cadre médico-légal et une autre définition de la qualité chez un fabriquant de cartouche d'encre...Deux univers, deux définitions qui lui permettent de proposer quelques clés permettant de sortir de ce concours de mauvaise foi.
Alors qu'en est-il?

Lire la suite
Brèves de consultants

Et après RIA?

Posté le par Olivier Mallassi

Le Web2.0 nous amène quotidiennement son lot de nouveautés, de nouveaux frameworks et induit un changement fort en terme d'ergonomie: nos applications web vont devoir être repensées, être "fluidifiées"...
Un petit voyage dans le futur (pas trés loin en fait...) nous ferait découvrir les WebOS.

Lire la suite
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