Cette année 2023, la plateforme de crowdtesting Testeum, dont Hightest a posé les fondations, offre une campagne par mois à un projet calédonien innovant !
Vous trouverez dans cet article le témoignage des porteurs du premier projet ayant utilisé Testeum dans ce cadre, à savoir l’application Domaine NC.
Qui êtes-vous ?
Nous sommes Adrien Sales, product manager de l’application mobile et de l’API de domaine.nc, et Laurent Schaeffer, développeur de l’application mobile Domaine NC Mobile.
A quoi sert l’appli Domaine NC ?
LS : Pour faire simple, cette application sert à consulter de manière mobile et très compacte les noms de domaines de Nouvelle-Calédonie. Cela permet de visualiser les différentes informations d’un nom de domaine et de recevoir des notifications en cas de d’expiration prochaine de celui-ci.
AS : Nous avons produit une expérience utilisateur disruptive pour faciliter une gestion qui auparavant était plutôt faite à la main… avec des risques d’oubli. Lequel a un impact important sur notre business digital car si votre nom de domaine expire, vous disparaissez du web et donc vous perdez de la visibilité, ou pire : des transactions. Nous voulions mettre en avant la valeur de ces données et leur potentiel.
Quels sont les risques qualité de cet applicatif ? Qu’est-ce qui pourrait « mal tourner » ?
AS : Un des risques est d’avoir une UX non optimale/trop compliquée. On redoutait aussi d’avoir de mauvais temps de réponse… ou pire : pas réponse (une vilaine 500 par exemple) !
A quelles questions vouliez-vous que la campagne de crowdtesting réponde ?
LS : Il fallait s’assurer que chaque utilisateur puisse accéder facilement aux informations qui l’intéressent.
AS : Effectivement, nous voulions nous assurer de la facilité de prise en main par un néophyte. Nous voulions aussi savoir si nos performances étaient passables, bonnes ou excellentes (nous visions une recherche et un affichage instantanés).
Comment avez-vous organisé vos campagnes de test ?
AS : On a d’abord figé un périmètre très réduit de fonctionnalités (notre MVP) via une milestone dédiée sur GitHub, puis on a organisé une première campagne très simple pour récupérer des feedbacks des testeurs sur un jeu très restreint de features.
LS : Suite aux corrections opérées en sortie de cette première session de test, on a lancé d’autres campagnes : une par fonctionnalité.
Qu’avez-vous pensé des retours des crowdtesters ?
LS : Nous avons découvert un point de vue différent du nôtre, qui nous a permis d’améliorer l’application sur un plan UX et fonctionnel.
AS : On a découvert des scénarios de test très pertinents. Par exemple, une personne a cherché la taille maximale acceptée par notre champ de saisie de nom de domaine. Certains tests nous ont même permis d’améliorer la sécurité de notre API ! Nous avons eu de nouvelles idées de simplification d’usage, par exemple l’ajout de placeholders guidant davantage les utilisateurs.
Nous avons aussi eu un retour sur un bug bête et méchant : la recherche automatique ne devait se déclencher qu’à partir de 3 caractères saisis, mais ce n’était pas le cas. Nous avons donc amélioré au passage la vitesse de l’appli et réduit le nombre d’appels de l’API.
Qu’avez-vous pensé de la plateforme elle-même ?
AS : Les dashboards sont beaux et très faciles à exploiter ! Tout est prêt à l’emploi. On a pu les copier-coller tels quels pour organiser notre travail en équipe, avec très peu d’efforts.
LS : La plateforme est facile d’utilisation et permet de bien organiser ses campagnes de manière optimale.
Pour vous, comment une démarche crowdtesting devrait s’articuler avec les autres pratiques de test ?
AS : De ce que j’ai pu en voir, je trouve que cela arrive par exemple pour tester des RC (release candidates) ou des bêtas, et en conditions réelles (sur une infra cible). J’ai par exemple pu mesurer l’impact sur les perfs de l’API et voir si toute la chaîne tenait bien le coup : c’était vraiment de bout en bout ! Génial et terriblement efficace.
Je verrai bien une description d’organisation, qui intégrerait le crowdtesting avec toutes les autres phases de test et la partie release planning.
Je pense que left-shifter une campagne ferait sens dans une approche LEAN, ce qui privilégierait le Time To Market, la qualité et plus généralement toute la chaîne de delivery. Nous avons implémenté une chaîne de CI complète qui nous permettait de déployer avec une simple release la version sur les stores… et de manière sémantique. Ainsi on peut se concentrer sur des périmètres compacts et boucler très rapidement et avec une grande qualité logicielle. Nous avons tout fait via des outils cloud GitHub/Fastlane.
Quel conseil donneriez-vous à une personne qui envisagerait une démarche de crowdtesting pour tester son produit ?
AS : Je lui conseillerais de :
- Sensibiliser son équipe : lui présenter les concepts clés de la plateforme à son équipe et de la sensibiliser au Left-Shifting. Lui montrer des exemples de campagnes : les wins, les fails, des exemples très concrets, présenter les approches (une grosse campagne de test VS plusieurs petites) voire diffuser des témoignages.
- Sensibiliser sur le fait que le test d’une feature fait parties des coûts de dev… et que donc cela doit être pris en compte dès le début.
- Au moment de la conception de la campagne de test, proposer un parcours complet pour profiter au mieux de la plateforme (ROI)
- Disposer impérativement d’un PO (et donc d’une vision produit très claire)
- Embarquer l’équipe (Devs, Scrum Master) afin que le crowdtesting soit une phase projet comme une autre… et si possible des newbies complets à l’équipe qui ne connaissent rien au domaine métier.
- En bonus : créer un club d’utilisateurs qui ont utilisé la plateforme et qui pourraient créer un guide de best practices.
Tiens, c’est quoi qui brille par terre ? Une lampe ? HA, voici le génie de Testeum, vous pouvez faire 3 voeux de nouvelles fonctionnalités sur la plateforme !
LS : On en a 3 chacun ? J’en fais 2 pour ma part : 1) La possibilité d’exporter les données de test vers d’autres platformes (style GitHub ou autre) ou au format JSON, et 2) Fournir une API pour récupérer les données de test et/ou d’autre données.
AS : J’en fais 3 ! 1) Pouvoir trigger des Webhooks pour pousser les retours directement en issues (Github) ou déclencher des workflows (IFTTT, Zapier, Power Automate, …), en mode événementiel, ou à des chaînes de CI. 2) Fournir une API pour consommer les données des feedbacks et des campagnes à des fins d’intégration B2B ou de reporting. 3) Pouvoir targetter des profils professionnels (en plus des critères actuels : âge, sexe, pays et type de matériel possédé).
Merci à Adrien et Laurent pour ce témoignage ! Pour en savoir davantage sur la génèse de leur projet, vous pouvez visionner cette vidéo.
Vous pouvez également consulter deux de leurs rapports de test Testeum : celui-ci et celui-là !
