En janvier 2003, Louis, notre community manager, a proposé que nous officialisions les tests d’assurance qualité que nous faisions sur nos versions localisées et surtout que nous les uniformisions. Le projet international était d’ailleurs encore jeune puisque seulement créé dans l’été 2002. Et c’était aussi très décourageant parce qu’à ce moment, les erreurs rencontrées dans nos versions prenaient des années à être corrigées, Ian qui en était en charge avait trop de travail... Nos versions localisées n’étaient d’ailleurs même pas dans le circuit de distribution officiel puisque c’était Armin Theissen qui nous les compilait sous Windows, jusqu’à la version 1.0. Ensuite nous n’avions des versions localisées que pour les RC, toutes les versions développeurs étaient en anglais et sans language pack, c’était vraiment tard pour arriver à tester les bugs ou régressions qui avaient pu se glisser pendant la période de développement. A l’heure actuelle et depuis la beta de la 2.0 (qui s’est distinguée par des tas de chaînes en anglais dans l’interface ce qui lui avait value d’être recalée par mes soins), nous disposons de toutes les versions localisées, y compris les developer snapshots et pour toutes les plateformes.
La première version où nous avons tout coordonné entre notre projet et le projet QA international était la version 1.0.2. J’ai traduit tous les smoke tests de façon à ce que nos testeurs puissent faire tous ces tests en français. Ils sont encore sur le cvs, dans la section qa du site francophone ! Et bien sûr la liste de travail a été créée sur le projet francophone dès février 2003.
André Schnabel,alors lead du projet germanophone, a fait une matrice Calc pour que nous puissions suivre les résultats des testeurs. À ce moment, le Testtool utilisé par Hamburg n’était pas libre, nous n’y avions donc pas accès. Mais les tests manuels étaient déjà bien fournis et grâce à l’aide de Joost, j’ai appris à tester la localisation d’une version. Quant au TCM, il était encore dans les limbes de son développement. Donc il s’agissait d’étaler toutes ces feuilles autour de soit et de contrôler tous les dysfonctionnement pour isoler les bugs et les reporter sur IZ. Manuels jusqu’au bout, ces tests ! Si vous voulez avoir une idée du travail, prenez par exemple l’issue 26909, elle n’a pas encore beaucoup de contributeurs et reste digeste ;-)
Je ne sais plus bien quand le TCM a été mis en place dans sa première version. Il y a eu un pilote en 2004. Il n’était pas prévu que les tests soient traduits et cela a été l’objet de mes premières demandes lors du meeting de mise en place sur irc #ooopilot, les 144 tests étaient traduits hors ligne, mais pas possible de les mettre en ligne... Cela n’a pas duré, en fait et Karl Park a fait les aménagements nécessaires à l’outil suite au meeting. Nous avons maintenant une seconde version du TCM, beaucoup plus facile à maintenir et surtout documentée, la première ne l’était pas et je suis allée cliquer un peu partout pour comprendre comment cela fonctionnait. Si mes souvenirs sont bons, la première version n’était pas open source et ça a été l’objet de la seconde.
Ce que ce TCM a apporté en dehors d’un confort pour le testeur qui bénéficie d’une interface de saisie de résultats de ses tests, c’est la possibilité d’analyse des résultats à travers des requêtes. Plus loin encore, c’est aussi la possibilité d’avoir un suivi des bugs à travers les versions et donc de vérifier d’éventuelles régression, et ce dans toutes les langues pour les équipes qui utilisent cet outil. Actuellement, il serait à améliorer, nous avons besoin de plus de tests et de plus de statistiques sur ces tests.
Nous sommes de plus en plus nombreux a effectuer les tests sur cet outil, les projets francophone, germanophone et italophone ont fait des émules :-) Le pas important que nous avons franchi finalement, c’est que nous sommes devenus responsables de la mise à disposition de nos versions et que cela a vraiment marqué une étape de maturité pour notre projet. Et qui d’autre que nous pourrait juger de la qualité du produit que nous offrons à nos utilisateurs ?
Bien souvent les utilisateurs pensent que la version anglaise est d’abord réalisée, puis que viennent ensuite les traductions. Mais là aussi notre projet se démarque, nous pensons d’abord internationalisation et tout le process de développement est maintenant fait pour que les versions localisées arrivent en même temps que la version anglaise. Même si toutes ne vont pas au même rythme parce que cela demande beaucoup de ressources que d’arriver à faire les tests d’assurance qualité dans des délais assez courts, nous essayons au moins que les versions anglaise, allemande, italienne, japonaise et française sortent en même temps pour que nous puissions bénéficier d’un effet d’annonce international.
Je parle de ressources, mais ce sont bien des bénévoles qui sont derrière ce mot. Si nous avons pu délivrer version après version depuis 2003, c’est parce qu’à chaque fois nous avions une équipe qui pouvait valider par ses tests les plateformes mises à disposition. Il faut au minimum deux testeurs par plateforme pour la valider. Parfois nous en avons plus, parfois pas du tout ou un seul (c’est ce qui s’est passé pour la version 2.4 Mac Intel et PPc).
Si notre équipe est bien construite maintenant, je peux dire que cela à été à chaque fois un pincement au coeur au début lorsque je faisais un appel à volontaires, mais il y a toujours eu du monde à répondre et bien qu’avant le Testtool, nous faisions beaucoup plus de tests manuels. Et c’était répétitif et rasoir de tout recommencer à chaque nouvelle RC, parfois jusqu’à huit fois de suite, nous recommencions ces tests.
Le Testtool a été présenté rapidement la première fois à la OooCon de Hamburg je crois, j’ai été impressionnée par toutes ces fenêtres et ces menus qui s’ouvraient tout seul ! Les premières utilisations étaient vraiment compliquées, il fallait déjà comprendre comment marchait l’outil dans OOo, ensuite, il fallait télécharger les jeux de tests sur cvs, la plupart du temps, c’était les tests qui se plantaient et non la plateforme... bref, un poème ! Quant à l’analyse des résultats, une horreur, des centaines de fichiers .res à évaluer. Ouf, Bob a vite fait un script permettant une première analyse. J’avoue que quand Sun a dit qu’il s’occupait des tests automatiques pour nos versions, je ne me suis pas battue pour les garder, l’essentiel étant que nous restions maîtres de la sortie de nos versions.
Depuis un an maintenant, le Testtool fonctionne bien, mais pratiquement plus personne dans le projet francophone ne fait ces tests. Pourtant, à nouveau, Sun nous demande de participer parce qu’ils ne peuvent tester toutes les plateformes et une matrice assez intéressante a été mise en place pour traquer et analyser les résultats de ces tests. J’essaierai dès que j’aurai un second ordinateur. Cet outil s’appelle QAste, pour l’instant il n’y a que le projet allemand qui ait embrayé pour les rc de la 3.0. L’intérêt c’est de pouvoir également tester des cws et donc activer le QA et donc activer les corrections et leur intégration.
Maintenant, il faut encore arriver à faire que les TCS soit rendus localisables (ce qui n’est pas très difficile, il suffit de se mettre à les traduire ;-) et que nous ayons une plateforme pour les réaliser. Ces tests sont dédiés aux versions de développement et nous aident bien souvent à comprendre comment fonctionne les nouvelles fonctionnalités lorsque nous devons faire la localisation avant leur intégration (cela a été le cas du solveur notamment ou encore l’extension mediawiki) ou simplement vérifier que leur internationalisation est correcte. Là encore, il y a beaucoup de tests à traduire et à illustrer, mais petit à petit... J’ai bon espoir qu’à la prochaine conférence nous arriverons à une solution et un outil.
(Vous souhaitez reproduire cet article ?)
