New Version of FRED, Testing Was Its Foundational

On the 15th of November, following the prior maintenance notification, our system administrators have successfully installed a new version of FRED, the system that is the basis of the .cz domain name registry (as well as national domain name registries in a dozen of other countries). What does that actually mean though?

Well, firstly, that you will see no more posts on this topic — that is, if everything went as it should have. Simply because the result is again a fully functional .cz registry, no people stay in queues, no overloaded or collapsing systems. There’s just nothing for the prime time of the evening news or the cover pages of our newspapers. But what might be in the technical note?
The FRED version 2.33, on which the .cz registry is now running, has brought only a few changes, but their implementation required considerable effort from our developers and testers. We have continued rewriting the EPP part (to upgrade it and enhance safety), which is used for communication between the domain registry and registrars. This time, new code was introduced in methods for polling messages and credit management; these changes, however, were designed to leave the existing interface unchanged. Only changes to the ‘reason’ element text in EPP responses were made, as well as minor modifications to the ‘result code’. The new version of FRED also provides the ability to manage mailing addresses via EPP, which will be only turned on after it is tested by the registrars at the beginning of 2018. Furthermore, we have implemented a new version of contacts merging that eliminates duplicates in the registry. This new version will be launched in the coming weeks. New version of FRED also includes other, minor changes, especially for optimizing internal work with registry data by our customer support operators.

It might seem that this wraps up the description of new features of the 2.33 version. However, the opposite is true: by far, the biggest benefit was that we have greatly improved the tools for testing new versions of FRED. We have invested more than two months of work in the new testing framework, and not just that of testers, but also of backend developers, who I would like to thank for temporarily leaving their tasks and making a significant contribution to improving the efficiency of the testers’ work. Thanks to a combination of testers’ and developers’ experience, we have built a testing framework for the backend part of the central registry that enables simple implementation of test cases so the test implementer can focus more on the important part, i.e. WHAT needs to be tested and not HOW it should be tested. In addition, the test implementer is not burdened by generic checks that are performed internally in the testing framework. To illustrate it with two examples, the EPP response timestamp generated by the server must represent a valid time between the sending of the request to the server and obtaining the response. The second example — in a negative scenario that is not supposed to end with success, the data of the object in the registry must not be changed. The development was preceded by definition of test cases, which we used not only for the implementation of tests but also for the analysis and development of the framework. With the new testing framework, we have already implemented nearly 2000 prioritized tests, and a few more hundreds of middle-priority tests are scheduled to be completed later. We assume that the above-standard investment in the testing framework will be worthwhile not only for this version of FRED, but for all versions to come, as it will eliminate a huge package of manual tester work that would have to be done with every major intervention in EPP.

We had so much work that we used our smart wall to improve the visualization of the work progress. And I’m not surprised that on one Friday night, Pac-Man and Space Intruders appeared on the wall as well…

Author:

Leave a comment

All fields are required. Email won't be shown.