Jean asked me to also write an article for his blog; thanks for this offer, Jean.

Having learned in one of Jean’s articles a lot about the trench warfares behind the scenes let’s come back to the normal working live.

Implementing such a converter is only one part of the medal. The other is testing all the code drops the developers produce. As already mentioned by Jean, this takes place twice a week. Consequently, testing is a continuous process which has to check new feature conversions integrated in a release but also whether the new release did not re-introduce “old” errors (this is done via the regression tests).

There are two companies involved in testing: AztecSoft in India and we, DIaLOGIKa, in Germany.

Why two companies?

There are some good arguments to split the testing. AztecSoft focuses more on feature testing, i.e. they send a lot of documents containing only one specific formatting or layout feature through the converter and check the result, e.g. documents containing frames or documents containing footnotes, etc. Such a feature testing is necessary, even mandatory, and AztecSoft really does a great job here.

But what do we do?

We also test, however, we test real documents, i.e. day-to-day documents created in the EU institutions or found in the Internet. Our testing is oriented towards actual usage scenarios such as: A European company sends a technical specification in ODT format to the European Commission for being commented. The Commission internally uses Word only, i.e. the document must be converted to Word, commented by the Commission, re-converted to ODT and returned to that company.

Another example: An EU agency makes standardised CVs and language passports available for the EU citizens on their web site. Since a considerable number of citizens might use OpenOffice instead of Word the agency publishes the documents in Word and ODT format. In order to save time, the documents are created in one format, converted to the other and then fine-tuned.

Our real documents contain a good mix of various and sometimes rare features which challenge the converter (and probably its developers as well). This mix makes the difference to the mere feature testing: a feature alone might be properly converted, however, the feature mix exhibits the problems.

And there is another argument: When the converter has finally passed this real document feature mix testing we can be quite sure that will also be usable in our real world.

And why have we been chosen to do this kind of testing?

We are in the EU document creation and editing business for more than a decade. The European Commission’s corporate style package for official and legislative documents has been developed by us. Similar systems from us run at the European Council and other EU and member-state institutions. Due to this in-depth knowledge accumulated by us in this multilingual European IT environment, we are in an ideal position to contribute to the OpenXML/ODT conversion project by identifying, emphasizing and testing the document features required for the day-to-day work with international documents in an increasingly interoperable world.