Re: [qa-test] Fichiers testtool de la 2.4
Bonsoir Sophie, Le 20/02/08, sophie <[EMAIL PROTECTED]> a écrit : > > Bonsoir, > > Pour ceux (celui ;) qui préfèrent faire les tests sur le TestTool de la > 2.4, l'archive des fichiers est ici : > ftp://ftp.ooodev.org/pub/qa/ Merci, je vais me régaler de suite ;-) Yves A bientôt > Sophie > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- web site : http://www.molenbaix.com
Re: [qa-test] Fichiers testtool de la 2.4
sophie a écrit : Bonsoir, Bonsoir, Pour ceux (celui ;) qui préfèrent faire les tests sur le TestTool de la 2.4, l'archive des fichiers est ici : Je me sens visé, merci Concrètement, ai-je bien compris qu'il faut attendre la rc2 parce que la rc1 est trop buguée ? ftp://ftp.ooodev.org/pub/qa/ Détail : pourquoi, quand je clique sur ce lien, ça ouvre IE alors que c'est FF le navigateur par défaut ? Henri
Re: [qa-test] Fichiers testtool de la 2.4
Le Jeudi 21 Février 2008 02:21, Henri Boyet a écrit : > sophie a écrit : > > Bonsoir, > > Bonsoir, > > > Pour ceux (celui ;) qui préfèrent faire les tests sur le TestTool de > > la 2.4, l'archive des fichiers est ici : > > Je me sens visé, merci;-) > Concrètement, ai-je bien compris qu'il faut attendre la rc2 parce que la > rc1 est trop buguée ? > > > ftp://ftp.ooodev.org/pub/qa/ > > Détail : pourquoi, quand je clique sur ce lien, ça ouvre IE alors que > c'est FF le navigateur par défaut ? Bonjour, Parce que c'est du ftp et non du http et que chez toi par défaut c'est IE qui prend le ftp ? Juste une idée, sans garantie. JBF -- Seuls des formats ouverts peuvent assurer la pérennité de vos documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qa-test] Fichiers testtool de la 2.4
Henri Boyet a écrit : sophie a écrit : Bonsoir, Bonsoir, Pour ceux (celui ;) qui préfèrent faire les tests sur le TestTool de la 2.4, l'archive des fichiers est ici : Pour info, il me semble que le fichier à télécharger est celui marqué "Head", car les autres contiennent des scripts qui donneront de faux positifs (problèmes de scripts qui fonctionnaient sous 2.3.x mais non sous 2.4.x). En outre, d'après ce que j'ai pu comprendre, la version HEAD est mise à jour tous les jours. Le souci pour moi est de savoir jusqu'à quand on va arrêter de nous demander de faire des tests avec des versions et des scripts qui ne sont pas prêts...Je veux bien faire des tests, je suis actuellement en train de compiler OOo Aqua, mais cela devient désespérant de devoir recommencer tous les quatre matins parce qu'on s'est aperçu que finalement la version que l'on était supposé tester comporte un gros bogue (en outre généralement facilement repérable et réparable). Ce problème de "release" m'inquiète vraiment, et ce n'est pas la première fois qu'on en parle. C'est d'autant plus vrai que certains devs chez Sun se sont étonnés de la libération de versions que l'on savait ne fonctionnaient pas avec tous les composants de la suite (notamment Base et le générateur de rapports). C'est pour moi encore une fois le "release plan" qui prend les devants sur la qualité du produit et AMHA ce n'est pas une bonne chose. Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qa-test] Fichiers testtool de la 2.4
Bonjour Alex, Alex Thurgood wrote: Henri Boyet a écrit : sophie a écrit : Bonsoir, Bonsoir, Pour ceux (celui ;) qui préfèrent faire les tests sur le TestTool de la 2.4, l'archive des fichiers est ici : Pour info, il me semble que le fichier à télécharger est celui marqué "Head", car les autres contiennent des scripts qui donneront de faux positifs (problèmes de scripts qui fonctionnaient sous 2.3.x mais non sous 2.4.x). En outre, d'après ce que j'ai pu comprendre, la version HEAD est mise à jour tous les jours. Head est maintenant utilisé pour la 3.0, si tu veux télécharger les scripts sur cvs, il faut utiliser : cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs co -r ooo240 -P qa/qatesttool L'archive que j'ai donnée est celle faite par André et est mise à jour quotidiennement. Le souci pour moi est de savoir jusqu'à quand on va arrêter de nous demander de faire des tests avec des versions et des scripts qui ne sont pas prêts...Je veux bien faire des tests, je suis actuellement en train de compiler OOo Aqua, mais cela devient désespérant de devoir recommencer tous les quatre matins parce qu'on s'est aperçu que finalement la version que l'on était supposé tester comporte un gros bogue (en outre généralement facilement repérable et réparable). Ce problème de "release" m'inquiète vraiment, et ce n'est pas la première fois qu'on en parle. C'est d'autant plus vrai que certains devs chez Sun se sont étonnés de la libération de versions que l'on savait ne fonctionnaient pas avec tous les composants de la suite (notamment Base et le générateur de rapports). C'est pour moi encore une fois le "release plan" qui prend les devants sur la qualité du produit et AMHA ce n'est pas une bonne chose. D'où la nécessité de mieux tester les versions en amont des rc et de remonter les bugs bloquant sur la liste release. Le bug dont tu parles (86031 je pense et moi ce qui m'énerve c'est le positionnement de générateur de rapport...) aurait effectivement dû laisser la m7 comme une version dev et non une RC1, c'est aussi pour cela que nous n'avons pas démarré les tests sur celle-ci. Itou pour les autres bugs. Pour ma part, j'essaye de faire que nous ayons un environnement de test correct pour les versions dev en multilingue et avec des jeux de tests complets et je suis preneuse de toutes les idées et aide pour y arriver avant la sortie de la 3.0. A bientôt Sophie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qa-test] Fichiers testtool de la 2.4
sophie a écrit : Bonjour Sophie, Head est maintenant utilisé pour la 3.0, si tu veux télécharger les scripts sur cvs, il faut utiliser : cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs co -r ooo240 -P qa/qatesttool L'archive que j'ai donnée est celle faite par André et est mise à jour quotidiennement. Autant pour moi, merci de m'avoir corrigé et désolé pour la désinformation de ma part. D'où la nécessité de mieux tester les versions en amont des rc et de remonter les bugs bloquant sur la liste release. Le bug dont tu parles (86031 je pense et moi ce qui m'énerve c'est le positionnement de générateur de rapport...) aurait effectivement dû laisser la m7 comme une version dev et non une RC1, c'est aussi pour cela que nous n'avons pas démarré les tests sur celle-ci. Itou pour les autres bugs. Pour ma part, j'essaye de faire que nous ayons un environnement de test correct pour les versions dev en multilingue et avec des jeux de tests complets et je suis preneuse de toutes les idées et aide pour y arriver avant la sortie de la 3.0. Je n'ai pas de solution évidente, si ce n'est que de faire des tests sur les milestones, mais je crains que l'on ne soit assez nombreux pour les organiser/effectuer. Pour ma part, rien que le fait de télécharger les sources CVS et compiler pour X11 et Aqua est semé d'embuches, encore moins les tester, cela a l'air de changer assez régulièrement de sorte que je suis obligé de m'y reprendre à plusieurs reprises pour obtenir un jeu de sources complet. J'ai carrément arrêté les tests pour FreeBSD, parce que les ports sont dans un tel état qu'il ne semble pas possible d'avoir une version si ce n'est que de test qui marche à peu près correctement, voire même se lance. Pour Mac, je vais pouvoir lancer des tests automatiques sur une machine à part (celle qui fait les builds justement) en prenant exemple sur le tutoriel de Maho, mais ces tests là ne vérifient pas le résultat visible à l'écran, ce qui fait des tests manuels restent indispensables. On revient toujours à se demander, quels sont les tests a minima qu'il faut accomplir opur valider une version et quel est le degré de défauts que l'on est prêt à accepter pour marquer cette validation ? Si je prends ne serait ce que l'exemple Mac, la version X11 est complètement inutile sur Leopard pour tout ce qui touche aux Bases de Données. Cela veut dire qu'un module complet ne fonctionne pas. Comment peut on alors valider une version pour cet OS ? On est déjà tellement peu nombreux à avoir des Mac Leopard, et je ne vais certainement pas y passer tant que des problèmes de compatibilité existent avec d'autres softs que j'ai provenant de développements spécifiques. Certes, OOo fonctionne (à peu près correctement au niveau BDD, et encore, tous les types de BDD disponibles sur les autres plateformes ne seraient pas disponibles) pour Tiger et Panther, mais aujourd'hui qqn qui achète un Mac neuf se trouve avec ce dilemme : ou bien je prends NeoOffice qui lui fonctionne complètement mais avec un certain retard de version, ou bien OOo qui ne fonctionne que si on ne veut pas utiliser les BDD ou bien encore Office2008 qui vient de sortir. Du coup, il me semble difficile de proposer qq chose de cohérente globalement au niveau des tests QA. :-( Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [qa-test] Fichiers testtool de la 2.4
Re Alex, Alex Thurgood wrote: sophie a écrit : Bonjour Sophie, Head est maintenant utilisé pour la 3.0, si tu veux télécharger les scripts sur cvs, il faut utiliser : cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs co -r ooo240 -P qa/qatesttool L'archive que j'ai donnée est celle faite par André et est mise à jour quotidiennement. Autant pour moi, merci de m'avoir corrigé et désolé pour la désinformation de ma part. C'est moi qui n'avait pas donné toute l'information, à deux, on va y arriver ;) D'où la nécessité de mieux tester les versions en amont des rc et de remonter les bugs bloquant sur la liste release. Le bug dont tu parles (86031 je pense et moi ce qui m'énerve c'est le positionnement de générateur de rapport...) aurait effectivement dû laisser la m7 comme une version dev et non une RC1, c'est aussi pour cela que nous n'avons pas démarré les tests sur celle-ci. Itou pour les autres bugs. Pour ma part, j'essaye de faire que nous ayons un environnement de test correct pour les versions dev en multilingue et avec des jeux de tests complets et je suis preneuse de toutes les idées et aide pour y arriver avant la sortie de la 3.0. Je n'ai pas de solution évidente, si ce n'est que de faire des tests sur les milestones, mais je crains que l'on ne soit assez nombreux pour les organiser/effectuer. C'est à ça que je voudrai travailler, avoir une interface de tests, si possible localisée (un peu à la TCM) pour les tests des milestones. Pour le moment, on est arrivé là : http://wiki.services.openoffice.org/wiki/Feature_Freeze_Testing_2.4 Les cas tests sont recencés etc... ce n'est pas encore l'idéal pour des utilisateurs finaux non anglophones, mais au moins toute l'info est centralisée pour pouvoir la retraiter (ce qu'il reste à faire). Pour ma part, rien que le fait de télécharger les sources CVS et compiler pour X11 et Aqua est semé d'embuches, encore moins les tester, cela a l'air de changer assez régulièrement de sorte que je suis obligé de m'y reprendre à plusieurs reprises pour obtenir un jeu de sources complet. J'ai carrément arrêté les tests pour FreeBSD, parce que les ports sont dans un tel état qu'il ne semble pas possible d'avoir une version si ce n'est que de test qui marche à peu près correctement, voire même se lance. Pour Mac, je vais pouvoir lancer des tests automatiques sur une machine à part (celle qui fait les builds justement) en prenant exemple sur le tutoriel de Maho, mais ces tests là ne vérifient pas le résultat visible à l'écran, ce qui fait des tests manuels restent indispensables. On revient toujours à se demander, quels sont les tests a minima qu'il faut accomplir opur valider une version et quel est le degré de défauts que l'on est prêt à accepter pour marquer cette validation ? oui, je suis d'accord. Si tu regardes la roadmap de la 2.4, il y a eu pourtant pas mal de temps entre le feature freeze (mi-novembre) et la rc prévue pour le 21 février. C'est pour cela qu'à mon sens il faut optimiser les tests et les rendre plus accessibles, y compris sur les cws. Si je prends ne serait ce que l'exemple Mac, la version X11 est complètement inutile sur Leopard pour tout ce qui touche aux Bases de Données. Cela veut dire qu'un module complet ne fonctionne pas. Comment peut on alors valider une version pour cet OS ? On est déjà tellement peu nombreux à avoir des Mac Leopard, et je ne vais certainement pas y passer tant que des problèmes de compatibilité existent avec d'autres softs que j'ai provenant de développements spécifiques. Certes, OOo fonctionne (à peu près correctement au niveau BDD, et encore, tous les types de BDD disponibles sur les autres plateformes ne seraient pas disponibles) pour Tiger et Panther, mais aujourd'hui qqn qui achète un Mac neuf se trouve avec ce dilemme : ou bien je prends NeoOffice qui lui fonctionne complètement mais avec un certain retard de version, ou bien OOo qui ne fonctionne que si on ne veut pas utiliser les BDD ou bien encore Office2008 qui vient de sortir. Je n'ai pas de réponse à ton questionnement plus haut et nous en avons déjà discuté. Il m'a toujours semblé que plus nous avions de testeurs et plus nous arriverions à stabiliser une version, l'exemple FreeBSD tend dans ce sens. Maintenant, c'est vrai que l'utilisateur n'est pas un testeur, même si Frank dit qu'il n'y a que les tests en mode réel qui permettent de corriger une version. La frontière est mince quant à la décision de validation d'une version... ni la roadmap, ni les utilisateurs, ni les développeurs ne sont indifférents dans cette décision (je me rappelle encore de la beta 2.0 FR que nous n'avions pas validé ;) Du coup, il me semble difficile de proposer qq chose de cohérente globalement au niveau des tests QA. :-( Merci en tout cas pour ta réflexion :) A bientôt Sophie - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional co
