Tests to ensure high quality

In 2009, Afnic decided to set up a department dedicated to testing, reflecting the prime importance given to product and service quality. The testing team makes sure that the service provided by Afnic conforms to the expectations of its registrars, registry clients and domain name holders.

Testing, with the Product Owners and Release Management teams, forms part of Quality Assurance, which in turn is part of the Information Systems Division.

History of testing

Testing consists in carrying out various kinds of checks on developments that are under way. We carry out functional tests mainly on our EPP interface, APIs, and the Registrars’ Extranet. These tests may also concern our Whois service (the directory of domain names managed by Afnic) and RDAP (Registration Data Access Protocol), or even the registrar accreditation procedure.

Agile methodology, in use since 2018, has enabled us to deliver developments more and more frequently.

So in just a few years, the team has gone from the first manual tests using spreadsheets to tests that are automated by means of a tool used in all environments – development, pre-production, sandbox and production – and for all top-level domain names managed by Afnic.

The test specifications, including the verification of functional and security requirements, are drawn up based on recommendations from the ISTQB (International Software Testing Qualifications Board).

The tickets describing new functionalities are analysed each week with the support of the development team, the Products Owners and the Marketing & Sales Division.

Once these functionalities have been delivered, the hunt for bugs is on!

Whatever it takes to maintain the high performance of the .fr domain!

The pace of releases is around ten a year for the .fr TLD. For each release there are thousands of non-regression tests performed automatically before each release goes to the sandbox (testing environment). The purpose of non-regression tests (NRTs) is to make sure that the latest developments are free of side effects that alter the existing functionalities provided by those parts of the code that have not been modified.

These automated tests allow gains in speed and completeness, thus improving our level of confidence in releases that do not contain functional or security regressions.

All the results of our testing campaigns are stored in a ‘bug tracking’ tool which is used for regular and rigorous monitoring. During the quality reviews carried out at the end of each sprint (a ‘sprint’, in the agile method, is a defined period needed by a development team to perform a given volume of work), the results are shared with the rest of the team and with the Sales Division. It is this that leads to the ‘Go/No Go’ decision announced prior to commissioning.

It's a hard life for a bug!

How are software anomalies, better known as bugs, flushed out? Bugs may be detected when testing a new functionality, or in a non-regression test, or if they pass through the mesh of the first nets, an expert eye may spot them later. There’s no miracle insecticide spray, but rather a whole process set in motion. Each bug will have a ticket number that will follow it everywhere it goes, and it will be tracked and described in detail for the development team. It will be thoroughly analysed, corrected and dissected, then re-tested to make sure it hasn’t left any spores in other parts of the code.

It is only on this condition that the correction will be definitively validated by testing so that the ticket for the resolved bug can be sent to production. As you will have gathered, with testing the watchword is quality, which we take very seriously.

Every day we play the role of interface, putting ourselves in the shoes of our clients and users in order to ensure optimal usability of all our services.