Le rôle du Quality Analyst dans le delivery d’une orga produit

Vous avez sûrement entendu parler, dans les équipes de delivery, du rôle de Quality Analyst (QA). Dans cet article, nous allons décrypter ce rôle essentiel dans les organisations produit et son articulation autour du delivery.

Les responsabilités du QA

Quand on parle de QA, on parle également de testing. Ce rôle essentiel dans les équipes permet d'assurer la bonne réalisation des produits et l’absence de bugs. La responsabilité des QAs : tester en long, en large et à travers le produit.

En effet, un bon produit est avant tout un produit qui fonctionne de manière fluide, intuitive et sans bugs. Si ce n’est pas le cas, l'utilisateur arrête tout simplement de l’utiliser.

La qualité étant primordiale, les besoins de vérification sont nombreux.

Les responsabilités du Quality AnalystSource : https://opensenselabs.com/blog/articles/importance-qa-software-development

Les besoins de testing

Qui dit développement de produits digitaux dit souvent interface utilisateur. Quand on conçoit un produit, on le fait de différentes manières.

La première vérification à laquelle on a généralement recours est la vérification de l'interface utilisateur. Il faut bien sûr regarder si ce que l'on a conçu correspond exactement aux maquettes. Il faut tester si celle-ci fonctionne sur différents navigateurs et formats car il est essentiel aujourd'hui de s'adapter à tout type d'écran (aussi bien d'ordinateur que de téléphone).

Les tests fonctionnels

Derrière l'interface utilisateur se cachent de nombreuses règles métiers (ex : “Quand l’utilisateur clique sur ce bouton, cela renvoie vers une page dédiée”) . Afin de vérifier leur bon développement, il est important de regarder si les critères d'acceptation contenus dans une User Story sont bien respectés. C'est la première étape pour vérifier si le produit fonctionne correctement.

📚 Lire notre article sur les User Stories

C'est pour cela que les règles métiers doivent être obligatoirement présentes dans les Users Stories et écrites avant même le développement de celle-ci.

Les cas de test

Aujourd'hui, très peu de développements concernent des sites statiques. La plupart des produits digitaux offrent une expérience utilisateur personnalisée en fonction de la data de ce dernier. Il est ainsi nécessaire de vérifier différents scénarios en injectant des jeux de données spécifiques sur chaque environnement (développement / qualification ou pré-production) / production) afin de coller le plus possible à l’utilisation réelle.

La non-régression des parcours

Dans des équipes agiles, les développements se faisant de manière itérative, il faut toujours vérifier que les nouveaux développements n'impactent pas ceux qui ont déjà été faits. Il est malheureusement courant qu’une nouvelle évolution puisse altérer le fonctionnement d'une mise en place précédente.

Les langues

L'un des plus gros défis que peut rencontrer une équipe produit est que son site fonctionne dans toutes les langues voulues. C'est en tout cas le plus long à vérifier!

En effet, un gros travail doit être fait pour vérifier l'orthographe complète. Il faut aussi vérifier que l’UI (user interface) s’adapte bien à toutes les langues, puisque la longueur des mots varie selon les langues utilisées.

Les tests End To End

Les tests de bout en bout vérifient le fonctionnement du produit en se focalisant sur les parcours utilisateurs.

Ils sont nécessaires pour affirmer ou infirmer que le front fonctionne parfaitement dans un cas précis d’utilisation du produit et qu'il s'imbrique bien avec toutes les composantes du back développées pour l’occasion.

En général, ces tests suivent un “plan de test de bout en bout” et sont réalisés avant la mise en production de l’application.

Voici un exemple de test :

Scénario : Chloé veut consulter sa consommation téléphonique sur son compte

• Elle arrive sur la page d’accueil
• Elle se connecte à son compte avec ses identifiants
• Elle va dans la rubrique “ma consommation”
• Elle télécharge le relevé de consommation

Résultats :

• Le fichier est téléchargé
• Toutes les informations liées à sa consommation sont remontées

Plan de test de bout en boutSource : https://www.katalon.com/resources-center/blog/end-to-end-e2e-testing/

Les tests techniques

Parmi les tests techniques possibles se trouvent les tests de charge : comme un produit doit pouvoir être utilisé par des millions d'utilisateurs, il doit rester utilisable et efficace en cas d’afflux massif et simultané d’utilisateurs.

Nous en parlions auparavant, la qualité du code est primordiale afin d'assurer la pérennité de la vitesse de développement des fonctionnalités et la non-régression du produit au fur et à mesure des mises en production. Un code bien fait est un code que l'on peut modifier facilement et rapidement, sans altérer le fonctionnement de ce qui a déjà été fait.

Les tests utilisateurs

Les utilisateurs étant au centre du produit, ce sont aussi nos premiers testeurs qui nous assurent une bonne qualité.

Il est important de bien s’outiller de ce côté afin de collecter un maximum de feedbacks et de réagir rapidement en cas de problème.

Quelles solutions de tests pour améliorer la qualité du produit ?

Pour pouvoir répondre efficacement à ces problématiques, les équipes utilisent en général plusieurs types de solutions, listées ci-dessous.

Les tests manuels

La solution la plus connue et la plus classique reste celle des tests effectués manuellement.

Le testeur rejoue tous les parcours utilisateurs à la main pour vérifier à chaque fois que tout fonctionne correctement. Il peut aussi rentrer tous les cas de test et les jouer pour essayer de détecter de nouveaux bugs. Cette méthode est de loin la plus longue et prend énormément de temps, car il faut rejouer les scénarios à chaque fois qu'une nouvelle fonctionnalité est mise en place.

Certains de ces tests restent néanmoins obligatoires : parfois, seule la main humaine peut détecter une anomalie.

Voici quelques exemples d'outils que l'on peut utiliser pour ce type de tests :

• CSS Peer pour l'inspection
• Google Page Speed Insights pour les tests de performance de site web
• BrowserStack pour émuler des navigateurs (et maintenant des applications mobiles)
• Postman pour tester des API

L’automatisation des tests

Certains outils permettent de vérifier automatiquement la qualité du code à chaque nouveau développement. Ces outils dépendent du langage utilisé et sont choisis par l’équipe technique. Ils assurent des standards de code et une homogénéisation de la qualité du code et de son écriture. Ils vont par exemple imposer le respect des alinéas, vérifier que le code ne contient pas de structures inutilement complexes (ex : “case” au lieu de “if” en séries) et peuvent donner des statistiques sur la couverture de test.

D’autres outils permettent de rédiger des scénarios de tests afin de les automatiser et de les jouer à chaque nouvelle version de code.

Cucumber est un des outils les plus populaires, il se base sur la syntaxe Gherkin, proche des critères d’acceptance “Given When Then”.

Cette méthode a pour avantage d'accélérer le testing d'un produit et d'enlever le côté répétitif du test aux QAs.

Les compétences du QA

Faisons un focus très rapide sur les rôles que l’on peut avoir dans une équipe de delivery.

• Le Product Owner est le garant fonctionnel de ce qui sera mis dans le produit.
• Le développeur code ces nouvelles fonctionnalités en respectant les bonnes pratiques de développement.
• Le Quality Analyst mène les tests pour assurer la bonne qualité des livrables et du produit en général. Il sera chargé de mener les tests fonctionnels, techniques et devra en automatiser certains. C’est le gestionnaire et le contrôleur des processus de qualité du code ainsi que de la robustesse de l'architecture.

Parmi ses qualités, une forte communication avec les autres parties est nécessaire afin de pouvoir remonter très rapidement des défaillances qui peuvent surgir lors de certaines phases de test. Il doit aussi avoir un fort esprit d’analyse pour pouvoir trouver les plus petites ambiguïtés qui ne sont pas forcément reconnaissables au premier point de vue ou lors de tests automatisés.

Idéalement, il doit donc avoir des compétences relationnelles et techniques afin de comprendre le processus de réalisation ainsi que des compétences analytiques fortes pour en tirer les conclusions nécessaires dans le but de proposer des axes d'amélioration.

Alors, faut-il ou non un QA dans une organisation produit ?

Tout dépend du type d’organisation

Le rôle et la nécessité d’un QA dépend du type d'organisation dans laquelle il évolue.

Dans les petites équipes qui gèrent de petits produits, ce rôle peut être absorbé par le Product Owner et les développeurs qui consacrent une partie de leur temps pour garantir au maximum la qualité du produit en faisant des tests fonctionnels et automatiques.

Dans les grandes entreprises où plusieurs équipes peuvent travailler en même temps sur un produit, il y a besoin de vérifier la cohérence du produit au niveau global et de valider l'ensemble des développements réalisés par tous les départements. C’est aussi le cas pour un produit assez complexe, qui demande des validations constantes (comme dans le cas d’un ERP par exemple). Des personnes peuvent donc être dédiées à la qualité globale du produit.

La clé : l’automatisation

Dans tous les cas, une automatisation systématique des tests doit être mise en place pour assurer une qualité maximale du produit. En effet, plus le produit est complexe, moins il est évident de réaliser des tests manuels, compte tenu du nombre de cas à couvrir. Seule l'automatisation peut garantir une non-régression au fur et à mesure des développements.

Test manuel vs test automatiqueSource : https://laptrinhx.com/test-automation-our-challenges-and-how-to-overcome-them-3550213372/

L'automatisation permet aussi d’assurer un delivery continu et rapide du produit. Prenons l’exemple de Doctolib, qui fait évoluer son produit tous les jours grâce à des mises en production quotidiennes. Une livraison continue n’est possible que grâce à une automatisation complète des tests. Dans leur organisation, aucun QA n’est présent. Les développeurs sont chargés de l'automatisation des tests et les Product Managers des tests End to End.

La qualité avant tout

La place du QA est encore floue dans les frameworks Agiles et produit. C'est pourquoi chaque organisation a recours à une équipe de QA en fonction de ses besoins.

Des garants de la qualité seront toujours nécessaires dans les organisations produit. La qualité du produit étant l'affaire de tous, ce rôle peut être divisé entre les Product Managers et les développeurs. Le principal frein aujourd'hui est le manque de temps qu’ont ces rôles pour pouvoir assurer une qualité optimale, d'où la présence de QA dédiés.

En conclusion

La présence d’un Quality Analyst est aujourd’hui importante dans les organisations produit, afin de tester le bon fonctionnement du produit. Cependant, il est nécessaire d’avoir recours à une équipe de QAs en fonction de ses besoins. La présence d’un QA en permanence n’a de sens que lorsque l’automatisation des tests n’est pas suffisante pour assurer une bonne qualité des produits.