Journal Firebird 2.0 cherche des testeurs

Bonjour à tous,

Le Projet Firebird va bientôt rendre publique la première version "alpha" de Firebird 2.0. Cette version 2.0 est une version majeure attendue depuis longtemps et comporte de nouvelles fonctionnalités, des améliorations et des corrections de bug (voir les notes de version http://firebird.sourceforge.net/download/prerelease/rnotes0200_01.z(...) pour plus de détails, ce document est en anglais mais une version française sera bientôt disponible). Au vu du nombre de changements, le passage à cette version est au moins aussi important, sinon plus que celui que nous avons connu avec le passage de la version 1.0 vers la version 1.5.

Vous savez que nous nous préoccupons de la qualité, et que nous ne livrerons pas de version finale de la 2.0 avant d’avoir satisfait aux tests de qualité. Pour la version 1.5, il nous a fallu presque un an pour être satisfait. Mais aujourd’hui la situation est un peu différente.

Le projet Vulcan a atteint un niveau de stabilité satisfaisant, avec seulement quelques correctifs à venir, et nous voulons fusionner les deux codes source le plus tôt possible. De cette fusion naitra Firebird 3.0 qui aura un support complet de SMP, une architecture unifiée (plus de compilation séparée pour classic/superserver/embedded) et d’autres améliorations (voir http://www.ibphoenix.com/downloads/VulcanOverview.pdf(...) pour plus de détails). Outre les avantages procurés aux utilisateurs de Firebird, cette fusion permettra d’avoir une architecture et un code plus clair et plus concis, et terminera notre transition depuis l’ancien code C procédural vers un code objet C++. Cela permettra aux developpeurs de créer et mettre en place des fonctionnalités complexe comme les espaces de noms, les tables temporaires et d’autres fonctionnalités actuellement réclamées.

Mais nous ne pouvons nous concentrer complètement sur la fusion Firebird/Vulcan avant que la version finale de Firebird 2.0 soit livrée, donc nous devons raccourcir autant que possible la phase de test de qualité, mais sans compromettre nos exigeances de qualité pour une version finale. Nous *pouvons* le faire en rendant notre processus de test plus efficace. Cette efficacité depend pour une large part des retours des utilisateurs, il est donc naturel de nous tourner vers vous aujourd’hui.

Jusqu’à présent, les retours des utilisateurs sont aléatoires et dépendent entièrement des utilisateurs eux mêmes. Classiquement, nous livrons des binaires, attendons les retours un certain temps et nous corrigeons les problèmes relevés (en même temps que les autres problèmes que nous trouvons en interne pendant cette période). Si aucun problème important n’est rapporté ou trouvé depuis la dernière version "Release Candidate", cette version est relivrée en tant que version finale. Bien sûr, il y a aussi les étapes alpha et beta qui suivent ce processus, mais diffèrent en ce que les développeurs ont le droit de changer dans le code.

Même si ce processus a fonctionné parfaitement dans le passé, il pose un problème important : nous ne savons pas comment sont fait les tests chez les utilisateurs tant en termes de fonctionnalités testées qu’en nombre de tests différents effectués. Nous ne pouvons qu’évaluer approximativement à partir du nombre de téléchargements effectués, des retours directs, du oui dire, de l’étape de developpement, etc la qualité et la quantité des tests effectués. Nous avons ainsi qu’une seule échelle de mesure : le temps, d’où la longueur du cycle de livraison finale.

Pour améliorer cela, nous voulons organiser un programme de tests, en commençant par Firebird 2.0. Ce programme de test *ne remplacera pas* l’habituel scénario de tests (ni les tests internes), mais fonctionnera en complément des autres procédures de test de qualité. L’objectif de ce programme est de collecter des informations précises sur ce qui aura été testé (par exemple comment les binaires auront été testés et avec quels résultats), ainsi nous pourrons mieux évaluer les résultats du processus d’assurance qualité, allouer plus précisément les ressources et ainsi avoir plus rapidement des certitudes sur la qualité du code.

La participation à ce programme de tests est très simple. Si vous maitrisez l’anglais, vous devez vous inscrire par email auprès de pcisar_ AT_ ibphoenix.cz, si vous voulez faire les tests et dialoguer en français vous devez vous inscrire auprès de Philippe Makowski qui coordonera le travail en français à l’email suivant firebird20_AT_firebird-fr.eu.org, en décrivant comment vous souhaitez tester nos productions. Nous préférons des méthodes de tests aussi proches que possible de la réalité. Cela veut dire que si vous avez une application qui fonctionne avec Firebird, vous pouvez simplement la mettre en test avec la nouvelle version de Firebird dans un environnement de test, de préférence avec des données réelles. Bien sûr, vous pouvez utiliser la méthode de test que vous voulez, et vous pouvez même vous concentrer sur un sujet précis pour lequel vous avez un intéret particulier (par exemple la performance, les sauvegardes / restaurations, les nouvelles fonctionnalités, l’optimiseur etc.). Vous pouvez aussi décrire quelle version de Firebird (CS/SS/Embedded) et la ou les plateformes que vous voulez tester. Nous vous enverrons une information dès qu’une nouvelle version à tester est disponible, et nous attendrons de vous en retour les résultats de vos tests, qu’ils soient positifs ou négatifs.

Nous savons qu’un tel engagement n’est pas toujours facile à remplir, il est donc possible que vous ne testiez pas toutes les sous versions ou que vous abandionnez le travail en cours, donc nous récompenserons ceux qui nous aiderons ! Nous avons créé un lot de prix qui comprend à l’heure actuelle un polo Firebird fournit par IBPhoenix dans la couleur et la taille de votre choix, mais nous pensons avoir d’autres lots avant la livraison finale de Firebird 2.0. A la fin du cycle, nous recompenserons le(s) testeur(s) le(s) plus actif(s) et un testeur au hasard.

Ce programme de test est ouvert à tous, à n’importe quel moment du cycle (de la version alpha 1 jusqu’à la dernière RC), mais ceux qui s’inscrivent le plus tôt ont le plus de chance d’être récompensés pour leur aide.

Pavel Cisar Firebird Project QA Division