Comment configurer une fonction d'assurance qualité à partir de zéro

C'est un scénario habituel: une start-up a une nouvelle idée et engage un certain nombre de développeurs pour construire un modèle de travail de l'idée.

En raison de la nature des startups, c'est-à-dire du peu de financement disponible avec un court laps de temps pour développer l'idée, l'effort principal est concentré sur la construction du nouveau produit pour le faire connaître au public pour tester les eaux, et donc naturellement, tester et l'assurance qualité n'est pas la priorité absolue de l'équipe de développement.

Une fois qu'il est devenu évident que l'idée a été un succès, la société souhaite développer l'idée et commence à embaucher plus de développeurs, mais en même temps, elle souhaite également que le produit soit testé avant qu'il ne soit rendu public.


Pendant un certain temps, les tests sont effectués par quiconque est disponible dans l'entreprise, et ils sont en grande partie ad hoc sans processus appropriés à suivre.

Puis vient un moment où la start-up décide d'embaucher son premier responsable QA senior pour commencer à mettre en œuvre un nouveau processus d'assurance qualité pour l'équipe de développement.


Aux fins de cet article, je vais supposer que la startup est une entreprise basée sur le Web, par exemple un site Web de commerce électronique.



Mettre en œuvre un processus d'assurance qualité

L'objectif principal d'un processus d'assurance qualité est de s'assurer que le bon produit est construit correctement, du premier coup. Cela signifie que nous devons nous assurer que les exigences sont correctement définies et que l'équipe de développement a une solide compréhension des fonctionnalités des nouvelles fonctionnalités avant de commencer à coder.

Il est important de noter que le test n'est pas une phase, c'est une activité et que le test commence dès le tout début du processus de développement, dès le moment où les user stories sont écrites.

Les tests doivent soutenir le développement et les activités de test sont donc parallèles aux activités de développement, et à chaque étape du processus de développement, nous devons nous assurer que le code est testé de manière approfondie.


Avant de mettre en œuvre un processus de test, nous devons connaître la méthodologie et le processus de développement actuels et, si nécessaire, faire des ajustements pour améliorer le processus.

Test de régression / Test de sprint

Lorsque vous commencez en tant que première personne chargée du contrôle qualité de l'entreprise, il est probable qu'aucun test de régression n'est en place et que, au fur et à mesure que de nouvelles fonctionnalités sont développées, vous ne savez pas si elles ont un impact négatif sur le site Web opérationnel actuel. De plus, vous devez suivre l'équipe de développement pour tester les nouvelles fonctionnalités afin de vous assurer qu'elles fonctionnent correctement et conformément aux spécifications.

Il y a au moins deux tâches en parallèle: tester de nouvelles histoires dans le sprint et effectuer un certain degré de test de régression.

Le test des nouvelles fonctionnalités est prioritaire car il y a plus de chances de trouver des bogues dans le nouveau code que de casser le site de travail actuel. Mais, en même temps, des tests de régression sont nécessaires pour garantir que l'application existante continue de fonctionner au fur et à mesure que nous développons de nouvelles fonctionnalités.


Un pack de test de régression doit être exécuté dès qu'il y a une mise à jour de l'application, afin que l'équipe de développement puisse obtenir retour rapide sur la santé de l'application.

Il n'y a pas assez de temps pour écrire des tests de régression et pour suivre les tests de nouvelles fonctionnalités. Comment briser ce cycle?

Habituellement, pendant les premiers jours du sprint, les développeurs sont occupés à coder et les nouvelles fonctionnalités ne seront donc pas prêtes à être testées pendant un certain temps. Voici une bonne chance de commencer à travailler sur les tests de régression.

Il existe des bonnes pratiques pour les tests de régression, mais en général, l'approche consisterait à identifier les principaux parcours des utilisateurs de base sur le site Web, de sorte qu'à chaque nouvelle version du site Web, nous puissions être sûrs que l'application est toujours utilisable par la majorité de ses utilisateurs. utilisateurs.


Il n'est pas nécessaire d'avoir une liste exhaustive de ces scénarios, seuls les principaux et les plus importants suffiront pour démarrer un petit pack de régression qui peut être exécuté sur chaque build. Plus tard, à mesure que le pack de régression mûrit, nous pouvons commencer à ajouter d'autres scénarios.

Plus important encore, ces scénarios de régression doivent être automatisés.

Test automatisé

Dans un projet agile, où un sprint dure généralement environ deux semaines, il n'y a pas assez de temps pour faire tous les tests manuellement. Il y a des tests de nouvelles histoires ainsi que des tests de régression. S'il est logique de faire des tests exploratoires pour tester de nouvelles fonctionnalités, les tests de régression doivent être automatisés pour réduire la tâche banale d'exécuter manuellement les mêmes tests à plusieurs reprises.

Déploiement / construction du pipeline

Un déploiement ou un pipeline de construction dans un projet agile définit comment une histoire passe du backlog de produit au site de production en direct. Il définit un processus et les activités qui se produisent à chaque étape.


Afin de mettre en œuvre un processus d'AQ réussi qui garantit que nous publions fréquemment du code de qualité, le pipeline de déploiement doit être défini et respecté par toutes les parties prenantes. Le pipeline de déploiement est la colonne vertébrale de la livraison de logiciels.

Le pipeline doit être basé sur les meilleures pratiques et englober les activités qui se produisent à chaque étape.

Ateliers d'histoire

L'une des activités les plus importantes d'un projet agile est la fréquence des ateliers sur l'histoire. C'est à ce moment que le propriétaire du produit, les développeurs et les testeurs se réunissent dans une pièce et commencent à élaborer et à étoffer les détails des histoires. Ceci est important car tout le monde doit avoir la même compréhension de l'histoire avant de commencer le travail de développement.

L'assurance qualité concerne la prévention des défauts plutôt que la détection.Ainsi, dans les ateliers d'histoire, l'équipe a la possibilité de poser des questions sur les détails de l'histoire, les contraintes techniques ou de conception et les obstacles au développement des histoires.

Voici une excellente occasion de commencer à rédiger les critères d'acceptation des histoires. Tout le monde devrait contribuer et commencer à réfléchir aux scénarios possibles pour chaque histoire, car chacun aura une idée différente, donc plus il y a de têtes sur l'histoire, plus on peut penser à des scénarios et plus il y a de chances d'empêcher les défauts de se concrétiser.

Une fois que tout le monde est certain du détail et de la portée de chaque histoire, le développement commence.

Test du développeur / test pendant le développement

Tout le monde doit être responsable de la qualité du produit et pas seulement les testeurs. En tant que tel, il doit y avoir une quantité suffisante de «tests du développeur» pour s'assurer que le code écrit est de haute qualité avant d'être déployé dans un environnement de test pour des tests supplémentaires.

Il est certain que chaque nouvelle fonctionnalité devrait être bien testée à l'unité. En plus de cela, il doit y avoir des tests d'intégration, des tests d'API ainsi que des tests d'interface utilisateur.

Les revues de code par les pairs ou les «tests d'amis» peuvent mettre un second œil sur le travail du développeur. Un testeur peut aider à passer en revue les tests unitaires et les tests API pour s'assurer que les tests corrects ont été écrits, ainsi qu'à écrire les tests d'interface utilisateur automatisés de haut niveau.

Intégration continue / Environnements de test

Afin de tester efficacement les nouvelles fonctionnalités, nous devons nous assurer que le code fonctionne non seulement sur la machine du développeur, mais également sur d'autres environnements, et intégré au code d'autres développeurs.

L'intégration continue aide à identifier tout problème de build dès le début du processus, de sorte qu'en cas d'échec du déploiement, nous puissions commencer à chercher d'où vient le problème.

Les environnements de test permettent aux testeurs et aux autres membres de l'équipe de tester les nouvelles fonctionnalités avant de les mettre en ligne.

Tests non fonctionnels

Si nécessaire, nous devons également effectuer des tests non fonctionnels, tels que des tests de performances, de charge et de sécurité. Bien souvent, l'accent est mis sur le bon fonctionnement de la fonctionnalité, mais les tests non fonctionnels doivent avoir la même priorité, en particulier pour les applications Web, car elles pourraient être soumises à une charge importante et / ou à des attaques.

En effectuant des tests non fonctionnels, nous pouvons être sûrs que notre application peut gérer la charge pendant les périodes de pointe et qu'elle n'est pas exposée aux menaces de sécurité.

Autres points à considérer

  • Tests multi-navigateurs, multi-appareils
  • Test mobile et tablette
  • Exécution parallèle de tests automatisés
  • Essais exploratoires
  • Des outils tels que Jira, Jenkins, Selenium, etc…
  • Amélioration continue
  • Recrutement des testeurs