Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-16 Par sujet reseau voillaume

Jean-Baptiste Faure a écrit :

Bonjour,

Hier j'ai mis en release blocker (stopper) 2 bugs pour la 3.1 :

http://www.openoffice.org/issues/show_bug.cgi?id=101869 (13 mai 2009) : le 
problème signalé hier matin par Marie-Jo, (La coupure de lignes complètes quand 
une cellule contient une référence à une cellule de la même colonne, bloque OOo 
sur XP et MacOS).

http://www.openoffice.org/issues/show_bug.cgi?id=101690 (8 mai 2009) : le tri 
de lignes contenant des formules mélange les références ; le bazar que ça met 
dans une feuille de calcul ne saute pas forcément aux yeux ce qui en fait un 
bug vicieux. La correction était ciblée 3.2 mais nous avons étaient plusieurs à 
souligner la nécessité de corriger ça dés la 3.1.1.

Les deux sont déjà corrigés mais il faudra attendre la 3.1.1 pour en profiter.

Je m'interroge sur l'efficacité de nos tests qui nous ont permis de laisser 
passer ce genre de chose et sans doute d'autres aussi gênantes. Pour ma part je 
pense que j'aurais pu voir le bug sur le tri si j'avais utilisé la RC2 sur ma 
machine professionnelle au lieu de l'expérimenter seulement hier. Pour le 
moment je n'ai pas de meilleure proposition que d'intensifier les tests et, à 
l'occasion de la refonte des fichiers d'exemple pour les tests TCM, d'essayer 
d'y inclure  des vérifications plus larges.

Je me demande aussi, et j'aimerais avoir votre avis là-dessus, s'il ne serait 
pas utile de publier une page d'information sur les bugs et problèmes connus 
importants de la version stable courante. Cela permettrait d'améliorer 
l'information des utilisateurs. Il ne s'agirait pas bien sûr de faire une liste 
exhaustive ni très longue afin d'éviter de noyer le lecteur sous l'abondance 
d'information. Au contraire il s'agirait de n'afficher que les bugs et 
problèmes qui nous paraissent susceptibles d'avoir un impact réellement négatif.
Cette page servirait aussi de fait de programme de tests complémentaires lors 
des tests QA de la version suivante.

Qu'en pensez-vous ?

Bonne journée
JBF

  
Le rythme des versions me parait important : versions par an dont deux 
majeures..


ne serait il pas possible de descendre à deux ? la version actuelle 
garderai son status de RC, serai proposée au téléchargement et seule la 
3.1.1 serait considérée comme stable et de qualité


ainsi un public plus large ferai remonter les bugs en utilisation 
courante, pour ma part, j'utilise toutes les versions, mais je ne 
déploie plus qu'une version sur deux : les x.x.n>1


par exemple il semble encore y avoir des problèmes avec dmath, les 
utilisateurs de dmath ont régulièrement souffert des évolutions dooo



pierre

-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org

Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-15 Par sujet Jean-Baptiste Faure
Bonjour,

Le 16.05.2009 01:17, Henri Boyet a écrit :
> Bonjour,
>> ...
>>> Quelle est la prochaine version à tester ? J'ai trouvé une DEV300_m47,
>>> mais je ne sais pas de quoi il s'agit ! Est-elle dangereuse ? C'est
>>> quand même paradoxal : pour trouver des bugs, il faut passer du temps
>>> avec des "vrais" fichiers mais pour être prudent il ne faut pas
>>> utiliser des fichiers importants !
>>> 
>> La version de développement Dev300_m48 est en train de se propager sur
>> les miroirs. Comme indiqué dans le bulletin d'annonce cette version
>> préfigure la 3.2 qui doit être publiée en fin d'année.
>> Il n'y a pas encore de version de développement pour la 3.1.1.
>>   
> Comme il est souvent difficile de faire cohabiter plusieurs versions,
> qu'est-ce qui est le mieux ? Tester la future 3.2 ou attendre pour
> tester la future 3.1.1 ?
Je ne sais pas encore comment vont se faire les tests informels de la
3.1.1. C'est à dire que je ne sais pas si nous allons avoir une version
"OOo-Dev" pour la branche 3.1.1 et une autre pour la branche 3.2 auquel
cas il sera difficile de les tester ensemble sur la même machine (2
applis de même nom ça ne marche pas).
En attendant d'en savoir plus je vais pour ma part installer la
OOO300_m48 pour commencer à tester la future 3.2 quitte à l'enlever dans
quelques temps pour passer à la 3.1.1.
>> Pour moi il n'y a pas de paradoxe : il faut utiliser des vrais fichiers
>> importants mais pour ne pas travailler en production et prendre les
>> précautions d'usage, il suffit de ne pas utiliser leur version originale
>> mais seulement des copies.
>>   
> Ce que je voulais dire, c'est qu'on n'a pas forcément assez de temps
> pour utiliser les "vrais" fichiers  d'une part pour son travail et
> d'autre part  pour tester les nouvelles versions. Bien sûr, j'ai des
> copies (et même en triple : après deux crashes de disques durs, on
> devient parano !) et donc pas de problème si le fichier est perdu en
> cours de travail. C'est pourquoi, je travaille dès que possible avec
> les versions tests et jusqu'à présent, je n'ai jamais eu à le
> regretter. Là où ça me fait peur, c'est de prendre conscience qu'un
> fichier peut être altéré de façon invisible : au bout d'un certain
> temps, toutes les copies de sauvegarde sont remplacées par le fichier
> corrompu ! Même si le risque est très faible et sans conséquence
> dramatique pour moi, ça peut être plus grave pour d'autres et donc
> freiner les tests sur le vrai matériau.
Tu as raison. Ce fichu bug 101690 montre qu'il faut isoler les tests
faits sur de vrais fichiers, c'est à dire ne pas réinjecter les fichiers
ainsi modifiés dans le circuit normal de production sans être bien
certain de leur intégrité. Mais pour cela il faut avoir le temps et les
moyens de faire les choses en double, avec la version stable et avec la
version de développement.
Mais comme les versions stables peuvent avoir des défauts inconnus il
est aussi utile de prévoir dans la conception même de ces documents
(surtout tableurs), dans la mesure du possible, des moyens de contrôle
de cohérence. C'est en cherchant à vérifier l'efficacité d'un tel moyen
sur mon propre fichier que j'ai trouvé le contournement que j'ai exposé
hier et qui fonctionne apparemment bien dans le cas qui m'intéresse.
Je pense que cette notion de contrôle de cohérence d'un tableur est
utile de façon générale, même indépendamment de la prévention des bugs
de OOo.

Bonne journée
JBF

-- 
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.



-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org



Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-15 Par sujet Henri Boyet

Bonjour,

...

Quelle est la prochaine version à tester ? J'ai trouvé une DEV300_m47,
mais je ne sais pas de quoi il s'agit ! Est-elle dangereuse ? C'est
quand même paradoxal : pour trouver des bugs, il faut passer du temps
avec des "vrais" fichiers mais pour être prudent il ne faut pas
utiliser des fichiers importants !


La version de développement Dev300_m48 est en train de se propager sur
les miroirs. Comme indiqué dans le bulletin d'annonce cette version
préfigure la 3.2 qui doit être publiée en fin d'année.
Il n'y a pas encore de version de développement pour la 3.1.1.
  
Comme il est souvent difficile de faire cohabiter plusieurs versions, 
qu'est-ce qui est le mieux ? Tester la future 3.2 ou attendre pour 
tester la future 3.1.1 ?

Pour moi il n'y a pas de paradoxe : il faut utiliser des vrais fichiers
importants mais pour ne pas travailler en production et prendre les
précautions d'usage, il suffit de ne pas utiliser leur version originale
mais seulement des copies.
  
Ce que je voulais dire, c'est qu'on n'a pas forcément assez de temps 
pour utiliser les "vrais" fichiers  d'une part pour son travail et 
d'autre part  pour tester les nouvelles versions. Bien sûr, j'ai des 
copies (et même en triple : après deux crashes de disques durs, on 
devient parano !) et donc pas de problème si le fichier est perdu en 
cours de travail. C'est pourquoi, je travaille dès que possible avec les 
versions tests et jusqu'à présent, je n'ai jamais eu à le regretter. Là 
où ça me fait peur, c'est de prendre conscience qu'un fichier peut être 
altéré de façon invisible : au bout d'un certain temps, toutes les 
copies de sauvegarde sont remplacées par le fichier corrompu ! Même si 
le risque est très faible et sans conséquence dramatique pour moi, ça 
peut être plus grave pour d'autres et donc freiner les tests sur le vrai 
matériau.

Bonne journée
JBF
  

Bonne fin de semaine,

Henri




Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-14 Par sujet Jean-Baptiste Faure
Le 15.05.2009 00:30, Henri Boyet a écrit :
>
> Bonsoir,
>
> Comme d'autres avant moi, je dirai :
> - que nous avons manqué de temps pour tester "dans la vraie vie",
> - que les tests que nous faisons pour la localisation ne sont pas
> suffisants,
> - que le respect d'une date de sortie est moins important que la
> qualité et la sécurité,
> - que je supprime des lignes dans le tableur, je ne les coupe pas.
>
> Qu'un bug fasse planter le programme me gêne mais ne me choque pas
> trop. Qu'un autre fausse des résultats sans qu'on s'en rende compte me
> paraît intolérable : imaginez qu'une entreprise perde des sommes
> énormes ou produise des pièces dangereuses à cause d'un tel bug, qui
> serait responsable ? Même si juridiquement il n'y a pas de suite,
> quelle contre-publicité !
Comme toujours : l'utilisateur est responsable de ce qu'il produit avec
le logiciel.
Mais c'est vrai, si légalement l'éditeur du logiciel n'est pas
responsable, ça ne fait lui pas une bonne publicité.
> Le moins qu'on puisse faire est effectivement de publier une alerte
> pour que les utilisateurs se méfient. Je ne comprends pas qu'on
> attende plusieurs mois pour publier une version correcte. Ne serait-il
> pas possible de tester cette version corrigée, pour vérifier que la
> correction n'a pas entraîné d'autres catastrophes et la publier dès
> que possible ? Ma version de Firefox se met à jour très souvent (en
> tout cas plus souvent que OOo), pour des corrections de sécurité.
L'architecture de OOo ne permet pas encore les mises à jour partielles.
Tous les modules sont très interdépendants et faire un nouvel exécutable
suppose de refaire l'intégralité des tests de validation.
On "n'attend" pas pour publier une version corrigée, on prend le temps
de tester et manifestement pour la 3.1 ce temps a été trop court.
>
> Quelle est la prochaine version à tester ? J'ai trouvé une DEV300_m47,
> mais je ne sais pas de quoi il s'agit ! Est-elle dangereuse ? C'est
> quand même paradoxal : pour trouver des bugs, il faut passer du temps
> avec des "vrais" fichiers mais pour être prudent il ne faut pas
> utiliser des fichiers importants !
La version de développement Dev300_m48 est en train de se propager sur
les miroirs. Comme indiqué dans le bulletin d'annonce cette version
préfigure la 3.2 qui doit être publiée en fin d'année.
Il n'y a pas encore de version de développement pour la 3.1.1.
Pour moi il n'y a pas de paradoxe : il faut utiliser des vrais fichiers
importants mais pour ne pas travailler en production et prendre les
précautions d'usage, il suffit de ne pas utiliser leur version originale
mais seulement des copies.

Bonne journée
JBF

-- 
Seuls des formats ouverts peuvent assurer la pérennité de vos documents.



-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org



Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-14 Par sujet Henri Boyet

Bonsoir,

Comme d'autres avant moi, je dirai :
- que nous avons manqué de temps pour tester "dans la vraie vie",
- que les tests que nous faisons pour la localisation ne sont pas 
suffisants,
- que le respect d'une date de sortie est moins important que la qualité 
et la sécurité,

- que je supprime des lignes dans le tableur, je ne les coupe pas.

Qu'un bug fasse planter le programme me gêne mais ne me choque pas trop. 
Qu'un autre fausse des résultats sans qu'on s'en rende compte me paraît 
intolérable : imaginez qu'une entreprise perde des sommes énormes ou 
produise des pièces dangereuses à cause d'un tel bug, qui serait 
responsable ? Même si juridiquement il n'y a pas de suite, quelle 
contre-publicité !
Le moins qu'on puisse faire est effectivement de publier une alerte pour 
que les utilisateurs se méfient. Je ne comprends pas qu'on attende 
plusieurs mois pour publier une version correcte. Ne serait-il pas 
possible de tester cette version corrigée, pour vérifier que la 
correction n'a pas entraîné d'autres catastrophes et la publier dès que 
possible ? Ma version de Firefox se met à jour très souvent (en tout cas 
plus souvent que OOo), pour des corrections de sécurité.


Quelle est la prochaine version à tester ? J'ai trouvé une DEV300_m47, 
mais je ne sais pas de quoi il s'agit ! Est-elle dangereuse ? C'est 
quand même paradoxal : pour trouver des bugs, il faut passer du temps 
avec des "vrais" fichiers mais pour être prudent il ne faut pas utiliser 
des fichiers importants !


Bon courage à tous quand même,

Henri



-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org



Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-14 Par sujet gibi

Jean-Baptiste Faure a écrit :

Bonjour,


Bonsoir,


Hier j'ai mis en release blocker (stopper) 2 bugs pour la 3.1 :

http://www.openoffice.org/issues/show_bug.cgi?id=101869 (13 mai 2009) : le 
problème signalé hier matin par Marie-Jo, (La coupure de lignes complètes quand 
une cellule contient une référence à une cellule de la même colonne, bloque OOo 
sur XP et MacOS).

http://www.openoffice.org/issues/show_bug.cgi?id=101690 (8 mai 2009) : le tri 
de lignes contenant des formules mélange les références ; le bazar que ça met 
dans une feuille de calcul ne saute pas forcément aux yeux ce qui en fait un 
bug vicieux. La correction était ciblée 3.2 mais nous avons étaient plusieurs à 
souligner la nécessité de corriger ça dés la 3.1.1.

Les deux sont déjà corrigés mais il faudra attendre la 3.1.1 pour en profiter.

Je m'interroge sur l'efficacité de nos tests qui nous ont permis de laisser 
passer ce genre de chose et sans doute d'autres aussi gênantes. Pour ma part je 
pense que j'aurais pu voir le bug sur le tri si j'avais utilisé la RC2 sur ma 
machine professionnelle au lieu de l'expérimenter seulement hier. Pour le 
moment je n'ai pas de meilleure proposition que d'intensifier les tests et, à 
l'occasion de la refonte des fichiers d'exemple pour les tests TCM, d'essayer 
d'y inclure  des vérifications plus larges.

Je me demande aussi, et j'aimerais avoir votre avis là-dessus, s'il ne serait 
pas utile de publier une page d'information sur les bugs et problèmes connus 
importants de la version stable courante. Cela permettrait d'améliorer 
l'information des utilisateurs. Il ne s'agirait pas bien sûr de faire une liste 
exhaustive ni très longue afin d'éviter de noyer le lecteur sous l'abondance 
d'information. Au contraire il s'agirait de n'afficher que les bugs et 
problèmes qui nous paraissent susceptibles d'avoir un impact réellement négatif.
Cette page servirait aussi de fait de programme de tests complémentaires lors 
des tests QA de la version suivante.

Qu'en pensez-vous ?

Je rejoins toutes les idées et opinions qui ont été exprimées, notamment 
le wiki, les fichiers de test et anticiper au maximum.


Pour ma part, j'ai tendance à essayer d'utiliser les versions dev et rc 
en situation et ne faire les tests TCM qu'au tout, mais vraiment tout 
dernier moment (hum, n'est-ce pas Jean-Baptiste?).
Mon objectif étant d'essayer d'isoler un bug et de le glisser en fail 
dans le TCM le plus approchant...

:-)

Bonne soirée.

-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org



Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-14 Par sujet Jean-Francois Nifenecker
Jean-Baptiste Faure a écrit :
> Bonjour,

Bonjour,

> 
> http://www.openoffice.org/issues/show_bug.cgi?id=101690 (8 mai 2009)
> : le tri de lignes contenant des formules mélange les références ; le
> bazar que ça met dans une feuille de calcul ne saute pas forcément
> aux yeux ce qui en fait un bug vicieux. La correction était ciblée
> 3.2 mais nous avons étaient plusieurs à souligner la nécessité de
> corriger ça dés la 3.1.1.

Pour moi, c'est ce bug-là qui est le plus grave. Un risque de
"perturbation" complète d'une feuille Calc, sans que cette
"perturbation" soit apparente implique pour moi le retour à la v.3.0.1.

A+
-- 
Jean-Francois Nifenecker, Bordeaux

-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org



Re: [qa-test] Comment avons-nous p u laisser passer ça ?

2009-05-14 Par sujet Jean-François PHILIP

Jean-Baptiste Faure a écrit :

Bonjour,

Hier j'ai mis en release blocker (stopper) 2 bugs pour la 3.1 :

http://www.openoffice.org/issues/show_bug.cgi?id=101869 (13 mai 2009) : le 
problème signalé hier matin par Marie-Jo, (La coupure de lignes complètes quand 
une cellule contient une référence à une cellule de la même colonne, bloque OOo 
sur XP et MacOS).

http://www.openoffice.org/issues/show_bug.cgi?id=101690 (8 mai 2009) : le tri 
de lignes contenant des formules mélange les références ; le bazar que ça met 
dans une feuille de calcul ne saute pas forcément aux yeux ce qui en fait un 
bug vicieux. La correction était ciblée 3.2 mais nous avons étaient plusieurs à 
souligner la nécessité de corriger ça dés la 3.1.1.

Les deux sont déjà corrigés mais il faudra attendre la 3.1.1 pour en profiter.

Je m'interroge sur l'efficacité de nos tests qui nous ont permis de laisser 
passer ce genre de chose et sans doute d'autres aussi gênantes. Pour ma part je 
pense que j'aurais pu voir le bug sur le tri si j'avais utilisé la RC2 sur ma 
machine professionnelle au lieu de l'expérimenter seulement hier. Pour le 
moment je n'ai pas de meilleure proposition que d'intensifier les tests et, à 
l'occasion de la refonte des fichiers d'exemple pour les tests TCM, d'essayer 
d'y inclure  des vérifications plus larges.

Je me demande aussi, et j'aimerais avoir votre avis là-dessus, s'il ne serait 
pas utile de publier une page d'information sur les bugs et problèmes connus 
importants de la version stable courante. Cela permettrait d'améliorer 
l'information des utilisateurs. Il ne s'agirait pas bien sûr de faire une liste 
exhaustive ni très longue afin d'éviter de noyer le lecteur sous l'abondance 
d'information. Au contraire il s'agirait de n'afficher que les bugs et 
problèmes qui nous paraissent susceptibles d'avoir un impact réellement négatif.
Cette page servirait aussi de fait de programme de tests complémentaires lors 
des tests QA de la version suivante.

Qu'en pensez-vous ?

Bonjour Jean-Baptiste

J'ajoute ce que je considère comme un bug sur la fonction INDIRECT :
http://fr.openoffice.org/issues/show_bug.cgi?id=101645

A mon avis, nous n'avons tout simplement pas assez de temps pour tester 
les versions ;

Personnellement, avec le boulot et la famille, 1 semaine c'est court...

Avec un semaine de plus, j'ai le temps de faire "tourner" mes fichiers 
sur la RC à tester ;


Une refonte des fichiers de test serait effectivement la bienvenue,
je pense que tout le monde l'a réclamé ici.
Faire une page d'accueil sur les bugs rencontrés serait effectivement 
utile aux testeurs,

mais risquerai d'effrayer le néophyte, je pense.

Voilà pour mon avis qui n'engage que moi ;)
Jeff



-
To unsubscribe, e-mail: qa-test-unsubscr...@fr.openoffice.org
For additional commands, e-mail: qa-test-h...@fr.openoffice.org