Forum Logiciel

Après les résultats d’un premier sondage sur l’automatisation des tests fonctionnels, Methods & Tools s’est demandé qui en avait la responsabilité au sein du département informatique. Voici les réponses:

Des développeurs : 15.4%
Des testeurs spécialisés : 37,4%
Les deux: 36,2%
Personne, les tests fonctionnels sont faits par les utilisateurs : 11.0%

Participants : 409
Source: Methods & Tools

Pour près de 50% des participants, les développeurs ne sont pas impliqués dans les tests fonctionnels. Les questions posées sur des réseaux sociaux professionnels pour connaître les causes de cette situation ont donné deux réponses.

Les développeurs ne maîtrisent pas les outils de tests fonctionnels. Ceux-ci utilisent pour la plupart un langage propriétaire, même si de nouveaux outils comme ceux de la famille WatiX permettent de créer des tests dans le même langage que celui utilisé pour la programmation. Ensuite, la validation doit être indépendante du développement. Les rôles d’analyste et de testeur fonctionnel peuvent être combinés, mais on ne peut pas demander à un développeur de valider son propre travail.

Cette situation est représentative de la défiance qui existe souvent entre les équipes de développement et celles de contrôle qualité. Pour ces dernières, les développeurs sont des personnes peu consciencieuses qui se contentent d’écrire du code le plus rapidement possible sans se préoccuper de la qualité. Pour les développeurs, les équipes de tests sont déconnectées de la réalité des projets et ralentissent la livraison du code à l’utilisateur. Ces constatations sont malheureusement vraies des deux côtés dans de nombreux cas. J’ai rencontré pleins de développeurs qui ne cherchaient pas à remettre en cause leurs créations et des équipes de contrôle qualité trop attachées à produire des processus de validation qui étaient très jolis en théorie mais qui en pratique n’ajoutaient aucune valeur à la chaîne de production.

Ressources
Functional Testing Tools Directory

SQAZone.net

Testing TV

BlogsDeDéveloppeurs.com est un aggrégateur de flux RSS de blogs individuels, de sociétés et d’associations francophones qui traitent du développement informatique: programmation (Java, .NET, PHP, Javascript, Ruby, etc.), gestion de projet, assurance qualité, méthodes et processus de développement (Agile, Scrum, Merise, UML). Son objectif est de partager sur un seul lieu (et avec un seul flux RSS sortant) les connaissances sur ce domaine.

Au cours de ma carrière dans le monde du développement informatique, j’ai vu de Merise à Agile de nombreuses approches ou méthodologies utilisées dans différentes organisations. Lorsqu’une nouvelle (meilleure naturellement) approche est diffusée, ceux qui l’adoptent ont tendance à avoir une attitude proche du zèle religieux. Les éditeurs de logiciels ont d’ailleurs constaté ce phénomène et emploient des « évangélistes produit ». Dans cette situation, les nouveaux convertis ont tendance à rejeter tout ce qui a été fait auparavant et adoptent une attitude « ceux qui ne sont pas avec nous sont contre nous », spécialement lorsque la nouvelle approche est encore le fait d’une minorité qui lutte contre une méthodologie établie.

Ce phénomène se passe aussi pour Agile, même si les mots mêmes du manifeste agile ( »bien que les éléments de droite aient de la valeur, nous accordons plus d’importance à ceux de gauche ») tentent d’éviter ce phénomène de terre brûlée. La plupart des coachs Agile favorisent aussi la prise de décision selon l’esprit de l’approche en fonction du contexte, mais pour certaines personnes il est plus facile de suivre aveuglément un modèle plutôt que d’absorber une philosophie. Vous connaissez le proverbe : « Donnez un poisson à un homme, il mangera un jour. Apprenez-lui à pêcher, il mangera toute sa vie. » Il est cependant plus facile d’apprendre à utiliser JUnit que de créer de bons cas de tests unitaires. Les puristes d’Agile ont vite trouver leur ennemi : le Waterfall, un processus dinosaure voué à l’extinction et dont on devrait retrouver des fossiles dans les couches du mainframique des l’histoire de la programmation entre deux listings de programmes Cobol. Ceux qui ont un peu plus de culture essaient de combattre RUP ou le CMMI qui sont au Waterfall ce que les tyrannosaures sont aux dinosaures, une évolution plus dangereuse et féroce qui tue des forêts entières pour produire la documentation des projets informatiques.

Le dernier numéro de Methods & Tools contient un article intéressant parlant d’une entreprise qui mélange le CMM et Scrum. Est-ce une hérésie pour les tenants de chaque approche? Peut-être. Est-ce que cet article nous dit qu’il faudrait tous faire la même chose? Non. Les auteurs décrivent seulement ce que la société pense sur la meilleure approche pour son contexte. Est-ce que cela fonctionne? Oui. Mon onzième commandement du développement est donc le suivant: oubliez les dix premiers. Si l’on pouvait résumer le développement de systèmes d’information en quelques règles, on le saurait déjà. Vous devez tout lire avec un esprit ouvert mais critique. Vous pourrez ainsi faire de meilleurs choix en fonction de votre propre contexte. Personne ne détient LA vérité sur les projets de développement de logiciel. Nous faisons tous des erreurs, ce qui est une bonne chose si nous pouvons en tirer des enseignements.

Le 10 août, VMware a annoncé un accord définitif pour acheter SpringSource pour un montant de 460 millions de dollars. Cette acquisition constitue un pari risqué et onéreux pour WMware… même si la société est riche. Son chiffre d’affaires en 2008 a été de 1,9 milliard de dollars avec un bénéfice de 290 millions. On peut comparer ces chiffres avec les estimations du chiffre d’affaires de SpringSource qui varient entre 10 et 40 millions de dollars selon les analystes. Concrètement, WMware dépense plus que son bénéfice 2008 pour acheter une société à une valeur dix fois supérieure à son chiffre d’affaires. L’ambition qui soutient cet achat est de créer un infrastructure pour « Java dans le Nuage » (Java in the Cloud).  Je considère que cette acquisition est un pari risqué. Le marché des applications sous forme de services n’est encore qu’à ses débuts et il est difficile d’estimer son potentiel… sauf si vous êtes un analyste qui désire vendre cher un rapport qui vous dira comment en profiter ;o) Il est aussi sujet à une forte concurrence avec des acteurs (Amazon, Google ou Microsoft) qui ont des bonnes ressources financières et technologiques. Se positionner sur ce marché pourrait aussi être un problème pour WMware dont les logiciels tournent sur des systèmes d’exploitation d’autres sociétés qui pourraient dorénavant le considérer comme un concurrent.

Parmi les gagnants de cette transaction devraient figurer principalement les clients de SpringSource qui devraient disposer de solutions avec une plus grande solidité financière… si la majorité des cerveaux restent dans la société (voir l’exode des dirigeants de JBoss après le rachat par Red Hat) et restent concentrés sur les produits existants. Je pense aussi que la communauté Java sera contente d’avoir un autre acteur de poids qui s’implique dans son évolution après le rachat de Sun par Oracle. Enfin, il y a certains capital-risqueurs qui ont investi dans SpringSource en 2007 et 2008. Du côté des perdants, on peut citer Red Hat dont la division jBoss va affronter un concurrent plus sérieux au niveau des serveurs Web open source.

Selon Reuters, Micro Focus a annoncé qu’une autre société serait intéressée à racheter Borland. Le prix d’achat serait de 1,20 dollar par action, alors que le conseil d’administration de Borland avait accepté l’offre de MicroFocus pour 1 dollar par action. En cas d’annulation de la transaction, Borland devrait verser à Micro Focus 3 millions de dollars.

L’identité de cette autre société est pour l’instant inconnue. Elle serait en train d’examiner les comptes de Borland avant de faire une offre définitive. Parmi les noms qui circulent, on note ceux d’Embarcadero et d’Oracle. Embarcadero, qui a déjà racheté la division CodeGear en 2008, pourrait être intéressé par une offre d’outils de modélisation, de gestion de configuration et de tests qui compléterait sa gamme actuelle… à un prix abordable au vu de la chute de l’action Borland. Pour Oracle, qui vient d’annoncer le rachat de Sun, il pourrait s’agir d’une acquisition de niche qui pourrait étoffer une offre d’outils centrée autour de Java. JDeveloper, l’IDE Java d’Oracle, était d’ailleurs basé initialement sur la technologie JBuilder de Borland.

Sun Microsystems et Oracle Corporation ont annoncé ce lundi qu’ils avaient conclu un accord pour le rachat de Sun par Oracle au prix de 9,5 dollars par action. Le montant de la transaction est évalué à 7,4 milliards de dollars. Cet accord survient après que Sun ait rompu les négociations avec IBM qui offrait un prix de 9,40 dollars par action.

Le communiqué de presse de Sun dit “Il existe un avantage substantiel stratégique à long terme pour Oracle dans le fait de posséder deux technologies de Sun : Java et Solaris”. Je pense que cette phrase résume bien les points importants de cette acquisition, du moins en ce qui concerne le développement de logiciels. Pour augmenter sa part de marché dans l’infrastructure informatique des entreprises, Oracle a principalement acheté avec Sun des compétences au niveau des langages de programmation et des systèmes d’exploitation qui viennent compléter ses solutions au niveau des applications et des bases de données. Le matériel de Sun devrait aussi permettre à Oracle d’offrir à ses clients une solution complète, matériel et logiciel, même si au vu des faibles parts de marché de Sun, Oracle devrait rester en bons termes avec ses autres partenaires comme HP ou Dell. Oracle va aussi augmenter son expérience au niveau du middleware Java après son acquisition de BEA Systems l’an dernier.

L’autre fait contenu, ou je devrais dire omis, dans cette phrase du communiqué de presse de Sun est la mention de MySQL. Sun a acheté MySQL en janvier 2008 dans le but d’augmenter son offre logicielle. MySQL a été depuis longtemps un concurrent sérieux pour Oracle au niveau d’entrée de gamme du marché des bases de données. Avec l’achat de Sun, Oracle a la possibilité de tuer “tranquillement” le processus d’évolution de MySQL et d’offrir aux clients payants actuels de MySQL de migrer vers sa propre base de données. Je ne vois pas Oracle maintenir deux solutions de bases de données, surtout si un des produits est gratuit. Même si les clients d’Oracle ne sont pas intéressés par MySQL, cette dernière était surtout adoptées par des startups, privant ainsi Oracle de clients possibles. Il existe aussi un certain nombre de sociétés qui construisent autour de MySQL les outils qui peuvent rapprocher ses performances de celles des solutions Oracle.

Je pense qu’un destin similaire, une mort lente du fait d’un manque de soutien financier, attend la plupart des autres technologies open source de Sun: NetBeans, GlassFish, JavaFX ou OpenOffice. Oracle est avant tout une société pour laquelle l’aspect financier prime sur la technologie. Dépenser de l’argent pour des projets open source avec peu de retour sur investissement à court terme n’entre pas dans sa stratégie. Certains projets pourraient sans doute subsister s’ils sont utilisables comme armes tactiques contre ses concurrents comme Microsoft ou SAP.

Communiqué de presse de Sun en anglais (rien ne figure sur les sites français de Sun ou d’Oracle)
http://www.sun.com/third-party/global/oracle/index.jsp

Le dernier sondage de Methods & Tools s’est intéressé à l’adoption de l’approche CMMI dans les organisations :

Participants : 392
Source: Methods & Tools
Fin du sondage : Janvier 2009

Plusieurs concepts de développement des années 80 et 90 ont quitté depuis longtemps les pages de la presse spécialisée ou de la blogosphère, soit parce qu’ils semblaient si évidents, comme dans “bien sûûûr, tout le monde fait de la programmation orientée objet aujourd’hui….”, soit parce qu’ils n’ont pas rencontré le succès espéré, telles les bases de données orientées objet qui devaient remplacer cette vieille technologie relationnelle datant des années 70….

Le CMMI est le successeur du Capability Maturity Model (CMM - modèle de maturité du logiciel). Le CMM a été développé de 1986 à 1997 comme un projet d’évaluation de la maturité du processus de développement. Le CMMI, où le “I” signifie “intégration”, a ensuite remplacé le CMM. Ce n’est certainement pas un concept tendance et on ne trouvera pas de section CMM sur developpez.com. Je trouve ainsi surprenant que les résultats concernant l’adoption, l’ignorance et le rejet du CMMI soient très similaires à ceux d’un sondage semblable effectué sur les approches agiles au début de 2008.

Je n’ai pas trouvé d’autres statistiques sur l’adoption de l’approche CMMI et il n’y a donc pas de comparaison possible avec d’autres études. Ces deux sondages sur le CMMI et l’Agilité nous indiquent le l’adoption d’un processus formel d’adoption est croissante au niveau des organisations de développement. Le niveau d’adoption du CMMI dans ce sondage peut aussi s’expliquer par la partie importante du lectorat de Methods & Tools qui provient d’Asie, une région où la culture peut être un frein à l’agilité, mais qui par contre a adopté le CMMI, un label qui peut servir de garantie lors de la vente des services d’outsourcing.

Comme le taux d’adoption du CMMI est équivalent à celui des approches agiles, je me suis demandé s’il existe des organisations qui ont adopté les deux approches. J’ai trouvé un sondage de Dr Dobb’s avec des chiffres de certaines entreprises qui utilisaient en même temps le CMMI et l’agilité. Selon ce sondage, le taux de succès des projets est similaire, juste au-dessus des 50%. On peut interpréter ces résultats en pensant que quelque soit le processus, le fait d’en adopter un permet d’améliorer le taux de réussite, ce qui signifie que la discipline a ses avantages. Ces chiffres nous disent aussi que vous avez toujours 50% de risques d’échec, ce qui signifie que la discipline n’est pas évidente à mettre en place. A ce propos, on peut noter que le sondage spécifique sur l’agilité effectué par Version One semble indiquer un taux de réussite supérieur pour les projets agiles, même si le type de questions posées rend cette comparaison difficile.

Bien qu’il existe des évidences de coexistence entre le CMMI et Agile, l’impression générale des gens qui pratiquent l’amélioration des processus est qu’il y a des différences culturelles importantes entre les deux communautés. Même si l’aspect non-prescritif du CMMI est reconnu par les développeurs agiles, les entreprises qui adoptent le CMMI ont tendance à privilégier fortement la planification et la documentation, ce qui est en opposition avec les principes agiles. Malgré cette apparente incompatibilité culturelle, il y a l’exemple souvent cité de Systematic, une compagnie évaluée au niveau 5 du CMMI, qui a mis en oeuvre Scrum au-dessus de son processus et obtenu une réduction de 50% des coûts. Ceci n’est peut-être pas trop surprenant si l’on considère que le CMMI et l’agilité poursuivent le même objectif d’amélioration du processus et nécessitent tous les deux de la discipline. Gérer une itération Scrum d’une semaine avec des réunions journalières devrait conduire à un contrôle strict de l’avancement d’un projet. Une entreprise qui a suivi l’approche CMMI pour une bonne raison, c’est-à-dire pas seulement pour vendre ses services, devrait ainsi être naturellement attirée par les outils d’amélioration du processus contenus dans Agile. D’autres organisations que Systematic ont ainsi ajouté les pratiques agiles au-dessus du CMMI, mais l’inverse ne semble pas évident à trouver.

Le monde du développement informatique se porterait mieux si l’on considérait le CMMI ou l”Agilité comme des boîtes à outils et non des religions qui doivent être adoptées aveuglement… avec une tendance à considérer les autres mouvements comme des “hérésies” qui ne peuvent être que condamnées. Comme le dit Chris O’Brien (Software Capabilities Manager chez Gen-i) : “Le CMMI et l’Agilité sont complémentaires, mais leur utilisation doit être basée sur les besoins de l’entreprise. Je crois que les deux offrent des solutions intéressantes et que la coexistence serait sensée dans de nombreuses organisations, particulièrement pour celles qui sont capables d’appliquer les enseignements de leur domaine avec intelligence et prudence, pour obtenir des résultats.”

Références

Le CMMI traduit en français

CMMI Home Page du  SEI

Software  and systems firms embrace CMMI - India Trends - Express Computer India

CMMI  or Agile: Why Not Embrace Both!

Dr Dobb’s article: Agile  CMMI?

Mature  Agile with a twist of CMMI

Scrum and  CMMI Level 5: The Magic Potion for Code Warriors

Systematic  Gains Chart

Methods  & Tools Agile Survey

CMMI  articles list in SoftDevArticles.com

Un sondage récent de Methods & Tools a trouvé que malgré que le nombre de pratiquants du TDD a augmenté, les tests unitaires sont toujours conduits en majorité de manière informelle, lorsqu’ils ne sont pas tout simplement ignorés par les développeurs. Ce sondage a examiné comment les organisations exécutent les tests unitaires. Est-ce une activité informelle exécutée avant l’intégration s’il reste du temps ou est-ce un élément clé du processus de développement? La question était: comment sont exécutés les tests unitaires dans votre organisation?

Participants : 384 (2006:460)

Date de fin : octobre 2008 (février 2006)

Malgré le fait que l’adoption du Test Driven Development a augmenté depuis le précédent sondage, les tests unitaires sont toujours largement exécutés de manière informelle, lorsqu’ils ne sont pas tout simplement ignorés par les développeurs. Ceci peut sembler bizarre au moment où certains annoncent une adoption généralisée des approches agiles, mais le résultat de ce sondage est semblable à ceux de bien d’autres études sur le même sujet.

En comparant les deux études, il semble que les personnes qui exécutaient déjà les tests unitaires de manière formelle ont adopté une approche TDD. Les personnes qui ne font pas de tests unitaires peuvent avoir des raisons différentes. Certains considèrent simplement que cette activité n’apporte pas de valeur à leur processus de développement, ce qui me semble difficile à croire. Pour d’autres, il s’agit simplement d’un manque de temps, une raison malheureusement plus facile à comprendre ;o). Beaucoup se plaignent que les tests unitaires soient difficiles à écrire, mais la création d’un test est une preuve de la compréhension de l’objectif de votre code. Je suis cependant d’accord avec ceux qui jugent difficile le maintien de jeux de tests unitaires automatisés lorsque les spécifications varient beaucoup. Parmi les “bonnes” raisons de ne pas faire de tests unitaires, certains considèrent que la partie client d’une application Web n’est pas adéquate pour ce type de tests. Il existe aussi certaines organisations où les équipes de tests sont séparées des équipes de développement. Celles-ci se repose entièrement sur les équipes d’assurance qualité pour tester leurs applications. On peut aussi juger que les tests unitaires sont inutiles pour une application qui aura une durée de vie très limitée et un impact fonctionnel mineur.

Ressources additionnelles (en anglais)

TDD Survey Results by  Stelligent (2007)

Developer  Survey: Unit Testing & Other Tools

Telerik  Watch: Survey Says: Unit Testing Still Not Mainstream

CodeProject:  Survey Results - Do you use Unit Testing in development?

Borland a discrètement annoncé la semaine dernière la démission de son PDG Tod Nielsen, en place depuis 2005, qui part rejoindre WMware comme directeur des opérations et de Peter Morowski, son responsable de la recherche et du développement qui a décidé de réorienter sa carrière. L’actuel responsable des finances assurera la direction ad interim. Borland a aussi annoncé une réduction d’environ 15% de ses effectifs, soit 130 employés. Pour le quatrième trimestre 2008, Borland s’attend à un chiffre d’affaires entre 38,5 et 40 millions de dollars, en baisse d’au moins 10% par rapport au trimestre précédent. Comme les charges normales d’exploitations pour le dernier trimestre étaient de 45 millions de dollars et qu’elles sont en grande partie fixes, on peut s’attendre à un nouveau trimestre de forte perte pour l’entreprise.

Par le passé, Borland avait souvent accusé son unité des outils de développement d’être la cause de ses difficultés financières et de freiner son ambition de devenir un leader dans le domaine de l’ALM (Application Lifecycle Management). Cette unité avait été séparée dans une entité nommée CodeGear que Borland a finalement réussi à vendre en mai 2008 à Embaracadero. Les résultats de cette dernière sont difficiles à analyser, car elle n’est pas cotée en bourse et elle n’a donc pas à publier ses comptes. L’offre actuelle de Borland consiste en un assemblage de produits dont certains ont été développés en internes et d’autres sont le fruit des acquisitions de ces dernières années (Togethersoft, Segue), regroupés sous la bannière de l’ALM. Aucun des composants de cette offre n’est considéré comme un produit phare dans son secteur spécifique et il est toujours difficile de réaliser une intégration efficace et élégante de produits disparates. La vente de ces produits et du concept d’ALM est aussi plus difficile pour Borland, car il s’agit d’avoir des contacts à plus haut niveau dans les entreprises par rapport aux produits ciblant des développeurs individuels. En outre, il s’agit typiquement des produits dont l’acquisition sera diminuée lors de difficultés économiques. Finalement, ce marché met Borland en compétition avec des sociétés de taille plus importante, comme IBM qui a racheté Telelogic l’an dernier, ou qui ont leurs racines dans le monde de l’ALM, comme MKS.

Il serait regrettable que Borland fasse faillite juste après avoir célébré ses 25 ans, mais si l’entreprise était déjà en difficulté alors que la conjoncture était favorable, on peut craindre pour sa survie alors que l’économie est en crise et que 2009 s’annonce comme une année difficile pour les éditeurs de logiciels. En faisant des recherches pour cet article, j’ai trouvé la mention que Borland avait déjà diminué de 40% son effectif en 1995 après la démission de son fondateur Philippe Kahn. Ce qui se passe actuellement pourrait ainsi n’être qu’une “crise de plus” dans l’histoire de Borland, une société aussi brièvement connue sous le nom d’Inprise ;o)

Communiqué de presse de Borland (en anglais)

Cette étude a été menée et sponsorisée par VersionOne durant les mois de juin et juillet 2008. Elle a reçu des réponses de 3061 participants de 80 pays, la plupart (70%) répondant pour la première fois à cette enquête. La majorité des participants étaient des coachs ou leaders agiles, ainsi que des consultants. Ceci pourrait amener un biais sur une vision peut-être optimiste de la réalité des projets agiles. Agile ou non, un manager reste un manager ;o)

Cette étude n’essaye pas de mesurer l’adoption des approches agiles, mais elle fournit des informations intéressantes sur la manière dont elles sont adoptées. Une majorité (55%) des participants travaille dans des organisations plutôt petites, avec 100 personnes ou moins qui sont affectées au développement informatique. L’agilité est une nouveauté pour la plupart, puisque seulement 34% des participants ont utilisé les méthodes agiles depuis plus de deux ans. Le pourcentage qui a adopté l’agilité dans l’année précédente est de 36%. On peut aussi constater que l’adoption est partielle dans les entreprises, car 65% des participants utilisent une approche agile dans moins de 50% des projets. Une adoption complète n’est réalisée que dans 17% des entreprises, un chiffre similaire à celui produit par un sondage de Methods & Tools conduit à fin 2007

Scrum est la méthodologie agile la plus suivie. Parmi les pratiques, la planification d’itération, les tests unitaires, les réunions journalières, la planification des versions et l’intégration continue sont celles qui sont adoptées par plus des 2/3 des participants. De manière surprenante, la programmation par paire, une pratique emblématique de l’approche XP, se situe en bas de tableau, avec un taux de mise en oeuvre de seulement 31%. L’intégration du client dans les projets est aussi faiblement utilisée. Ceci montre que les pratiques qui impliquent les interactions entre les personnes sont les plus difficiles à mettre en oeuvre, l’aspect personnel étant le plus grand frein des changements de processus.

Une des questions traitait du taux de succès des projets agiles. Pour 55% des participants, presque 100% des projets sont réussis. A l’opposé, 24% estiment qu’un projet sur deux échoue, principalement à cause de l’opposition entre la culture de l’entreprise et des valeurs agiles et par manque d’expérience dans les approches agiles. La partie finale du rapport fournit des informations intéressantes sur les outils utilisés par les projets agiles. On constate ainsi que les outils traditionnels et agiles de gestion de projet sont utilisés dans des proportions similaires.

Données de l’étude Version One Survey

Sondage Methods & Tools