Attention: cet article a été écrit en 2017. Vous trouverez à la fin de ce dernier des réponses par rapport à des problèmes rencontrés (évolution ou explication) lors de mon expérience.
PS: les images proposées ne sont plus les images initiales mais sont validées par Applause car permettent de ne pas enfreindre des règles de confidentialité avec leurs clients.
Depuis mon article sur le CrowdTesting, j’ai continué à me renseigner pour mieux comprendre ce nouveau concept. Et, vous me direz, quoi de mieux pour comprendre le fonctionnement et se faire une idée que de tester par soi-même ?
C’est donc ce que j’ai fait ! Je me suis inscrit sur une plateforme de CrowdTesting. Le choix a été fait suite à un commentaire citant ce site parmi plusieurs sur le CrowdTesting.
1ère partie : Être invité pour une campagne.
Lors de l’inscription, plusieurs informations m’ont été demandées : quels types de test, suis-je prête à faire des déplacements, sur quelles plateformes, quel téléphone, OS, opérateur, langues…
J’ai choisi, Français et anglais, uniquement des tests fonctionnels sur téléphone (en prenant le mien).
2 jours après je recevais ma première invitation à participer à une campagne, puis une nouvelle invitation encore 2 jours après. Le site est donc assez actif sur ses propositions et il est assez simple d’avoir un peu de matière de travail.
Exemple d’invitation pour participer à une campagne :
2ème partie : Exécuter les campagnes
C’est là que le travail commence !
Après avoir accepté de rejoindre le test cycle on a accès à une page explicative avec des descriptions sur plusieurs points :
· Ce qui est demandé pour cette campagne (le périmètre)
Exemple :
· Le paiement
Données confidentielles et dépendant des campagnes (pas de screenshots).
Paiement par tests exécuté (très rare)
Paiement par bugs trouvés
Et oui, on est payé au bug (c’était le cas pour mes 2 campagnes) !
Après s’être réinscrit si besoin (car il peut avoir des inscriptions supplémentaires sous peine de ne pas être payé (je reviendrai plus tard sur ce point)) et récupéré les TC s’ils sont donnés on peut faire nos tests sur une application généralement non connue (c’est très important pour la suite).
Sur mes 2 campagnes j’ai eu 1 seul fichier avec des cas de test (pourtant dans la seconde campagne on parlait de tests exploratoires ET de tests de régression). Ces cas étaient compliqués à exécuter car peu clair. De plus je trouve que la présentation était (très) mal pensée car la plupart des lignes n’étaient pas visibles.
En fait pour chaque ligne de la colonne « Action » et « Résultat attendu » il peut y avoir jusqu’à 10 lignes… Un crève-cœur pour moi qui répète sans cesse qu’un cas de test doit être écrit de cette manière : « 1 action => 1 ou plusieurs résultats » !
Enfin, on remonte les résultats.
Si l’on trouve des bugs il faut vérifier que ces bugs n’existent pas déjà. S’ils existent, les confirmer (je trouve que c’est une très bonne idée).
Sinon, il faut suivre les consignes décrites lors de l’adhésion à la phase de test et remplir les champs demandés. Les bugs demandent beaucoup de travail !
3ème partie : Se faire payer.
On arrive à une partie plus délicate… Et bien entendu celle qui permet de recruter tant de personnes dans un laps de temps si court.
De mon côté, malgré environ 1h30 passé sur ma première campagne, 1 fichier de TC (Test Case: Cas de Test) effectué (à environ 19$), 1 bug ouvert (à quelques $) je n’ai rien perçu et ne percevrai rien.
Pour le fichier de TC je ne m’étais pas réinscrit (je ne m’inquiète pas cela a quand même été étudié):
image représentait un refus de payer!
Pour le bug : il a été rejeté, demandant une vidéo (faire une vidéo sur son téléphone et sur l’utilisation c’est galère), d’autant plus qu’il était stipulé qu’ils préféraient des ScreenShots aux vidéos :
Sur la seconde campagne je n’ai passé qu’une heure. Il n’y avait pas de cas de test à exécuter. Je n’ai pas ouvert de bug mais en ai confirmé 3 (pas de nouvelle de paiement, je suppose donc que ces confirmations ne m’ont rien rapportées).
Voilà donc le résumé du déroulement de mes 2 campagnes.
Je peux donc passer à l’analyse de mon expérience :
Mes remarques :
· L’entreprise se lançant dans le CrowdTesting doit faire attention à la qualité des livrables.
Les tests doivent être bien écrits et compréhensibles ! Ici les testeurs ne connaissent pas l’application, ne connaissent pas l’entreprise et peuvent difficilement avoir des explications.
Les informations doivent être claires, notamment sur les demandes sur les Bugs et les objectifs des tests.
Les coûts d’exécution sont vraiment faibles voir très faible, par contre il faut assurer une bonne qualité et une satisfaction des testeurs (je ne referai pas de campagne pour l’application de ma première campagne)
· On ne gagne pas sa vie avec de CrowdTesting. Les gains envisageables sont très faibles par rapport à l’investissement (en temps et matériel) nécessaire.
· Il faut toujours faire attention à l’environnement (de test)… Les 2 campagnes que j’ai effectuées étaient en production. Sur la première on nous demandait d’annuler sa commande, sur la secondes de ne pas en faire. Cela pose 2 problèmes :
Pour la première campagne : on doit rentrer son numéro de CB, aucune CB de test n’est fournie… De plus rien ne garantit la non utilisation de ces données, on est considéré comme un client lambda. Je ne sais pas pour vous mais personnellement cela me dérange et ne suis donc jamais allé jusqu’à cette étape.
Pour la seconde, le paiement n’est pas testé ce qui est pourtant, de mon point de vue (surtout vu le contexte de site ayant pour but de vendre des livres) la partie la plus importante de l’application !
· Le support de l’entreprise doit être rapide… Il existe un système de chat pour contacter l’entreprise. Je ne l’ai pas utilisé mais d’autres testeurs l’ont fait (tous à propos de la réinscription), par contre personne n’est revenu vers moi sur ma remarque avec les CB…
· La course aux bugs est lancée ! On est payé au bug… Pas à nos retours aussi constructifs soient-ils, pas au fait de confirmer les bugs sur différentes plateformes… Résultats : de nombreux bugs sont créés, de nombreux bugs déjà existant également (pourquoi chercher parme les 50+ bugs si le mien existe déjà ? Je le créé et au pire il sera refusé, ça me prendra moins de temps et au moins si quelqu’un d’autre le trouve en même temps j’aurai la primauté…)
N’hésitez pas à partager vos expériences si vous avez également participé à des campagnes de CrowdTesting.
Réaction à mes retours de 2017 (informations données par Applause)
Premier changement significatif, une personne est désormais dédiée à la gestion de la communauté de testeurs français.
Mon retour:
L’entreprise se lançant dans le CrowdTesting doit faire attention à la qualité des livrables. Les tests doivent être bien écrits et compréhensibles ! Ici les testeurs ne connaissent pas l’application, ne connaissent pas l’entreprise et peuvent difficilement avoir des explications. Les informations doivent être claires, notamment sur les demandes sur les Bugs et les objectifs des tests. Les coûts d’exécution sont vraiment faibles voir très faible, par contre il faut assurer une bonne qualité et une satisfaction des testeurs (je ne referai pas de campagne pour l’application de ma première campagne)
Evolution:
Les personnes qui rédigent les instructions contenues dans la plateforme et donc les cas de test (lorsqu’ils ne sont pas fournis par les clients) sont membres de notre communauté. Ils sont guidés et formés pour que ce soit le plus clair et précis possible. Si parfois ce n’est pas assez compréhensible, nous nous appliquons pour améliorer la qualité de nos instructions tous les jours. Lorsqu’un testeur a une question, il peut à tout moment nous contacter via un chat dédié à chaque cycle de test et obtiendra une réponse dans les prochaines heures (ce chat était en place il y a deux ans). Nous communiquons également les adresses emails des différentes personnes en charge du projet qui sont disponibles pour guider et assister les testeurs tout au long du cycle mais également après. En tant qu’entreprise de Crowdtesting, la satisfaction, la motivation et la fidélité de nos testeurs sont nos priorités. Nous avons des solutions en place pour nous assurer qu’aucun testeur ne se sente injustement traité (comme lorsqu’un bug est rejeté par le client). Dans ce cas le testeur peut demander que l’on étudie de nouveau la validité de son rapport de bug en nous donnant ses arguments. Lorsque le testeur a le sentiment d’une injustice, nous nous assurons toujours de répondre à ce sentiment en révisant la décision prise ou en lui donnant une explication claire et en lui expliquant comment mieux faire la prochaine fois. ·
Mon retour:
On ne gagne pas sa vie avec de CrowdTesting. Les gains envisageables sont très faibles par rapport à l’investissement (en temps et matériel) nécessaire.
Réponse:
Cela dépend des profils (pays et ville de résidence, langue(s) parlée(s) etc.), du nombre et type d’environnement à la disposition de la personne, de la qualité et quantité de sa participation. Nous avons des testeurs travaillant à plein temps avec Applause depuis de nombreuses années.
## Je nuance par le fait que cela peut être possible mais compliqué (voir retour en commentaire) et que de préférence il vaut mieux ne pas être en France ou dans un pays à haut niveau de revenu.
Mon retour:
Il faut toujours faire attention à l’environnement (de test)…
Les 2 campagnes que j’ai effectuées étaient en production. Sur la première on nous demandait d’annuler sa commande, sur la secondes de ne pas en faire. Cela pose 2 problèmes : Pour la première campagne : on doit rentrer son numéro de CB, aucune CB de test n’est fournie… De plus rien ne garantit la non utilisation de ces données, on est considéré comme un client lambda. Je ne sais pas pour vous mais personnellement cela me dérange et ne suis donc jamais allé jusqu’à cette étape.
Evolution:
L’une des forces de notre entreprise est que nous réalisons des tests en conditions réelles pour nos clients. Ainsi, lorsque le client veut tester en production, il se peut que nous demandions aux testeurs de réaliser des achats (il s’agit de test de paiement ou Payment Testing). Tester le bon fonctionnement des moyens de paiement est primordial pour anticiper les bugs qui pourraient survenir lorsqu’un utilisateur réel utilise un produit digital et cela ne peut pas seulement se faire en environnement de test avec des cartes de test. Les testeurs sont informés qu’ils testent en production et des différentes informations qu’ils vont devoir partager. Ils ne participent que s’ils le souhaitent. Quant à l’utilisation de ces données, nous sommes soumis à la régulation européenne sur l’utilisation des données personnelles, comme le sont nos clients.
Mon retour:
Pour la seconde, le paiement n’est pas testé ce qui est pourtant, de mon point de vue (surtout vu le contexte de site ayant pour but de vendre des livres) la partie la plus importante de l’application !
Réponse:
Nos clients décident de ce qu’ils veulent tester dans un cycle de test en fonction de leurs besoins. Il se peut que les paiements réels aient été testé à une autre occasion, il se peut qu’ils aient décidé de ne pas tester cette partie de leur produit en conditions réelles. Cette décision peut avoir été prise pour de multiples raisons. Encore une fois, nous testons les parcours transactionnels lors de cycles bien distincts (service Applause nommé « Payment Testing ». Les testeurs sont remboursés du montant de la transaction et rémunérés et perçoivent une rétribution pour les dédommager d’avoir utilisé leur propre moyen de paiement. ·
Mon retour:
Le support de l’entreprise doit être rapide… Il existe un système de chat pour contacter l’entreprise. Je ne l’ai pas utilisé mais d’autres testeurs l’ont fait (tous à propos de la réinscription), par contre personne n’est revenu vers moi sur ma remarque avec les CB…
Réponse:
Comme mentionné précédemment, les testeurs peuvent utiliser le chat pour poser leur question concernant le périmètre de test, le produit à tester, ou toute question tant que cela respecte notre Code de conduite. Une personne veille à répondre à ces questions aussi régulièrement que possible. Si un testeur n’obtient pas cependant pas de réponse dans un délai raisonnable, il peut alors contacter par email les autres personnes de l’équipe du projet. ·
Mon retour:
La course aux bugs est lancée ! On est payé au bug… Pas à nos retours aussi constructifs soient-ils, pas au fait de confirmer les bugs sur différentes plateformes… Résultats : de nombreux bugs sont créés, de nombreux bugs déjà existant également (pourquoi chercher parme les 50+ bugs si le mien existe déjà ? Je le créé et au pire il sera refusé, ça me prendra moins de temps et au moins si quelqu’un d’autre le trouve en même temps j’aurai la primauté…)
Réponse:
Nous avons plusieurs offres que nous proposons à nos clients, les retours utilisateurs (Usability testing) est quelque chose que nous fournissons en dehors des cycles de test fonctionnel car cela demande une expertise bien différente. Dans un cycle de test fonctionnel ce qui intéresse nos clients sont les rapports de bug fonctionnel. Nous pouvons mettre en place quelques questions pour collecter des retours utilisateurs mais cela ne remplace en rien une vraie étude d’expérience utilisateur. Concernant les bugs déjà créés et la liste de bugs connus (cette dernière est aussi souvent que possible directement intégrée dans la plateforme et non dans un fichier à part comme cela a pu l’être dans le cycle de test mentionné dans cet article), nous avons un système de reconnaissance de mots-clés qui permet de faciliter ce travail de recherche de bugs similaires pour le testeur. Lorsqu’il y a de nombreux bugs rapportés précédemment ou que nous avons beaucoup de bugs connus fournis par le client, nous comprenons que le risque de rapporter un doublon augmente. Nous avons une personne chargée de trier les bugs avant que le client ne s’en occupe à son tour. Cette personne s’assure que les rapports soient clairs, précis, et valides. Si un doublon est détecté, alors le bug sera rejeté. Il y a de nombreuses évolutions depuis deux ans : Nous avons intégré dans la plateforme beaucoup de nouvelles fonctionnalités pour faciliter et rendre plus agréable l’expérience de nos testeurs (comme une fonctionnalité de slotting directement liée aux cas de test ce qui aurait pu prévenir le rejet de ton cas de test notamment…). Les fonctionnalités existantes ont été améliorées et perfectionnées (comme la fonctionnalité de détection des doublons, intégrée directement dans l’interface de rédaction d’un rapport de bug). Comme mentionné plus haut, les membres de la communauté qui participent à la création et la gestion de ces cycles de test sont de mieux en mieux formés et guidés dans ces tâches. Ainsi, les testeurs sont davantage aidés et accompagnés pour leur permettre de fournir les meilleurs résultats possibles et donc d’être rémunérés.
Vous pouvez également me contacter si vous souhaitez des précisions que je ne pourrais pas apporter en répondant à des commentaires.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes article
