Lors de discussion sur les tests logiciels, je suis régulièrement surpris d’entendre que cela se résume à test unitaire, test d’intégration et test fonctionnel. En schématisant, le premier permet de tester le code, le deuxième l’intéraction de composants et le troisième le logiciel dans son ensemble. Hors, cette liste est largement incomplète.
Objectif d’un test Avant de tenter une classification, il me semble opportun de s’interroger sur l’objectif d’un test :
Cela fait maintenant une dizaine d’années que je monte des équipes. J’en ai tiré une ligne de conduite que je vous propose dans ce billet.
Votre équipe doit vous survivre A la création d’une équipe, je pars du postulat suivant : dans quelques mois (généralement de 12 à 36 mois selon la difficulté à monter l’équipe), je n’en serai plus le manager. Le fait de se le dire dès sa conception permet de graver dans ses gènes l’apprentissage de son autonomie, d’une création d’une vision à long terme et de sa légitimité pour y aller.
Dans une ancienne vie, j’ai travaillé pour un éditeur logiciel. Il est temps de vous raconter le début de cet aventure.
Note : je parle d’un temps ancien, les choses ont bien changées depuis.
A cette époque, je travaille dans une SSII et je cherche depuis quelques mois à changer de poste. Comme on dit dans les milieux autorisés, je suis en recherche active. Mes dirigeants veulent que je me casse mais sans me licencier.
J’ai toujours utilisé une distribution Linux à base de paquets binaires (Ubuntu, Debian…), trouvant ce mode de fonctionnement plus reposant que de compiler soi même tout un tas de projets dans divers langages. C’est souvent source d’erreurs incompréhensibles et de longs moments de solitude. Néanmoins, il existe plusieurs avantages de le faire pour un langage de programmation comme Python :
Ne pas toucher à l’interpréteur de la distribution et aux packages utilisés par le systême.
En 2004, un pote qui bosse chez Google me file une invitation pour tester un nouveau Webmail appelé GMail. 2014. Cela fait maintenant 10 ans que j’utilise GMail pour mes besoins (sur plusieurs comptes) en plus de l’utilisation du moteur de recherche Google, Google Maps, Google Calendar, Google+ et Android (et jusqu’en 2013 Google Reader). Il était temps de réduire ma dépendance envers Google. Dans un élan de volonté, je me suis décidé à trouver un nouvel hébergeur mail pour 2015.
J’ai lu voici quelques mois un billet qui s’intitule The Rise of Worse is Better par Richard P. Gabriel, développeur Lisp (qui a d’ailleurs monté une société autour de ce langage dans les années 80). Vieux billet puisqu’il date de 1989 dans sa version original. Il est, à l’origine, une section dans un essai nommé Lisp: Good News, Bad News, How to Win Big.
Dans ce billet, Gabriel expose deux visions du développement logiciel qu’il appelle la conception «The Right Thing» (approche MIT) et la conception «Worse is Better» (approche Stanford).
Lors d’une présentation d’un langage de programmation, ou lors d’une discussion entre développeurs, il arrive bien souvent que l’on utilise les termes «avantage» et «inconvénient». Par exemple, cela peut donner comme argument pour Java : «Java c’est cool, tu codes sur la JVM et cela fonctionne sur plusieurs plateformes». Hors pour moi, la JVM est loin d’être un avantage. C’est gros, lourd, géré par Oracle qui impose des restrictions alacon… L’exemple illustre un défaut dans l’argumentation : l’utilisation d’un argument subjectif présenté comme objectif.
Si cela fait des années que je n’espère plus rien de Google sur le plan des libertés, je reste curieux de tout ce qu’ils font sur le plan technique, notamment pour Internet. Car c’est pour moi la seule (grosse) boite qui fait avancer sérieusement les choses. Explication.
La différence de business model Pour expliquer mon point de vue, il faut d’abord parler de business model :
Quel est le business model de Microsoft ?
En septembre 2010, j’ai lancé #gitfr pour expliquer les DVCS et Git en particulier. 2 ans, ~30 présentations et ~10 ateliers plus tard j’ai besoin de parler d’autres choses :). Je propose de nouveaux ateliers et présentations sur des sujets assez variés, que ce soit en développement, administration ou management. Si vous êtes interéssé par un sujet, il suffit de me contacter pour se mettre d’accord sur un lieu et une date.
On peut juger un développeur sur la compréhension qu’il possède de son métier : 5 niveaux qui détermine bien souvent sa plus value pour une organisation.
Niveau 0 : pisser de code Il pense que son boulot est de produire des lignes et des lignes et des lignes de code. Généralement peu intéressé par ce qu’il fait, c’est juste un poste qui paye la soupe. Ou alors c’est un boulot temporaire avant de passer chef de projet.