L’Afnic dispose d’un pôle « Testing » qui permet d’industrialiser l’activité de test. Son objectif : débusquer avant chaque déploiement logiciel un maximum d’anomalies. Découvrez la stratégie de test mise en place par l’équipe pour tous les publics Afnic (bureaux d’enregistrement, clients Registres et titulaires de nom de domaine).
La qualité de ses services et produits étant au cœur de ses préoccupations, l’Afnic a choisi en 2009 de créer un pôle dédié au « testing ». Son équipe vérifie que l’Afnic fournit un service conforme à l’expérience attendue par ses Bureaux d’Enregistrement, ses clients Registres et par les titulaires de noms de domaine.
Au sein de la DSI (Direction des Systèmes d’Information), le testing est intégré au service « Assurance et Qualité » avec les équipes de Product Owners et du Release Management.
Le saviez-vous ?
Un product owner est une appellation issue de la « méthodologie de développement agile » ; il représente le besoin du métier (par exemple : j’ai besoin d’un parcours client plus fluide). Le release manager quant à lui s’assure que la mise en production est conforme avec toutes les optimisations apportées et en mesure les impacts.
Une histoire de tests
Le « testing » consiste à effectuer différents types de vérifications sur des développements en cours. Nous effectuons des tests fonctionnels principalement sur notre interface EPP, les API, l’Extranet Bureaux d’enregistrement. Ces tests peuvent aussi concerner nos services Whois (le service d’annuaires des noms de domaine gérés par l’Afnic) et RDAP (service d’accès aux données d’enregistrement), ou même encore la procédure d’accréditation des Bureaux d’Enregistrement.
Depuis 2018, l’application de la méthode agile a permis de faire évoluer la fréquence de livraison des développements. L’équipe est donc passée en quelques années des premiers tests manuels sur des tableurs à des tests automatisés via un outil utilisé sur tous les environnements : développement, pré-production, sandbox (« bac à sable » ou environnement spécifique de test), production et ce, pour tous les noms de domaine de premier niveau gérés par l’Afnic.
Les cahiers de tests, incluant la vérification des exigences fonctionnelles et de sécurité, sont rédigés en s’appuyant sur les recommandations de l’ISTQB (Comité international de qualification du test logiciel).
Les tickets décrivant des nouvelles fonctionnalités sont analysés chaque semaine avec l’appui de l’équipe de développement, des Products Owners et de la Direction Marketing et Commerciale.
Une fois ces fonctionnalités livrées, la chasse aux bugs est ouverte !
Il faut ce qu’il faut pour garder un .fr performant !
Le rythme des « Releases », les mises en production, est d’une dizaine par an pour le .fr. Pour chaque mise en production, ce sont des milliers de tests de non régression qui sont lancés de manière automatique avant chaque mise en « sandbox » (environnement de test fonctionnel). Les tests de non régression (appelés TNR) ont pour but de s’assurer que les derniers développements n’ont pas entrainé d’effet de bord, en altérant les fonctionnalités existantes fournies par les parties du code non modifiées.
Ces tests automatisés permettent de gagner en rapidité et en exhaustivité, améliorant ainsi notre niveau de confiance dans des mises en production qui ne contiennent pas de régressions fonctionnelles ou de sécurité.
Tous les résultats de nos campagnes de test sont consignés dans un outil de « bug tracking » (outil de gestion des anomalies) pour permettre un suivi régulier et rigoureux. Lors des revues de qualité effectuées à la fin de chaque sprint (un « sprint », dans la méthode agile, désigne une période limitée dans le temps dont une équipe de développement a besoin pour effectuer une quantité de travail donnée), les résultats sont partagés avec le reste de l’équipe et avec la Direction Commerciale. C’est ce qui conduit à la prononciation du « Go/No Go » préalable à la livraison en production.
3 qualités pour être un bon testeur / une bonne testeuse : rigueur, méthode et curiosité !
Dure est la vie d’un bug !
Comment sont éjectées les anomalies logicielles mieux connues sont le nom de bug ? Le bug est, selon les cas, détecté au plus tôt lors du test d’une nouvelle fonctionnalité ou lors d’un TNR, ou un peu plus tard s’il est passé à travers les mailles de ces premiers filets, un œil aguerri le découvrira. Alors point de spray insecticide, mais tout un process qui se déclenche. Traqué, décrit avec tous les détails pour l’équipe de développement, il aura un numéro de ticket qui le suivra partout. Il sera analysé, corrigé, décortiqué dans tous les sens, puis testé à nouveau, pour vérifier qu’il n’a pas laissé « de petits œufs » dans d’autres endroits du code.
C’est à cette unique condition que sa correction obtiendra la validation finale du testing, pour que le ticket de bug résolu soit envoyé en production. Vous l’aurez compris, la qualité est le maître mot du testing, et on ne plaisante pas avec ça.
Jouant le rôle d’interface, nous nous mettons dans la peau à la fois de nos clients et de nos utilisateurs chaque jour pour assurer une meilleure utilisation de tous nos services.