ERiC Files the Tax Report

This second part of the two-part article continues to describe the successful introduction of a proven methodology for quality assurance on the development side according to the principle “Very Early testing” with ERiC (ELSTER Rich Client) by showing in detail how the VET method was introduced to the ERiC project, done by mgm technology partners with Alexander von Helmersen of the Bayerisches Landesamt für Steuern and their teams.

ELSTER [1] (a German language acronym for Electronic Tax Return, ELektronische STeuerERklärung) is a joint project of all tax administration authorities of the Federal States and the Federal Ministry of Finance in Germany to enable secure electronic communication between taxpayers and the tax authorities.

One of the most-widely used parts of ELSTER is ERiC (Elster Rich Client), a library written in C/C++ which provides a secure encrypted transmission of tax data to the German tax authorities. It also validates the data and creates print versions of the declared tax data in PDF for the user. ERiC handles more than 20 different tax types. The most prominent example is: the compressed declaration of the income tax return. Up to now, ca. 70 million tax returns and several hundred million tax announcements have been filed using ERiC.

ERiC is an integral part of every tax software product for the German market, e.g. WISO, Steuersparerklärung or DATEV. It is also embedded in the rich client tax application product “Elster Formular” provided free of charge by the German tax authorities for the electronic transmission of tax declarations, see ELSTERWEB – Information for developers [2].

As ERiC is a library integrated into other products, with each release versions for a broad range of supported runtime environments have to be delivered. Likewise comprehensive documentation and manuals for the software vendors integrating the library into their products have to be put together.

ERiC supports all major Client platforms for Home Users as well as Enterprise operating systems: Windows platforms (Windows Server 2008, Windows Server 2012, Windows 7, and Windows 8), several Linux distributions as well as Apple Mac OSX from version 10.7, see Overview – Which ELSTER products can be used with which operation system [3]. Additionally, it is prepared to be embedded in various runtime environments based on all currently relevant programming languages like C, C++, C#, VB, Delphi or Java.

Challenges of the ERiC project

ERiC has a product history of more than 15 years. Especially during the last years of rapidly growing requests for comprehensive e-government services, the functionality of ERiC and the requirements regarding support for many heterogeneous platforms and runtime environments have grown dramatically. [4]

On the functional side, support of many new tax types was added to ERiC. On the technical side, many programming languages and operating system versions were added to the list of supported platforms. On the organizational side, ERiC has to support all functionality for up to 10 tax years backwards. In addition the delivery dates and updates to the tax code have to be implemented “complete and correct” and delivered to software vendors in a timely manner before the new legislation comes into effect. This timeline has to be followed strictly while on the other hand, as it is well known reality in many business critical projects, late functional changes are often introduced at short notice before the release deadline.

The software development process for each release is divided into a development phase and a stabilization phase at the end of the release. Prereleases have to be delivered to software vendors for integration testing and to the quality assurance department of ELSTER for functional testing. During the stabilization phase, defect correction has to compete with the implementation of requirements or late changes for development resources. In the past, this led to a heavy load for the developers and let defects slip into the field, which had to be corrected through the delivery of patches, which once again led to additional load for the developers now already working on the requirements for the next release.

To enable a solid management of all these requirements and interdependencies and to enable the team to guarantee the delivery of high quality for every release under any circumstances, the proven and very effective technical quality assurance methodology based on the principles of “Very Early Testing” was introduced successfully to the ERiC project.

1: Timeline VET introduction to the ERiC project.

Introducing “Very Early Testing” to ERiC

The introduction of a new development methodology to a running project is risky. Changes cause friction during the introduction and additional effort and can lead to schedule problems. Since the required content of ERiC is defined by legislation and cannot easily be reduced and as delivery dates are defined by the fiscal year, a new methodology had to be introduced in a way as to avoid jeopardizing the fulfillment of the requirements or exceeding the deadline.

ERiC has two releases per year. One around May 15th, the other around November 15th. During the QA phase of the November release, a beta release is delivered to software vendors for final integration tests and to the central ELSTER quality assurance department. It verifies at acceptance that the provided functionality meets the technical requirements. The task of the new, development-accompanying ERiC QA team was to introduce additional tests earlier in the process and more on the technical level with higher automation. See Figure 1 for what was done in detail.

The tasks in the team became more and more heterogeneous. Some tasks are long running development tasks for new infrastructure like implementing a test frame for the communication of ERiC with the server. Other tasks are short and time critical like executing an installation test or a delivery. To enable team members to focus on single tasks instead of working on parallel tasks with many interruptions, the following organizational regulations have been useful:

  • For each delivery a test master is selected who builds a task force from the QA team members for the testing of a delivery. He is responsible for selecting the tests necessary for a delivery, for setting up the task force, organizing the execution of the tests and for the provision of a summary of the results to the product manager.
  • The role test master is rotated between all team members, so that everybody is able to fulfill this task.
  • New team members first become test masters of non-critical deliveries until their experience is sufficient for the management of critical deliveries towards the end of the release.

The advantage of this approach is that there is only one owner of the QA for a delivery with a 100% focus on the execution of the QA and the final quality assessment of the delivery, which avoids delays or errors due to misunderstandings. In addition, the other team members, who are not in the task force for this delivery, can continue their work on tasks of the backlog like the analysis of new requirements, the creation of test cases, increasing the automation and improving the test infrastructure without interruption.

2: Major reduction of defects by introducing VET to the ERiC project.

Achievements of “Very Early Testing” for ERiC

The extremely positive effects of introducing “Very Early Testing” to ERiC were already clearly visible after one year (Fig. 2).
Due to the high test coverage made possible by the concept of Very Early Testing and the thereby reached high grade of reliability of the development-accompanying QA, the development team was able to do a major refactoring of the code basis and the provided API to simplify the usage of the product and its internal structure. More functionality was provided by a less complex technical infrastructure. This contributes to a decisively easier maintenance and thereby indirectly additionally helps avoiding defects.

This article was first published in German in JavaMagazin, 2.2015. Please click the picture for PDF download of the magazine article.

Links and Literature

[1] ELSTER – The electronic tax return [Die elektronische Steuererklärung]: https://www.elster.de/ .

[2] ELSTERWEB – Information for developers: https://www.elster.de/ent_angebot.php .

[3] Overview – Which ELSTER products can be used with which operation system: https://www.elster.de/untplat_nw.php .

[4] The chronological development of the electronic tax return is summarised in the paragraph “History”: http://de.wikipedia.org/wiki/ELSTER .

Martin Varendorff. A Practitioner’s Guide to Successful Software Testing, Part 1. Developers, Don’t Write Functional Tests!

Martin Varendorff. A Practitioner’s Guide to Successful Software Testing, Part 2. Why Functional Tests don’t belong in a Build Environment.

Share

Leave a Reply

*