Les premiers jours du QA : mode d'emploi

L’arrivée dans une nouvelle entreprise est toujours un moment particulier, avec un mélange d’excitation et d’appréhension. On quitte notre zone de confort où nous avions nos repères, où on connaissait le système, où nous étions probablement reconnu… pour passer dans un autre où nous avons quasiment tout à apprendre : les collègues, les technologies, les méthodes, potentiellement de nouvelles responsabilités.

Et puis il faut aussi parfois gérer nos désillusions : on nous a vendu monts et merveilles en entretien, et on découvre finalement l’envers (l’enfer ?) du décor, avec au choix : des bugs un peu partout dans l’application, des process tordus, des outils pas adaptés, des problèmes de communication, etc…

https://www.monkeyuser.com/2017/interview-vs-reality/

Face à toutes ces émotions, en tant que QA, on peut se sentir légitime de tout remettre en question et de se lancer dans plein de chantiers d’amélioration… On peut avoir la meilleure intention du monde, mais au final, complètement se planter !

Dans cet article, je vous propose quelques idées pour bien aborder votre futur poste de QA. Bien évidemment, je ne parle pas des missions de conseil ou de freelance qui ont leurs propres objectifs.

Rappels généraux

Dans un premier temps, rien ne vaut quelques rappels génériques, non spécifiques au métier de QA :

Le premier mois, prenez des notes de tout ce qui vous passe par la tête (idées d’amélioration, questions, pense-bêtes…) : relisez ces notes régulièrement, et réordonnez les pour en extraire les éléments essentiels pour votre debrief du premier mois.
Si cet entretien de fin de mois n’est pas prévu, demandez le ! Ce debrief est essentiel pour vous assurer que vous savez ce que votre manager attend de vous (et réciproquement). Il vous permet aussi de présenter votre état des lieux de l’entreprise, voire de suggérer de petites améliorations : le plus important dans ce cas est de viser petit. Ne cherchez pas à tout de suite bouleverser l’organisation de l’entreprise.
On ne le dira jamais assez, et a fortiori lors d’une prise de poste : la seule question stupide est celle qui n’est pas posée, donc lâchez vous ! L’arrivée en entreprise est le moment parfait pour poser toutes vos questions, et personne ne pourra vous le reprocher. Plus le temps passera, et moins vous oserez demander des précisions sur un sujet que vous êtes censés connaitre, au risque de vous décrédibiliser. L’autre point positif des questions est de vous faire connaitre par les différentes personnes de l’équipe, c’est un moyen simple de s’intégrer.

La QA, c’est de la technique…

Ce qu’on attend souvent d’un QA, c’est qu’il connaisse l’application par coeur. Par exemple, si un PO a une question sur l’enchaînement des actions dans une fonctionnalité, il ne va pas faire la procédure lui-même, il va plutôt demander au QA, c’est plus rapide !

Testez l’application

Suivant ce postulat (un peu caricaturé, je l’accorde), le mieux est de tester l’application manuellement, mais de la tester vraiment beaucoup. On se fait des séances de tests exploratoires. Les premiers jours, on bidouille un peu partout pour comprendre le logiciel dans son ensemble. Puis petit à petit, on se donne des périmètres plus précis pour chaque demi-journée (le système de paiements, les interactions entre les utilisateurs, etc…). Bref, retournez le système dans tous les sens, et faites en sorte de le connaitre sur le bout des doigts !

Bien évidemment, qui dit “tests exploratoires” dit « absence de procédures de test”. Je pense que dans un premier temps, c’est une bonne chose. Ecrire des procédures de test nécessite de connaitre exactement les bonnes conditions pour chaque situation, ce qui ne vient qu’avec la pratique. Ne perdez donc pas de temps là dessus, vous risqueriez de devoir retravailler vos procédures très régulièrement les premiers jours, et donc de perdre un temps précieux !

Remontez les bugs

La bonne nouvelle avec l’étape précédente, c’est qu’on trouve très souvent pas mal de bugs.

Et ça tombe bien puisque c’est exactement l’autre truc que les gens attendent de la QA. Considérez cela comme des petits points positifs facilement gagnés auprès du reste de l’équipe ! Pour autant, n’allez pas trop vite en besogne en les remontant directement dans l’outil de gestion des bugs : faites vous une liste de tout ce que vous trouvez, et présentez les à votre manager ou référent technique. Il y aura forcément une partie de ce que vous avez trouvé qui est déjà connu, qui tient du legacy de l’entreprise, voire qui fait volontairement ! Cette petite réunion vous permettra de ne pas remonter de bugs inutiles, mais surtout de vous faire évaluer par votre manager. La qualité (et la quantité) des bugs que vous lui remonterez sera autant de crédibilité gagnée.

Une fois ce tri fait, il s’agit de les remonter dans le gestionnaire de bugs. Aidez vous de mon article pour bien rédiger ces tickets (https://allaboutqablog.com/comment-creer-un-bon-ticket-de-bug/) : le plus important étant de rédiger des procédures parfaites ! Ces tickets de bugs seront le premier contact entre vous et les développeurs, et leur avis sur vous se basera en grande partie sur ce travail. Les développeurs qui comprendront vos tickets en un minimum de temps seront vos alliés et supports de demain pour des changements plus profonds. Soyez donc particulièrement attentifs à cette étape, elle est cruciale !

Et l’automatisation dans tout ça ?

A moins d’être déjà un expert dans ce domaine, je ne vous conseille pas de vous lancer avant plusieurs semaines dans un projet d’automatisation de tests, et ce pour plusieurs raisons :

vous n’aurez pas le recul nécessaire pour savoir quels tests doivent être automatisés en priorité
les tests automatisés sont coûteux à mettre en place
leur maintenance peut vite être chronophage

En résumé, les tests automatisés ne sont pas des “quick wins”, et ne vous permettront pas d’avoir une bonne visibilité dans l’équipe rapidement.

Par contre, si vous souhaitez quand même coder un peu, n’hésitez pas à implémenter des scripts pour vous simplifier la vie. Vous pouvez par exemple rédiger des scripts qui génèrent des utilisateurs dans différents états, ou encore qui créent des projets dans des configurations spécifiques, etc… A l’inverse des tests automatisés, les scripts présentent de nombreux atouts :

ils permettent d’utiliser (et donc d’apprendre) le fonctionnement de l’API
leur retour sur investissement est extrêmement rapide (utilisez-les dans vos tests exploratoires)
ils améliorent votre visibilité puisque les développeurs aussi seront heureux de les utiliser
ils vous seront utiles dans vos projets d’automatisation pour vous mettre dans des configurations précises

…Mais c’est aussi de l’organisationnel

La QA est le garant des bonnes pratiques organisationnelles. En ce sens, vous êtes légitimes pour suggérer des changements de méthodologie. Mais c‘est évident, dans un premier temps, respectez les règles de l’équipe, les cérémonies, les méthodes utilisées… Assimilez les le plus vite possible pour être opérationnel rapidement, tout en gardant un esprit critique : notez tout ce qui vous semble superflu, manquant ou inadapté. Lors de votre entretien de fin de premier mois, abordez ces points là, mais gardez bien en tête que :

avant de présenter vos suggestions, présentez des faits (“j’ai remarqué qu’on ne formalisait pas les fins de cycles : on ne prend pas de temps d’analyser ce qu’on a fait, en bien ou en mal”, ou encore “sur ces tickets, on s’est lancé dans l’implémentation sans avoir le design de prêt”, etc…)
il est beaucoup plus facile d’ajouter un processus que de modifier ou de retirer un processus existant
visez petit, opérationnel, et facile à mettre en place

Priorisez ce que vous allez présenter en fonction de ces critères. Et si vos propositions sont rejetées, ne le prenez pas personnellement : l’entreprise a une histoire, et atteindre sa méthodologie n’a peut être pas été sans peine. C’est votre rôle de QA de vous adapter.

« Qui veut déplacer une montagne commence par déplacer de petites pierres. »

Ce qu’il faut retenir

Posez des questions
Apprenez l’application par coeur en la testant
Remontez des tickets de bugs parfait
Privilégiez les scripts utilitaires aux tests automatisés
Préparez votre entretien de fin de premier mois
Proposez de petites améliorations de processus en entretien

Les premiers jours du QA : mode d’emploi