1st mars 2008

Software Testing: Dogmatic or Pragmatic?

As a software engineer, and particularly in the medical field, software testing is a subject I find very important, so I’d like share with you some thoughts about it.

I watched on InfoQ a debate about TDD which took place at JAOO ’07 with Jim Coplien and Bob Martin. Martin started the debate by declaring: « it is irresponsible for a developer to ship a line of code he has not executed in a unit test. »

First thought: of course! We, software engineers, learn by experience that code which has not been executed (tested) cannot be considered working (understand: should be considered not working). So yes, Martin is right. We tend to like clear and straight statements, because they are easy to understand and agree with: yes, every line of code should be executed in a unit test. But when you think of it, there are several problems with this:

  • Is it because a line has been executed in unit test that it is properly tested? Read: 100% code coverage in terms of executed line of code is not that meaningful in itself: I can write 100% coverage tests and still ship buggy code.
  • (Assuming you write meaningful tests:) What is the cost of writing unit tests to achieve this 100% coverage? And is the cost justifiable, does it really add value for the customer?

Recently, I also read this article on Javalobby: Practical Unit Testing. And I liked it, because it is more balanced and reflected than the single statement of Martin.

In fact (and this is the tricky problem in software testing): the most meaningful test is the most difficult to write. To take a practical example: in my organization, (a year or two ago) we’ve been an using automated test tool called Agitator (by Agitar Software; note that it is now part of a tool called AgitarOne). This tool basically automatically generates tests based on Java code and allows you to « agitate » your code, that is, run methods with all sorts of arguments, to try finding bugs. The problem is if you agitate your code « randomly », at best, you find trivial bugs such as lack of null-checking etc. On the other hand, if you want to use the tool in a meaningful way, you need to spend a lot of time creating mock classes and test datasets, to introduce domain knowledge in your tests (which the tool does not have). Whether you do it using using a tool such as Agitator, a xUnit framework, or manually, this effort is not going to change a lot. (I’m not saying you should not use a tool, but don’t think using a tool will substantially reduce the effort of writing meaningful tests).

The goal of software testing is simple to understand: ship bug free code. But it is extremely difficult to achieve due to the gigantic size of the search space. And it is therefore difficult to give good advices on how to do that in practice. In my opinion, we ought to be very careful with dogmatic statements, and always ask ourselves how to increase test efficiency (increase pay-off for the effort spent in writing tests), rather than increase test coverage.

posted in Opinion, Software | Comments Off on Software Testing: Dogmatic or Pragmatic?

4th novembre 2007


I just had a very interesting exchange with a friend of mine about which web technology to adopt. We were mainly comparing PHP and ASP.NET (leaving JSP, Ruby etc aside for now).

If we were to develop a medium/large size website, which technology should we choose? The interesting thing was our different backgrounds: we both studied computer engineering and learned programming at school on Unix-like systems, but after that, my friend mainly developed on Windows using Microsoft development tools, and I continued developing in Unix (actually more Linux). While his main tool is Microsoft Visual Studio, mine would be Eclipse or even… vi(m)! We really didn’t want to argue on this, so we tried to list « objective » differences and compare the pros and cons of ASP an PHP.

So we came up with general statements found randomly on the web:

  • PHP: platform independent, open-source, fast (performance), widely used, suited for small websites, MVC not well separated except when using a good framework
  • ASP: Microsoft, closed-source ;), maybe heavier than PHP but suited for large websites, good framework to separate view from model

At this point, none of us was able to say that one technology is « better » than the other.

Being used to open-source software and DIY solutions, I know PHP and have never touched ASP.NET. As for my friend, he thinks that having to type commands in a terminal is « pre-historic » and shouldn’t be needed anymore: You should be able to create your interactive website, connect to the database etc just by a few mouse clicks. And he showed me how Microsoft Visual Studio allows this. On the other hand, PHP does not have one framework like ASP.NET, it has many (I talked about Tigermouse recently, but there seem to be more mature frameworks like Symfony etc). You need to choose your framework, choose your IDE also. Can Zend Studio compete with MSVS? As far as I know, PHP does not have one simple, unified development environment, which seems to be the biggest difference between ASP.NET and PHP.

I will remain a fan of PHP and open-source solutions. But this discussion with my friend made me wonder the following: When you want to quickly develop a large application with a short time-to-market, are open-source solutions performant enough? Or are they only for the people who « have time »? The following is an excerpt of the MySQL website download page:

MySQL Downloads
MySQL Downloads

So to use open-source free products, I need time + experience, which is worth a lot of money I think.

posted in Software | Comments Off on PHP vs ASP.NET

31st octobre 2007

ScrumMaster training in Tokyo

I just attended an excellent training about SCRUM, the Certified ScrumMaster training in Tokyo. And this happens to be the first training given in Japan by the SCRUM Alliance.

The coach, Bas Vodde, told us what makes SCRUM special with respect to traditional development methods (aka waterfall), by explaining us the basic concepts underlying SCRUM. The concise SCRUM Primer, compiled by Pete Deemer and Gabrielle Benefield, is an excellent introduction.

But not only did Bas explain us how SCRUM is supposed to work, he also answered lot of practical questions such as: « how to address skeptical team or management? », « can SCRUM be applied in projects involving hardware development? », « how to handle regression testing? », etc.

Although the « rules » of SCRUM are very simple: self-managing team, potentially shippable product increment delivered in time-boxed iterations (SPRINT), customer-centric backlog driving development, inspect/adapt cycles with transparency, etc. … SCRUM seems very challenging to me if you want to implement it correctly. Because we (and our companies) are simply not used (yet) to think that way. We « like » to have managers telling people what they need to do (rather than encouraging self-management), and we always tend to go back to our old « waterfall » thinking which is really in the way to make SCRUM successful.

So what’s next? Talk about SCRUM and Agile methodologies. Get people know more about it. Start actually using SCRUM in some (pilot) project in our company. I’m really looking forward to see all this happen!

posted in Software | Comments Off on ScrumMaster training in Tokyo

27th octobre 2007

Webapps for Project Management

Recently, I tried two web applications which I’d like to briefly review.

Mindomo logoThe first one is Mindomo http://mindomo.com/ A very neat tool, which allows you to write mind maps. Try to dump the content of your brain in a Word document, it doesn’t work 😉 Try to write a mind map, there’s still a gap with what you think, but it is closer to what you (think you) are thinking… Mindomo is an excellent example of a RIA, with an easy to use interface and some pretty features (like map sharing). And it’s free….. at least for up to 7 maps (that’s obviously a big limitation…)

Teamwork Project logoAbout the other webapp I’d like to present, I’m a little less enthousiast. I am talking about teamwork project http://twproject.com/. This one has a different purpose, it is an integrated tool suite for project management. There is a downloadable version, which I didn’t try, so I am only talking about the online version. First the pros: the tools has plenty of features, including task scheduling, team communication, issue management, project overview, etc. And they say it integrates with SCRUM (to create project and sprint backlogs), but the wizard does not seem to be available in the online version (?). However, the main problem I see with this tool: it’s too slow!! (again, I’m speaking of the online version). It is not responsive (no Ajax out there? too many page refresh) and the number of clicks needed to perform simple things (e.g. add a task) is too high. Otherwise, I’d really have loved this tool…

Do you know any online project management tool you would recommend?

posted in Software | 3 Comments

16th octobre 2007

Smart developers

Aujourd’hui, je visitais le site tout nouveau de Seesmic (nouvelle boite lancée par Loic Le Meur il y a quelques jours à peine). Comme je n’ai pas encore de clé d’invitation, ce n’est pas très intéressant… Mais comme le design est sympa, je me demandais quelle techno ils utilisent.

Que fait-on dans ce cas-là? Menu « View » > « Page Source » de mon browser, évidemment (on est geek ou on ne l’est pas). Quelle ne fut pas ma surprise, en découvrant les quelques premières lignes du code HTML:

<html lang="en">

Smart developers always View Source.

This application was built using Adobe Flex, an open source framework
for building rich Internet applications that get delivered via the
Flash Player or to desktops via Adobe AIR.

Learn more about Flex at http://flex.org
// -->


« Smart developers always View Source« … Excellent!! Ca m’a fait bien rire 😉 Mais c’est bien, car je n’ai pas du chercher longtemps pour obtenir la réponse à ma question.

Je n’ai donc pas tardé à aller voir le site de http://www.flex.org. Et je dois dire que les applis qu’ils montrent dans leur show-case sont vraiment cool. Voir maintenant, étant donné que je ne connais pas du tout Flash, la difficulté de créer une petite appli. Je commence à penser qu’Ajax n’est sans doute pas suffisant si on veut faire quelque chose d’un peu « graphique ». La plupart des webapp qui offrent une GUI un peu raffinées semblent en effet utiliser Flash. Je pense a http://www.geni.com par exemple, pour l’affichage d’un arbre généalogique. Il semble par ailleurs que Yahoo! Maps utilise justement Flex. Sinon, il y a aussi Silverlight (de Micro$oft)…

posted in Software | 5 Comments

23rd septembre 2007

Tigermouse, un framework pour applications web

Cela fait quelques temps que je m’intéresse à la création d’applications web.

Parmi les plus connues aujourd’hui, il y a la « suite Google »: gmail, google docs, google spreadsheets, et (lancée récemment) google presentations. De merveilleux exemples d’applications web, qui à la différence d’un simple site web offrent les fonctionnalités d’un logiciel avec un browser comme GUI. Techniquement, cela fait longtemps que les webapp auraient pu voir le jour, en utilisant la technologie des applets Java, mais plusieurs facteurs (selon moi, entre autre: le fait qu’il faille installer Java, la lourdeur des applets, etc) ont ralenti leur développement. Aujourd’hui, AJAX semble remédier à certains de ces problèmes, et permettra peut-être aux webapp de se multiplier. AJAX couplé à Flash pour les applications gourmandes en graphismes (p.ex. google maps ou geni.com), permet de faire autant si pas mieux que les applets, et fonctionne dans tout browser « moderne ».

Bref, je voulais donc me lancer dans la programmation d’une webapp, et ai commencé à rechercher une technologie adaptée pour la partie serveur. Je vois au moins les choix suivants: J2EE (JSP, Servlets…), PHP, ASP… Quelles technologies les « grands » utilisent-ils? (Google, e-Bay, Amazon, YouTube, …) J’ai lu (ici) qu’e-Bay serait passé à J2EE, mais que cela n’aurait pas vraiment été un succès… Et ailleurs, la rumeur que google et amazon utiliseraient LAMP pour leurs gros serveurs… Si quelqu’un a des infos intéressantes dans ce domaine, je suis preneur.

J’ai commencé par explorer la piste PHP (qui me semblait plus « lightweight » pour commencer, que J2EE). Je cherchais un framework PHP qui me permettent d’implémenter une webapp de façon élégante; une bonne approche me semblait être le MVC (Model View Controller). Après quelques essais (j’ai exploré quelques frameworks listés ici), je suis tombé sur Tigermouse, qui m’a séduit par sa simplicité, et la « pureté » de son implémentation du MVC. Le code est extrêmement bien documenté, et répondait assez bien à mes attentes: en quelques lignes, on peut vraiment créer une webapp PHP/AJAX sans avoir à écrire une ligne de Javascript. Tigermouse me semble vraiment prometteur, même s’il manque encore de maturité pour l’instant.

Voilà le résultat de mes pérégrinations.  Pour les geek qui ont suivi jusqu’ici, je serais content de lire vos réactions.

posted in Software | 1 Comment

31st janvier 2007

JaSST ’07 à Tokyo: compte rendu

Hier et aujourd’hui, j’ai participé au JaSST ’07 à Tokyo (Japan Symposium on Software Testing in Tokyo) qui eu lieu dans le prestigieux hôtel de « Meguro-Gajoen » (目黒雅叙園). Voici donc un bref compte rendu.

Jour 1 (mardi, 30 janvier 2007):

La plus grande partie de la journée fut consacrée à l’exposé d’Edward Yourdon, qui consista essentiellement en un résumé de son: « Death March: how to survive mission impossible projects ». Le matin, pour le speech principal du Symposium, Yourdon présenta les chapitres 1 à 3 du livre:

  • Qu’est-ce qu’un projet « marche de la mort », et pourquoi diable se lance-t-ton dans une telle aventure? Son message est que la plupart des projets de développement logiciel sont essentiellement des « death march » (càd des projets dont certaines contraintes telles la durée, les effectifs, le budget, les fonctionalités requises, dépassent de plus de 50% les contraintes d’un projet « normal »)…
  • Le problème numéro 1 des « death march »: la politique. Autrement dit, ce qui cause le plus souvent l’échec d’un projet de développement logiciel sont les incessantes batailles politiques entre management, clients, et autres acteurs.
  • Le second majeur problème est celui des négociations: souvent un projet se transforme en « marche de la mort » lorsque le chef de projet échoue dans les négociations de compromis entre différentes composantes (durée, coût, resources, etc.).

L’après-midi, j’ai choisi d’entendre la suite de l’exposé d’Edward Yourdon (il s’agissait d’une session spéciale payante, mais puisque mon boss m’a permis d’y participer…). Il a présenté les chapitres 4 à 6 (et un peu du reste) de son livre:

  • Autre problème important d’un projet du type « death march »: les facteurs humains, ou selon le terme américain « peopleware ». Yourdon a d’ailleurs mentionné à maintes reprises le livre « Peopleware » de ses amis Tom DeMarco et Tim Lister. Obtenir le droit de se constituer une équipe valable et travailler le « team building » semblent être des facteurs importants dans la réussite d’un projet « death march ».
  • Yourdon a également évoqué les méthodes et outils (« processes and tools ») utilisés au cours du projet, tout en rappelant que ce facteur était sans doute moins déterminant pour la réussite ou l’échec du projet que les composantes évoquées plus haut.
  • Enfin,si je me rappelle bien, il a parlé brièvement d’autres aspects comme la planification (selon une méthode appelée « critical chain »), le controle et monitoring du projet, avant d’aborder la « dynamique des processus » (un concept que je n’ai pas bien compris).

Mon appréciation globale des exposés de Yourdon est plutôt positive, avec un bémol cependant: j’ai regretté qu’il se contente de nous présenter le contenu de son livre (car le livre, chacun peut le lire par soi-même), sans entre davantage dans le thème du symposium: le test software. Ceci dit, le contenu du livre (que j’ai acheté il y a deux semaines sur Amazon, et que je me suis fait dédicacer par Yourdon –yey!) est très interessant, et le fait d’entendre le contenu du livre expliquè par l’auteur en personne est quand même une chance à ne pas manquer.

Enfin, pour terminer cette première journée, j’ai assisté à une session sur un sujet tout autre, le « model-based testing« . L’idée est la suivante: supposant l’existence d’un modèle (UML par exemple) d’un logiciel, il doit théoriquement être possible de générer automatiquement des tests sur base de ce modèle, de les exécuter (toujours automatiquement) et de vérifier les résultats, tout cela sans effort. Très belle théorie, mais qui m’avait l’air un peu fumeuse. Autant la génération automatique de code (au moyen de CASE tools) ne semble pas être une réussite globale, autant j’ai de sérieux doutes sur les chances de telles entreprises. Mais bon, chez Hitachi, ils payent apparemment un gars (au moins, celui qui a donné l’exposé) pour faire de la recherche dans ce domaine…

Jour 2 (mercredi 31 janvier 2007):

La première session de la journée était plutôt basique et concrète. Il s’agissait d’une sorte de saynette mettant en scène un jeune programmeur inexpérimenté, confronté à des problèmes concrets de test, qui demande conseil à trois « sages », des testeurs professionels expérimentés qui lui donnent des conseils pratiques.

Les trois « sages » étaient:

Le « jeune programmeur » leur a soumis deux problèmes, l’un concernant le test d’un tableau de bord (logiciel embarqué), et l’autre un système de vente de tickets par internet (type « entreprise »), et chacun des trois « sages » proposait une approche concrète pour tester le système en question. Suzuki était partisan de l’approche basique de « table décisionnelle » (Decision Table, DT). Akiyama partait d’un diagramme causes-effets (Cause Effect Graph, CED) mais pour construire également une table décisionnelle (réduite). Et Matsuodani lui, proposait l’approche du « diagrame de flux de causes » (Cause Flow Diagram, CFD), qui ne me rappelait rien de connu (une approche plutôt visuelle, ne me semblant pas adaptée à des problème de taille réelle).

C’était un exposé très concret et pratique, qui m’a fait prendre conscience de l’importance de revenir à la théorie pour l’appliquer dans les problèmes que je rencontre tous les jours. L’importance aussi de bien vérifier la couverture des test (« test coverage »), pas seulement des spécifications de cas nominaux, mais aussi des comportement interdits, et de la masse de comportements non couverts dans les spécifications.

La seconde session était donnée par un représentant de la firme Mercury (récemment acquise par HP), qui nous a parlé de l’importance d’une vision globale des activités de test en regard avec le cycle de développement. Depuis la définition des spécifications jusqu’aux tests d’acceptance, l’importance de planifier les tests, d’en garder la trace, de les documenter, de les monitorer, etc. Tout cela pour en arriver à la présentation de leur outil « Test Director for QC ». Un outil permettant de gérer les spécifications, de créer des cas de test, de vérifier la couverture des spécifications par les tests, d’exécuter les tests automatiquement (via un language de controle de GUI), d’enregistrer les résultats, ainsi que les problèmes survenus lors des tests. Tout ça m’avait l’air très intéressant, mis à part le fait que cela implique une dépendance totale à leur outil. Tout est intégré, mais que faire si je souhaite utiliser DOORS pour gérer mes spécifications, ou encore gérer mes bugs via Bugzilla plutôt que via leur truc?

L’après-midi, Toru Matsuodani (Debug Engineering Institute) nous parla de sa « Vision future dans le domaine du test logiciel« . Dans la pratique, on observe que tout projet software coûte 30% en développement, et 70% en test. Comment réduire le coût (relatif) du test? Selon Matsuodani, on a pendant un temps cru que l’approche visant simplement à améliorer les mèthodologies de développement (CMM, et autres) seraient suffisantes, mais apparemment cela ne change pas le coût relatif de 70% pour les tests. La raison selon lui, est que ce n’est pas en améliorant la qualitè du logiciel produit que l’on rèduira l’effort nécessaire pour le tester. En effet, l’effort de test est lié à la taille de l’espace des entrées-sorties du système, càd l’espace que les testeurs devront parcourir pour trouver les bugs. Qu’il y ait moins de bugs ne réduit pas cet espace, mais c’est en réduisant la complexité du système (p.ex en divisant le logiciel en plus petits composants) que l’on pourra réduire l’espace à parcourir lors des tests. Et cela n’est réalisable, selon lui, qu’en passant d’un design du type « facile à fabriquer » à un design du type « facile à tester ». Autrement dit, prendre en compte le problème du test dès la conception du logiciel.

Cela nous mène déjà à la dernière session de ce symposium: une table ronde mettant en scène les orateurs suivants:

  • Edward Yourdon (NODRUOY Inc.)
  • Yamaura (Tokai University)
  • Toru Matsuodani (Debug Engineering Institute)

Le thème du débat était « Taming a Monster« , càd: « Dresser un monstre », faisant allusion au « monstre des bugs » auquel s’attaque l’équipe de testeurs corps et âme. Chaque orateur avait préparé un court exposè, présentant sa façon d’aborder le problème.

Matsuodani dans son exposé très imagé, pointa l’importance de: (1) réduire les attentes des clients, du management etc; (2) augmenter la motivation de l’équipe de test/développement; et (3) réduire la complexité du logiciel à tester en « divisant pour régner ».

Yamaura, lui, parla de l’importance des compromis dans la négociation des spécifications, du « triage », de l’importance de faire comprendre au management que le coût du software en fonction des resources ne répond pas à une loi linéaire (cf loi de Putnam), et proposa d’assigner une personne seulement responsable de vérifier la couverture suffisante des tests entrepris, ainsi qu’un « gardien des spécifications ».

Enfin, Yourdon mentionna une fois de plus les problèmes politiques, l’importance de la collaboration (au sein de l’équipe et en dehors), et de la négociation de compromis, rejoignant donc l’exposé de Yamaura.

Le temps de questions-réponses fut intéressant également. On y aborda notamment les points suivants: le fait que très peu de CTO (ou CIO) deviennent CEO montre que les priorités des entreprises de nos jours sont davantages dans la finance que la technologie. Egalement, l’importance de s’intéresser au phénomène « open-source », mentionnant notamment Linux et Wikipedia.


Je ne vais plus la faire longue, juste dire que j’ai trouvé ce symposium très intéressant. Dépassant largement la discussion du test logiciel, il m’a donné envie de me plonger dans d’autres bouquins pour approfondir un tas de concepts nouveaux.

posted in Software | Comments Off on JaSST ’07 à Tokyo: compte rendu

28th janvier 2007


Cette semaine, j’aurai la chance de participer à un symposium sur le test logiciel: « Japan Symposium on Software Testing in Tokyo (JASST ’07 Tokyo)« .

Se déroulant sur deux jours, mardi et mercredi, ce symposium promet d’être intéressant, notamment car l’un des orateurs n’est autre que Edward Yourdon, un fameux consultant dans le monde du développement logiciel. Outre des centaines d’articles techniques, Ed Yourdon a également écrit plusieurs livres, dont « Death March », un ouvrage présentant des stratégies pour survivre à des projets de développement voués à l’échec (qu’il appelle de façon très imagée les « marches de la mort »).

J’attends pas mal de ce symposium et espère qu’il m’apportera des éléments d’information intéressants et concrets.

posted in Software | Comments Off on Symposium