Quelles sont les procédures d'assurance qualité chez Linden Lab
Quelles sont les procédures d’assurance qualité de Linden Lab ?
Vous vous êtes sans doute demandé comment étaient traités les bugs de Second Life en arrière-plan. En réponse à cette vaste question posée par Ricky Lucero, Kelly Linden vous fait partager nos procédures d'assurance qualité (EN) :
Nous avons bien un Service d’Assurance Qualité (SAQ). Il fonctionne à peu près ainsi :
- Le chef de projet crée une subdivision ou branche à partir du tronc pour un nouveau projet.
- Les développeurs travaillant sur ce projet testent leur code dans cette subdivision.
- Les développeurs rédigent des modèles de tests pour le code qu’ils ont écrit.
- Quand le projet est « terminé », les modèles de tests et la subdivision sont envoyés au SAQ.
- Le SAQ procède aux tests :
- en exécutant les modèles de tests ;
- en évaluant les modèles de tests ;
- en exécutant des « smoke tests » ou tests de vérification ;
- en renvoyant les bugs identifiés au chef de projet.
- Les développeurs corrigent les bugs, renvoient au SAQ, nettoient le code et recommencent.
- La subdivision est intégrée au tronc.
- Le tronc est envoyé au SAQ et les bugs identifiés sont renvoyés aux développeurs (beaucoup de projets en sont à ce point).
- Les développeurs corrigent les bugs, renvoient au SAQ, nettoient le code et recommencent.
- Une version « bêta » devient disponible (soit sur la grille de test soit sur la grille complète).
- Les résidents et le SAQ envoient les bogues aux développeurs qui corrigent le code et recommencent.
- La nouvelle version devient disponible pour la grille réelle.
Cette procédure est quelque peu simplifiée et idéalisée. Parfois, un bug doit être corrigé en urgence et certaines étapes ci-dessus sont court-circuitées (la version « bêta publique » par exemple). Il peut y avoir plus d’assemblages et d’arborescences de codes en fonction de l’importance du projet et de ce qui se passe au niveau du tronc.
En résumé, nous avons un système particulièrement complexe devant intégrer beaucoup de types de matériels et de nombreux logiciels qui doivent fonctionner tous ensemble. Ces systèmes sont également utilisés de beaucoup de manières différentes et par de nombreuses personnes. Parfois, nous réalisons que les choses sont faites d’une certaine façon dans Second Life uniquement lorsqu'il y a un bug.
Faisons-nous un bon travail pour éviter les bugs ? Non, pas complètement. Mais nous avons, cependant, un SAQ et le processus ci-dessus est constamment revu et corrigé. Je pense que nous faisons un meilleur travail aujourd’hui que dans le passé. Nous dédions une grande part du temps de développement aux projets futurs, y compris à la correction des bugs, qui inclut les tests concernant les questions d’échelles et autres, et le remplacement des systèmes de base qui ont été conçus avec ce qui apparaît être des hypothèses erronées. Ceux-ci sont souvent invisibles aux utilisateurs sauf en cas de « plantage » ou si nous ne le corrigeons pas assez tôt.
En tant que développeur, je teste mon propre travail avant de l’envoyer au SAQ. Écrire du code, le compiler, et l’envoyer n’a pas de sens. Je vérifie d’abord que le code fait ce que j’en attends avant de l’envoyer au SAQ. Nous avons une équipe de développement plus importante que l’équipe d’assurance qualité et faire différemment, je pense, n’a pas de sens.
Lorsqu’on lui a demandé de donner des précisions sur la gestion des bogues et la question des priorités de leur traitement, Kelly a ajouté :
Comme je l’ai dit, il s'agit d'une vision simplifiée. Les rapports de bugs venant des résidents ne vont pas directement aux développeurs. Ils sont d’abord lus et analysés par le SAQ mais les bugs sont corrigés par les développeurs.
Il existe différentes définitions de bugs et différents niveaux de priorité, plus les modifications en arrière-plans, qui sont souvent plus importantes que ne laisse penser leur nature cachée. Il y a un grand nombre de questions qui sont en permanence priorisées, et avec une équipe de développement en nombre limité, nous essayons de répondre à toutes les questions dès que nous le pouvons. C'est pourquoi nous vous prions de ne pas demander « qu’en est-il de mon bug X ? », mais de soumettre vos descriptions de bugs lorsque vous les trouvez.
Parallèlement, nous avons une page sur les problèmes connus (EN).