But du projet

Le but principal est d'organiser les tests de la distribution Mandriva Linux. En effet, le développement de la distribution (cooker) est relativement structuré et bénéficie de toute l'infrastructure Mandriva mais il manque cruellement une infrastructure qui permettra à la distribution d'être testée sur une base raisonnable d'utilisateurs.

Principe

La structure du projet repose sur 5 groupes de personnes. Une personne peut faire partie de plusieurs de ces groupes. Ce sont les testeurs, les remonteurs, les modérateurs, les écrivains et les annonceurs. Les rôles et responsabilité de chacun de ces groupes est décrit en détail ci-après.

Le projet peut être décomposé en 3 sous-projets :

• Le test des versions beta
• Le test des contributions
• Le test des cas d'usage

Dans le premier et le deuxième cas, les testeurs reçoivent un mail lorsque quelquechose doit être testé dans Mandriva Linux et sont incités à donner leur retour d'expérience sur le forum (un lien sera fourni dans le mail). Lorsque l'on voudra tester une beta (premier cas), on prendra soin auparavant d'indiquer quelle version beta on souhaite tester. Cela évitera que tout le monde ne teste que la RC2, par exemple, étant donné qu'on ne teste généralement qu'une version béta.

Dans le troisième cas, les cas d'usage seront rédigés sur ce wiki (dans la page AccueilCasDusage) et les testeurs auront la possibilité de les tester.

Les tests des versions beta et RC de Mandriva Linux

Les tests occasionnels de fonctionalités / nouveautés / contributions

Les tests de cas d'usages

Ressources disponibles

Le projet dispose :

• D'un trac pour documenter les cas d'usage (AccueilCasDusage), décrire le fonctionnement du projet (wiki) et recenser les choses à faire pour l'organisation du projet (tickets)
• D'une liste de diffusion à sens unique : taster@… ( inscription). Un sous-groupe des inscrits à la liste de diffusion (les annonceurs) peut poster sur la liste, mais personne d'autre.
• D'une partie dédiée dans le forum mandriva ( http://forum.mandriva.com/viewforum.php?f=172).

Les testeurs

N'importe qui peut être testeur. Il n'y a pas besoin d'être membre de l'association. Pas de niveau en Linux requis. Il suffit de se servir du forum et scruter la liste de diffusion sur laquelle où l'on  s'inscrit via une page web. De manière proactive et en un minimum de temps, on peut réaliser des cas d'usage en allant sur le wiki à la page AccueilCasDusage.

Les remonteurs

Ce seront les principaux interlocuteurs des testeurs : leur but est de rechercher l'origine des problèmes rencontrés lors des tests, de déterminer s'il s'agit d'un bug et de donner un maximum d'informations aux développeurs pour pouvoir résoudre le bug, le cas échéant. Ils devront maitriser l'anglais un minimum, seul moyen de communication avec les développeurs. Idéalement, ils disposeront d'une version Cooker sous le coude histoire de vérifier si les bugs sont reproduisibles sur cooker (le cas échéant).

Les annonceurs

Ils seront les seuls à pouvoir envoyer un mail sur la  mailing list taster@… (personne ne peut leur répondre par mail). Les testeurs sont inscrits sur cette mailing list aussi. Les annonceurs devront s'informer constamment sur l'évolution de la distribution Mandriva Linux et lorsqu'un test est réalisable par les testeurs, ils effectueront deux opérations : créer un fil dans le forum, dédié à ce test et envoyer un message sur la  liste de diffusion pour appeler les testeurs à donner leurs impressions sur le forum (en donnant le lien vers les fil créé).

Les modérateurs

Ils travaillent principalement sur le forum et aident les testeurs à canaliser leurs idées. Ils seront aussi en mesure de supprimer ou déplacer les posts vers d'autres forum lorsque ces derniers ne respectent pas les règle du forum dédié "taster".

Les écrivains

Leur rôle est de rédiger des cas d'usage et de les exporter sur ce wiki. Voir la page AccueilCasDusage.

Inscriptions

Vous êtes motivés pour faire partie d'un des rôles ? Rendez-vous sur la page des InscriptionsTaster.

Quoi tester ?

Voir la liste des TestsPrécédents.

Facteur de succès

• Il faudra s'efforcer de garder un équilibre entre nombre de testeurs et nombre de remonteurs. Les autres groupes pouvant être plus limités en nombre de personnes. Les écrivains devront aussi être suffisament productifs pour avoir un nombre assez intéressant de cas d'usages.
• Il faudra aussi un minimum de réactivité des développeurs côté Mandriva. Appeler à un test, puis laisser les retours sans réponses pendant plusieurs mois serait assez préoccupant. Cela pourrait être un des rôles des modérateurs ou des remonteurs : faire du *bruit*...

Idées en vrac

• ofaurax : proposer des documents pour tester des choses précises. Ex: "Tester le son", avec toutes les choses à tester, dans l'ordre (ex: lire un mp3 avec mpg123, puis un jeu, puis une animation flash contenant du son, par exemple). Cela peut permettre aussi d'accélérer les tests dans certains domaines (ex: si un testeur a accès à 3 machines différentes, il peut réaliser les mêmes tests sur les 3 rapidement, sans rien oublier) et à certains testeurs de tester sans savoir au préalable ce qu'il faut tester. Cela améliorera aussi la cohérence des rapports.
• ofaurax : proposer des documents pour rapporter correctement des bugs dans certains domaines. Ex: "Rapporter un bug audio" donnera toutes les commandes pour obtenir la conf alsa, "Rapporter un bug driver 3D" permettra de savoir quelle version du driver est utilisée. Un testeur complètement étranger à un domaine (ex: la gestion de l'audio) pourra fournir toutes les informations dès le premier rapport, plutôt que de lui demander en plusieurs fois.
• deap : Proposer des soirées ou des journées "taster" avec un objectif précis (je pense au "bug day" de kde4 sur #kde-bugs) du genre : le 2 juin, on teste toutes les fonctionnalités de drakconnect et on rapporte/commente un maximum de bugs. Le tout se fait en messagerie instantanée sur jabber.
  • ofaurax: et lier ça au bugzilla, pour en profiter pour confirmer les bugs ouverts depuis longtemps mais qui n'ont pas été pris en compte et aussi pour fermer les vieux bugs.
• yoho : pour motiver les troupes, on pourrait diminuer la participation à l'association de ceux qui contribuent le plus.
  • deap : pourquoi pas, puis si le projet décolle, voir avec Mandriva si le "Taster de l'année" peut récupérer une Mandriva Flash à l'oeil :)
• yoho : comment impliquer les testeurs, en particulier, qu'ils s'engagent à réellement migrer leur machine lorsqu'une beta sort... distribution de "bon points" ou un truc dans le genre :) ?