Vous avez peut-être entendu parler de Crowdtesting, une pratique qui génère actuellement pas mal de ‘buzz’ et qui consiste à confier une application à une communauté de testeurs externes afin qu’ils en vérifient la robustesse.

A l’occasion du post de la semaine dernière, je me suis demandé si la situation rencontrée dans ce cas ne justifierait pas le recours à cette technique.

Un département informatique qui doit faire face à la forte croissance d’un site web de ventes online, gérant des dizaines de milliers de connexions journalières et des milliers de produits de plus de 1500 fournisseurs différents. Un portfolio d’applications vieillissantes intégrées à des ERPs, un grand nombre de customisations pour prendre en compte les réglementations de chaque pays.

La pression du time-to-market et la faible priorité accordée à la QA aboutit à des bugs que même un simple utilisateur peut détecter en suivant un processus normal d’achat. N’importe quel ‘Crowdtesteur’ y parviendrait donc aisément.

Ne serait-ce pas là un cas idéal pour incorporer ce type de tests dans la stratégie AQ pour ce site ? Quels en seraient les avantages ?

Ne serait-ce pas là un cas idéal pour incorporer ce type de tests dans la stratégie QA de ce site ? Quels en seraient les avantages ?

• Coûts : effectuer un plus grand nombre de tests pour un coût moindre de mise-en-œuvre. Or ce département IT n’a manifestement pas un budget QA à la hauteur de sa mission. More with less.
• Flexibilité : effectuer un plus grand nombre de tests en une période temps moindre. Le cas d’utilisation que nous avons rencontré – une exception au processus de livraison par défaut – nécessitait probablement une ou plusieurs itérations de QA en quelques heures, certainement moins d’une semaine. Impossible avec un équipe interne pas assez nombreuse. Possible avec des crowdtesteurs. Sooner with less.
• Infrastructure : puisqu’il s’agit d’un site marchand online, de tels tests peuvent être menés sur une réplique (privée) du site, sans nécessiter d’efforts importants de gestion de l’infrastructure de tests ou de déploiement. De plus, le Crowdtesting s’applique bien lorsque les tests doivent être reproduits sur différentes configuration de browsers, de machines clientes (ordinateurs, tablettes, téléphones, OS, …).
• Sécurité. Cette application ne comporte pas ou peu de données personnelles. Les seuls processus un tant soit peu sensibles sont le système d’identification utilisateur et le système de paiement, mais cela peut se gérer facilement. Pas comme s’il s’agissait du dossier médical d’un patient ou de vos données bancaires.
• Criticité et diversité. Le Crowd-testing ne s’applique pas vraiment lorsqu’il s’agit de tester des fonctionnalités pointues et complexes qui requièrent une connaissance métier avancée. Par exemple, une application boursière. Lorsqu’il s’agit d’un processus de vente online, cet inconvénient ne s’applique pas. Au contraire, le nombre important de testeurs assure une diversité de comportements d’achat qui ne peut que s’avérer bénéfique.

Je pense qu’il s’agit d’une situation dans laquelle il est possible d’imaginer une synergie entre :

• Une équipe réduite de professionnels en charge de vérifier une implémentation correcte de fonctionnalités métier.
• Un processus de Crowdtesting afin d’optimiser le time-to-market, la flexibilité et les coûts.

Le post de la semaine dernière était déjà trop long pour me permettre de faire part de ces réflexions, et je souhaitais également passer à d’autres sujets, notamment autour de Sonar. Mais un article dans ‘El Pais’ hier m’a fourni l’occasion de réfléchir à un autre phénomène : le Crowdsourcing.

Le Crowdsourcing est une pratique apparue avec le Web 2.0, qui consiste à utiliser le potentiel collectif des utilisateurs d’Internet pour développer de nouvelles applications. Je me suis alors demandé s’il serait possible, comme dans notre cas ci-dessus, de mixer développeurs internes et ‘CrowdDéveloppeurs’.

Le principal argument à l’encontre d’une telle idée est que, à nouveau, on ne peut demander à des développeurs externes de gérer la complexité fonctionnelle d’une application. Non ? Vraiment ?

Pourtant que se passe-t-il lorsque une entreprise outsource ses applications ? Cela implique un effort de passation de cette connaissance fonctionnelle, qui justifie d’ailleurs d’éviter l’outsourcing d’applications fonctionnellement complexes et critiques.

Et puis, il existe déjà des exemples de ‘CrowdDev’ qui prouvent que ce modèle est envisageable. Le monde Open Source nous a démontré que des communautés de développeurs pouvaient se construire autour d’un produit logiciel qu’elles contribuent à étendre. On trouvera généralement une équipe réduite, très experte, dédiée à la gestion d’un noyau ‘Open-Source’ autour duquel la communauté des ‘CrowdSourcers’ va développer des briques annexes.

Autre argument : ce modèle ne serait pas applicable hors du monde Open Source, pour des projets d’entreprise. Et pourquoi pas ? La plupart des projets de développements actuels s’appuient sur des frameworks Open-Source. Et il s’agit de moins en moins de briques techniques mais de plus en plus d’ERPs dans des domaines fonctionnels précis. J’ai vu également des clients ‘open-sourcer’ certains de leurs développements. Par exemple, le département informatique d’une région administrative en charge de toutes les applications ouvertes au public, qui met ses développements à la disposition des autres régions afin d’en mutualiser la maintenance. Un éditeur logiciel d’un ERP de gestion d’université, application qui nécessite beaucoup d’adaptations de la part de chaque université. Ces customisations sont ‘open-sourcées’ afin de permettre à chaque université cliente de bénéficier des développements d’autres équipes, et également reprises par l’éditeur afin d’enrichir la version de base.

En poussant le raisonnement, on peut imaginer des équipes de CrowdSourcing et de CrowdTesting, travaillant dans un monde de plus en plus virtualisé, pour des départements TI centrés sur des équipes métier et qualité réduites et fortement spécialisés.
Dans l’exemple de ce site web, puisque nous avons vu qu’ils envisagent de proposer leur site online sous un format SaaS, certaines fonctionnalités pourraient être ‘crowdsourcées’, comme la localisation du site en différents langages, la personnalisation de la boutique en ligne en fonction des produits vendus, la customisation de l’interface utilisateur et de l’ergonomie sur différentes plateformes hardware (PC, tablettes, etc.)

Contrairement à ce que pensent certains, je ne pense pas que les professionnels de QA ou de développement soient menacés par ces évolutions du marché. Comme nous l’avons vu ci-dessus, un bon architecte ou un bon professionnel de QA sera toujours nécessaire pour une application complexe, fonctionnellement pointue, ou sensible d’un point de vue sécurité.

Cependant, je pense aussi que les temps sont révolus où chacun pouvait passer sa vie professionnelle entière comme employé dans une ou plusieurs entreprises, mais qu’il sera de plus en plus nécessaire dans le futur de créer son propre emploi. En ce sens, Crowdsourcing et Crowdtesting vont faciliter l’utilisation par les départements informatiques de compétences extérieures.

Tant mieux. Dans mon dernier job, j’ai connu quatre patrons différents en cinq ans, et je ne les ai pas choisis. Mes clients si.

Cette publication est également disponible en Leer este articulo en castellano : liste des langues séparées par une virgule, Read that post in english : dernière langue.