Un bug entre 2 développements ? Comment gérer ?
Vous lancez enfin votre nouveau site e-commerce. Il semble "presque" parfait. Tout roule. Et puis, des petits bugs remontent, par ci par là, et vous n'arrivez vraiment pas à les gérer.
Un bug entre 2 développements ?
Prenons une situation type : un site e-commerce va être mis en ligne, il n'y a "presque plus" de bugs puisqu'une campagne de tests a été faite, la phase de re-test est terminée, les dernières corrections ont été apportées au site. Tout le plan de lancement est ficelé, les campagnes marketing sont prêtes.
On lance le site. Tout va bien. Les équipes Marketing prennent le relais, scrutent Google Analytics pour voir les chiffres grimper.
Puis, un utilisateur remonte une petite anomalie, puis un autre fait savoir qu'il a des soucis de charge sur un forum ou sur les Réseaux sociaux. Puis l'OS Windows connaît une nouvelle évolution. Puis un nouveau navigateur voit le jour. Puis, un membre de l'équipe fait un retour sur un bug qui s'était bien caché dans le code.
Que faire de toutes ces remontées qui arrivent au fil de l'eau ? Comment les organiser pour les reproduire et par la suite les réparer, sachant que la prochaine phase de développement n'est pas prévue avant quelques mois ?
Pour tous ces bugs, il n'existe malheureusement aucune procédure. La seule solution est : le bricolage en interne.
Les anomalies sont renseignées dans un document, souvent reproduites sur un appareil personnel et corrigées à la va-vite. Ensuite, les équipes prient pour que le bug soit corrigé pour toutes les configurations du marché.
Comment gérer ces bugs simples ?
La plupart de ces bugs identifiés durant les phases d'utilisation sont ponctuels, ciblés, urgents et bien entendu hors stratégie de test. Ils se caractérisent tous comme des tests "simples", isolés, facilement reproductibles, ce qu'on appelle des tâches de test, en anglais Test Tasks.
Ils ne requièrent pas de campagne de test à grande échelle, complexes et longues à organiser, mais ils méritent autant d'attention voire plus car le regard des utilisateurs pèse d'autant plus sur l'image de la marque, le site étant en ligne.
Voici quelques exemples de tests à la tâche :
- reproduction d’un bug remonté par un utilisateur
- test de régression suite à la sortie d'un nouveau smartphone/OS/navigateur
- test d’une nouvelle feature (mini-évolution)
- test d’un template d'emailing
- test du responsive sur mobile
- A/B testing
- test exploratoire
StarDust a créé MyTestingLab.io pour simplifier la réalisation de ces tests d'entre deux développements. C'est un véritable e-shop du test.
Comment ça marche ?
> On commande un test sur MyTestinglab.io via le catalogue de tests ou en décrivant sa propre tâche de test. Il est indispensable de fournir le maximum d’informations pour que le test soit effectué : environnement de test, description du test, URL.
> StarDust valide la tâche de test .
> Les testeurs StaDust exécutent les tests, en laboratoire.
> On reçoit les résultats des tests sous 24 heures (jours ouvrés, à partir de la validation des résultats par StarDust).
> On valide les résultats.
Les équipes ne perdent plus de temps à effectuer les tests. Ils les commandent sur MyTestinglab.io, récupèrent les résultats et apportent les corrections au site.
Le test à l'unité est devenu accessible, moins chronophage et à portée de clic.
