Bonjour Pierre-Yves, pierre-yves.samyn wrote: > Bonjour [...] > > Quelques réflexions sur les tests et sur OOo en général. > > On pourrait presque être surpris que les tests TCM découvrent des bugs. > On pourrait en effet se dire que les développeurs "passent" eux-mêmes > ces tests avant la mise en test...
Les développeurs ne font pas les tests, ce sont les membres du QA qui les réalisent et qui les écrivent, au moins pour les tests manuels. le workflow est ici http://wiki.services.openoffice.org/wiki/CWS_Workflow_for_QA-Representative http://wiki.services.openoffice.org/wiki/CWS_Checklist_for_QA_responsibilities > > Une manière de dire que ces tests ont leur utilité :) Chaque correctif est donc testé avant et après intégration. Par exemple, pour Writer, tu peux actuellement vérifier que la plupart de ces correctifs sont correctement implémentés et si ce sont de nouvelles fonctionnalités, elles doivent également reproduire la spécification. http://tinyurl.com/o8jkdk > > J'ai jusqu'ici privilégié le test en "usage courant", i.e. en téléchargeant > les versions et en les utilisant (usage privé et parfois professionnel). C'est un très bon complément des TCS, beaucoup de dysfonctionnements ne peuvent être trouvés qu'ainsi. > > Mes autres activités m'ont hélas (enfin, pas vraiment hélas car sinon > j'aurais fait d'autres choix) contraint à faire l'impasse pour les tests > récents. > > Je suis persuadé que ce type de test est le meilleur moyen de > détecter les bugs principaux découverts avec la 3.1. oui, avec les tests en amont sur les versions de développement. Les TCM sont vraiment une toute petite partie de l'iceberg du QA > > Tout le monde s'accorde sur la briéveté des délais compte tenu > de l'ampleur de la tâche : toutes les fonctionnalités (anciennes & nouvelles), > de tous les modules, leur traduction (menus, menus contextuels, aide), > pour toutes les plates-formes et architectures. Les TCM sont plus dédiés à la localisation étant donné que nous n'avons en général qu'une version de test de celle-ci avant la RC, la vérification 'en réelle' se fait au moment des RC. Pour la 3.2, le process a changé. Les dates de 'features freeze', de 'code freeze' et 'last cws integration' sont les mêmes et donc cela laissera une période plus longue pour l'intégration et pour les tests. Le process de localization doit changer également, avec une intégration plus en continue et des versions de tests plus fréquentes, mais je pense que ce ne sera pas pour la 3.2. > > Rien que ça... :) > > En terme de développement, qu'est-ce qui est vraiment important > (je n'ai pas un avis sur tout ce qui suit) ? > > - respecter un calendrier ou être "raisonnablement" sûr de la version sortie > > - ajouter des fonctionnalités ou corriger les bugs (il en reste des avérés > non programmés). > > - travailler sur les fonctionnalités ou sur la compatibilité MS (déjà mal > respectée par cet éditeur pour ses produits). Il y a eu une discussion la semaine dernière à propos de cela, le sujet est : stopper modus for OOo-Dev codeline. Cela n'a rien à voir avec la présente discussion mais avec la façon de traiter les bugs sur IZ, mais cela rejoint néanmoins ton propos. http://www.openoffice.org/servlets/ReadMsg?list=releases&msgNo=13840 Bonne journée Sophie --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
