Vous reprendrez bien une part de QA ?
Ou "assurance qualité" pour les intimes
Annonces, Actus et Infos / Mageia.org
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
Voilà un petit message de la part de l'équipe QA (via la prose d'Atelier et votre équipe de traduction préférée) sur le blog de Mageia :
Nous avons besoin de vous (pour tester et casser des trucs)
Utilisateurs, contributeurs, cet appel vient du cœur.
Nous n’arrêtons pas de parler du fait que Mageia est comme ceci, Mageia a besoin de cela et Mageia a réalisé cette chose étonnante… Mais vous savez quoi ? C’est un peu trompeur. Vous savez, Mageia n’est ni un grand groupe, ni même une petite entreprise. Mageia est une association de personnes. Des personnes comme vous. Et aujourd’hui, nous avons besoin de personnes comme vous.
Tout ceux qui ont déjà essayé d’obtenir un travail dans l’industrie des hautes technologies savent qu’une grande majorité des nouveaux embauchés est affectée à l’assurance qualité (« QA » en anglais), dont nous en avons tous besoin. C’est parce que ce secteur requiert beaucoup de main-d’oeuvre. Après tout, il n’y a besoin que de quelques esprits brillants pour créer d’excellents algorithmes, un peu plus pour écrire le code, et des légions entières pour essayer toutes les façons possibles de le faire fonctionner autrement que prévu. Parce que quelque part, quelqu’un va trouver cettepossibilité étrange qui va tout faire planter. Et avant de publier quoi que ce soit, qu’il s’agisse d’un nouveau système d’exploitation ou juste d’une petite mise à jour de sécurité, nous avons besoin d’avoir l’assurance qu’il corresponde à nosexigences de qualité.
Et c’est là que vous entrez en jeu.
Aujourd’hui, notre équipe qualité est vraiment petite. Petite à quel point ? Elle l’est tellement qu’il n’y a à l’heure actuelle qu’une seule experte en assurance qualité. Au départ, ils étaient deux, mais l’un deux à été obligé de réduire grandement son implication à cause de problèmes de santé. Nous lui souhaitons de se rétablir vite. Désormais, la plus grosse partie du travail tombe dans les mains de notre unique autre experte en assurance qualité. Elle fait de son mieux pour assurer la qualité dont nous avons besoin tout en essayant de former le petit groupe de volontaires de l’équipe. Ne vous trompez pas, ces « professionnels non entraînés » font aussi de l’excellent travail. En réalité, ils abattent une somme de travail considérable et du meilleur niveau tout en étant assez nouveaux dans l’équipe d’assurance qualité, et pourtant, ils sont submergés. Nous avons besoin de plus de personnes comme elles.
Chaque nouvelle mise à jour a besoin d’être testée sur les deux versions maintenues (actuellement Mageia 3 et Mageia 4) pour les deux architectures supportées (32 et 64 bits). Cela signifie que chaque petite mise à jour de sécurité ou nouvelle fonctionnalité à besoin d’être testée quatre fois avant que nous la publions, et la plupart de ce travail est réalisé par une seule personne.
Nous avons besoin de renforts, et vous pouvez aider.
C’est vraiment facile. Avec un petit peu de formation et d’expérience, vous pouvez vous aussi devenir un excellent testeur qualité.
Consultez simplement le portail de l’équipe assurance qualité et découvrez comment vous pouvez aider.
Mageia, c’est sa communauté, et aujourd’hui, nous avons besoin d’aide.
Utilisateurs, contributeurs, cet appel vient du cœur.
Nous n’arrêtons pas de parler du fait que Mageia est comme ceci, Mageia a besoin de cela et Mageia a réalisé cette chose étonnante… Mais vous savez quoi ? C’est un peu trompeur. Vous savez, Mageia n’est ni un grand groupe, ni même une petite entreprise. Mageia est une association de personnes. Des personnes comme vous. Et aujourd’hui, nous avons besoin de personnes comme vous.
Tout ceux qui ont déjà essayé d’obtenir un travail dans l’industrie des hautes technologies savent qu’une grande majorité des nouveaux embauchés est affectée à l’assurance qualité (« QA » en anglais), dont nous en avons tous besoin. C’est parce que ce secteur requiert beaucoup de main-d’oeuvre. Après tout, il n’y a besoin que de quelques esprits brillants pour créer d’excellents algorithmes, un peu plus pour écrire le code, et des légions entières pour essayer toutes les façons possibles de le faire fonctionner autrement que prévu. Parce que quelque part, quelqu’un va trouver cettepossibilité étrange qui va tout faire planter. Et avant de publier quoi que ce soit, qu’il s’agisse d’un nouveau système d’exploitation ou juste d’une petite mise à jour de sécurité, nous avons besoin d’avoir l’assurance qu’il corresponde à nosexigences de qualité.
Et c’est là que vous entrez en jeu.
Aujourd’hui, notre équipe qualité est vraiment petite. Petite à quel point ? Elle l’est tellement qu’il n’y a à l’heure actuelle qu’une seule experte en assurance qualité. Au départ, ils étaient deux, mais l’un deux à été obligé de réduire grandement son implication à cause de problèmes de santé. Nous lui souhaitons de se rétablir vite. Désormais, la plus grosse partie du travail tombe dans les mains de notre unique autre experte en assurance qualité. Elle fait de son mieux pour assurer la qualité dont nous avons besoin tout en essayant de former le petit groupe de volontaires de l’équipe. Ne vous trompez pas, ces « professionnels non entraînés » font aussi de l’excellent travail. En réalité, ils abattent une somme de travail considérable et du meilleur niveau tout en étant assez nouveaux dans l’équipe d’assurance qualité, et pourtant, ils sont submergés. Nous avons besoin de plus de personnes comme elles.
Chaque nouvelle mise à jour a besoin d’être testée sur les deux versions maintenues (actuellement Mageia 3 et Mageia 4) pour les deux architectures supportées (32 et 64 bits). Cela signifie que chaque petite mise à jour de sécurité ou nouvelle fonctionnalité à besoin d’être testée quatre fois avant que nous la publions, et la plupart de ce travail est réalisé par une seule personne.
Nous avons besoin de renforts, et vous pouvez aider.
C’est vraiment facile. Avec un petit peu de formation et d’expérience, vous pouvez vous aussi devenir un excellent testeur qualité.
Consultez simplement le portail de l’équipe assurance qualité et découvrez comment vous pouvez aider.
Mageia, c’est sa communauté, et aujourd’hui, nous avons besoin d’aide.
Une question subsidiaire serait : Qu'est-ce que l'équipe QA et/ou MLO peuvent faire pour vous aider à participer plus à l'assurance qualité ? Un système de mentoring sur le forum MLO (et/ou le canal #MLO) tout en restant en lien étroit avec l'équipe QA (et son canal #mageia-qa, pour ne pas scinder la communauté) ? Donnez vos idées, et n'hésitez pas à vous investir dans la QA, c'est un beau métier
Édité par Akien Le 22/08/2014 à 10h26
lebarhon Membre non connecté
-
- Voir le profil du membre lebarhon
- Inscrit le : 09/10/2010
- Groupes :
-
Équipe Mageia
-
Membre d'Honneur
Ayant participé à la traduction, cela m'a donné envie de voir ce que je pouvais faire pour QA. J'ai donc lu une bonne partie des pages wiki qui traitent du sujet. La réponse est quasi Rien !
Il y a 5 écueils qui rendent difficile la participation à QA pour un lecteur de MLO qui voudrait aider :
1 - la maitrise de l'anglais
2 - la bonne compréhension de certaines notions de conception informatique (ex : git/svn, build, compilation, srpm, ... )
3 - la maîtrise des outils de QA (Bugzilla, gestion des advisories, ..)
4 - La bonne connaissance de Mageia (et donc de Linux), notamment les interfaces Mageia/Bureau/Applications/. Comment sont articulées les gestions du son, de l'image, où sont les fichiers de config, etc...
5 - La bonne connaissance du hardware (ce point est assez bien maitrisé chez lez utilisateurs de MLO) mais il faut aussi posséder celui que l'on veut tester.
Cela fait beaucoup, pour moi, 2 et 4 sont rédhibitoires.
Il faut donc trouver un moyen de résoudre ces écueils sans que cela prenne trop de temps à la QA team déjà surchargée. J'ai pensé qu'il serait peut-être possible de faire des groupes d'environ 3 à 5 personnes, un leader qui maîtrise les 5 points ci-dessus et au moins 2 exécutants (idéalement un en 32 bits et l'autre en 64) auxquels le leader "sous-traite" des tâches élémentaires puis de moins en moins élémentaires avec le temps. Une même langue maternelle au sein des groupes serait un plus.
stef74 Membre non connecté
-
- Voir le profil du membre stef74
- Inscrit le : 23/11/2008
Ton idée est bonne, mais je penses qu'il va être difficile de trouver quelqu'un qui maîtrise les 5 points. Si c'est le cas, il faudra peut-être avoir un représentant de l’équipe et que dans l’équipe, on puisse retrouvé des gens qui se complémentent sur chacun des points.
Perso vue que je reprend un peut du service, je suis dispo sur les tests d'installation sur machine en raid. Actuellement sur du dmraid, demain dmraid +mdadm.
Apres faut aussi faire avec la dispo des gens... Et la ça va être encore plus compliqué pour cela que je me mettrais jamais leader et que j’hésite toujours a revenir dans les traductions.
Stef.
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
lebarhon :
Bonjour,
Ayant participé à la traduction, cela m'a donné envie de voir ce que je pouvais faire pour QA. J'ai donc lu une bonne partie des pages wiki qui traitent du sujet. La réponse est quasi Rien !
Il y a 5 écueils qui rendent difficile la participation à QA pour un lecteur de MLO qui voudrait aider :
Ayant participé à la traduction, cela m'a donné envie de voir ce que je pouvais faire pour QA. J'ai donc lu une bonne partie des pages wiki qui traitent du sujet. La réponse est quasi Rien !
Il y a 5 écueils qui rendent difficile la participation à QA pour un lecteur de MLO qui voudrait aider :
Tes remarques semblent montrer que le wiki donne trop d'informations et ne précise pas assez comment démarrer dans la QA. Parce que c'est vrai, pour être un expert QA il est nécessaire de maîtriser tout ce que tu as listé. Mais ce n'est pas nécessaire pour démarrer, voire pas nécessaire du tout (par exemple la gestion des advisories est le boulot des packagers qui les écrivent et de MrsB ou moi qui les uploadent sur svn, les autres testeurs n'ont pas à s'en occuper).
lebarhon :
1 - la maitrise de l'anglais
Ça c'est vrai que c'est indispensable pour apprendre. C'est là que le mentoring interne à MLO pourrait aider, par exemple j'ai aidé aranud87 à démarrer et il se débrouille très bien. Après pour ce qui est de comprendre les rapports de bugs et d'y ajouter un commentaire, Google Translate fait déjà assez bien le boulot, même si ce n'est pas très pratique.
lebarhon :
2 - la bonne compréhension de certaines notions de conception informatique (ex : git/svn, build, compilation, srpm, ... )
Ça ne me semble pas nécessaire de prime abord non. Ce qui est important, c'est de savoir gérer ses dépôts et de connaître quelques commandes telles que urpm[i,q,f] qui simplifient la vie. (par exemple installer un paquet directement depuis les dépôts testing sans avoir eu à les activer : urpmi <paquet> --searchmedia "testing").
Savoir qu'un SRPM est la source qui permet de générer les RPM n'est pas inutile non plus, mais c'est dit en une phrase :-)
Pour ce qui est de git/svn ou la compilation, ce n'est pas nécessaire non. Après il est clair que certaines mises à jour sont assez difficiles à tester, notamment quand il s'agit d'une application web et qu'il faut créer une base de données MySQL par exemple. Mais dans ce cas là ce ne sont pas les débutants qui s'en chargent.
lebarhon :
3 - la maîtrise des outils de QA (Bugzilla, gestion des advisories, ..)
Comme dit précédemment, les testeurs n'ont pas à s'occuper des advisories. Pour ce qui est de la maîtrise de Bugzilla, il faut savoir poster un commentaire et ajouter une mention dans le "whiteboard", ça ne va pas beaucoup plus loin.
lebarhon :
4 - La bonne connaissance de Mageia (et donc de Linux), notamment les interfaces Mageia/Bureau/Applications/. Comment sont articulées les gestions du son, de l'image, où sont les fichiers de config, etc...
Ça fait partie de ce qui rentre en compte dans la QA, mais ça ne veut pas dire qu'on ne peut pas faire de QA si on n'est pas un pro de Linux. Au contraire, les procédures détaillées qui existent déjà pour de nombreuses mises à jour permettent d'apprendre beaucoup de choses sur Linux et Mageia, quel que soit notre niveau. J'en apprends un peu plus à chaque nouvelle mise à jour. Et comme toujours il n'y a pas de questions bêtes, donc si vous ne savez pas où sont les fichiers de config, ou comment un programme fonctionne, il suffit de demander (ou de s'occuper d'une autre mise à jour et de lire le détail des tests que feront d'autres membres de l'équipe).
lebarhon :
5 - La bonne connaissance du hardware (ce point est assez bien maitrisé chez lez utilisateurs de MLO) mais il faut aussi posséder celui que l'on veut tester.
Ça ne me parait pas forcément nécessaire, moi je suis une bille en hardware par exemple :-) Quand j'ai un problème de compatibilité matérielle, je ne sais pas le résoudre, donc je demande de l'aide.
lebarhon :
Il faut donc trouver un moyen de résoudre ces écueils sans que cela prenne trop de temps à la QA team déjà surchargée. J'ai pensé qu'il serait peut-être possible de faire des groupes d'environ 3 à 5 personnes, un leader qui maîtrise les 5 points ci-dessus et au moins 2 exécutants (idéalement un en 32 bits et l'autre en 64) auxquels le leader "sous-traite" des tâches élémentaires puis de moins en moins élémentaires avec le temps. Une même langue maternelle au sein des groupes serait un plus.
Je pense qu'il ne faut pas faire si compliqué. Je pensais plutôt que ceux qui ont envie d'essayer le disent, et que les membres de MLO qui savent déjà faire de la QA se chargent ensemble de les aider. Entre david.david, leuhmanu, aranud87 et moi, il y a toujours quelqu'un sur #MLO qui peut aider un testeur débutant.
Note que je propose IRC parce que c'est ce que je trouve de plus pratique personnellement, mais il pourrait aussi y avoir une section du forum dédiée à la QA (comme aranud87 l'a déjà proposé).
Édité par Akien Le 22/08/2014 à 17h51
lebarhon Membre non connecté
-
- Voir le profil du membre lebarhon
- Inscrit le : 09/10/2010
- Groupes :
-
Équipe Mageia
-
Membre d'Honneur
Le blog dit que la QA manque terriblement de main d’œuvre (1 seul expert et une poignée au total) et tu me cites 4 personnes rien que sur MLO. J'en déduis que ces personnes n'ont pas ou très peu de disponibilité en ce moment, comment pourraient elles trouver en plus le temps de former des nouveaux ?
IRC est bien pour lever rapidement un point de méthode bloquant, mais plus la discussion porte sur le fond et plus forum ou ML sont efficaces pour le suivi.
Je suis disposé à tenter l'aventure (un peu pris jusqu'à mi-septembre, beaucoup mieux après) vu que coté doc cela semble calme.
Je dispose d'un laptop et bientôt d'un desktop entièrement dédiés aux tests, mais aucune compétence en informatique, qu'est ce qu'on fait ?
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
lebarhon :
C'est vrai que le wiki de QA fait peur lorsqu'on n'est pas du même monde.
Le blog dit que la QA manque terriblement de main d’œuvre (1 seul expert et une poignée au total) et tu me cites 4 personnes rien que sur MLO. J'en déduis que ces personnes n'ont pas ou très peu de disponibilité en ce moment, comment pourraient elles trouver en plus le temps de former des nouveaux ?
Le blog dit que la QA manque terriblement de main d’œuvre (1 seul expert et une poignée au total) et tu me cites 4 personnes rien que sur MLO. J'en déduis que ces personnes n'ont pas ou très peu de disponibilité en ce moment, comment pourraient elles trouver en plus le temps de former des nouveaux ?
J'ai cité quatre personnes de chez MLO qui savent faire de la QA, ce qui ne veut pas dire qu'elles en font de façon régulière. Leuhmanu est plutôt du côté du triage de bug, et heureusement pour nous car c'est extrêmement important. Aranud87, david.david et moi avons un peu d'expérience, mais ça ne veut pas dire qu'on est toujours dispos. L'équipe QA est énorme si on en croit sa ML (172 inscrits !), mais chaque semaine ce sont peut être deux ou trois personnes qui s'investissent sur les tests de mises à jour, et 5 ou 6 sur les tests d'images ISO. C'est pour ça qu'il est important de former des nouveaux : il n'est pas nécessaire d'avoir 10h de dispo par semaine pour la QA, il faut juste pouvoir faire un petit test de temps en temps. Si on a 50 personnes qui font un test par semaine, on est largement bons.
lebarhon :
IRC est bien pour lever rapidement un point de méthode bloquant, mais plus la discussion porte sur le fond et plus forum ou ML sont efficaces pour le suivi.
Je suis disposé à tenter l'aventure (un peu pris jusqu'à mi-septembre, beaucoup mieux après) vu que coté doc cela semble calme.
Je dispose d'un laptop et bientôt d'un desktop entièrement dédiés aux tests, mais aucune compétence en informatique, qu'est ce qu'on fait ?
Je suis disposé à tenter l'aventure (un peu pris jusqu'à mi-septembre, beaucoup mieux après) vu que coté doc cela semble calme.
Je dispose d'un laptop et bientôt d'un desktop entièrement dédiés aux tests, mais aucune compétence en informatique, qu'est ce qu'on fait ?
La référence, c'est MADB : http://mageia.madb.org/tools/updates
Ce lien est la todo liste de l'équipe QA, il est donc bien à garder en marque-page. Ensuite pour commencer, il vaut mieux s'essayer sur une mise à jour facile à tester, de préférence ayant un "yes" dans la case "Procedure available?".
Actuellement il n'y a que deux mises à jour qui me semblent relativement simples à tester :
- Trojita (mga#13941) : C'est juste une dépendance manquante, il faut donc simplement vérifier que la version de core/release de trojita plante si la dépendances manquante n'est pas installée, et que la mise à jour force l'installation de la dépendance pour corriger le problème.
- Blender (mga#13960) : La mise à jour est pour un correctif de sécurité, mais comme on ne sait pas bien comment le tester, il devrait être suffisant de vérifier que la version de core/updates_testing de Blender fonctionne bien (en jouant un peu avec l'interface, éventuellement en essayant d'ouvrir un modèle .blend trouvé sur Internet, etc.). Pas besoin de faire un test très poussé.
Je suis sur IRC dans la soirée si tu veux essayer de tester l'un des deux, je peux t'expliquer la procédure de QA en parallèle (elle est déjà détaillée sur le wiki et je pourrais en redonner les grandes lignes de manière générale ici, mais je préfère le faire en live pour pouvoir bien expliquer ce qui doit l'être, et ne pas insister sur ce qui n'est pas important).
Édité par Akien Le 22/08/2014 à 19h25
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
La principale difficulté pour celui-là était qu'il n'y a pas d'interface utilisateur pour ce logiciel, et que les touches par défaut dans un jeu sont absurdes, et pas évidentes à redéfinir pour les francophones parce qu'il faut utiliser la combinaison Alt + Shift + 1, et que bien évident nos chers claviers azerty n'ont pas de touche « 1 », mais une touche « & »...
Pour pouvoir suivre la procédure détaillée que j'ai donné, il faut donc pour la français penser à passer en clavier américain auparavant (soit dans la configuration du bureau, soit avec setxkbmap en_US - on repasse en français avec setxkbmap fr). Voilà un exemple d'un commande linux pratique pour la QA que l'utilisateur lambda ne connait pas, mais que je donne gratos parce que je suis sympa :-)
vouf Membre non connecté
-
- Voir le profil du membre vouf
- Inscrit le : 16/08/2008
- Groupes :
Je vais étudier la documentation et regarder si je peux apporter mon aide. Je pense pouvoir répondre à certaines exigences mais, sans doutes pas à toutes. Pour l'anglais, je ne suis pas excellent mais j'essaye de me débrouiller. J'utilise la double technique de traduction avec Google translate pour m'assurer que mon anglais est compréhensible. Je traduis d'abord le français en anglais, puis l'anglais en français et adapte en conséquence la traduction.. C'est assez efficace.
Je me débrouille avec urpmi, la ligne de commande et connait assez bien Mageia/mandriva, même si tout cela est bien sûr perfectible.
Pour la charge de travail, je suis surtout dispo le vendredi après midi et le weekend. Si je me lance dans cette aventure, je pense qu'une aide via irc serait bienvenue pour m'assurer que je maitrise le process..... On pourrait peut être sans doute se soutenir entre novices ??
stef74 Membre non connecté
-
- Voir le profil du membre stef74
- Inscrit le : 23/11/2008
Va falloir organiser une seance de formation!
Stef.
lebarhon Membre non connecté
-
- Voir le profil du membre lebarhon
- Inscrit le : 09/10/2010
- Groupes :
-
Équipe Mageia
-
Membre d'Honneur
stef74 :
Salut,
Va falloir organiser une seance de formation!
Stef.
Va falloir organiser une seance de formation!
Stef.
Surement bien plus qu'une
Sur http://mageia.madb.org/tools/updates 13941 (trojita) semble validé pour le 64 bits, or je n'ai pas de 32.
13960 (Blender) ne se trouve apparemment pas dans core/updates_testing, impossible de le trouver. Dans le MCC, j'ai bien les cases Enabled et Updates de cochées pour Core Update Testing, fait urpmi.update -a, mais pas de Blender.
Dans https://wiki.mageia.org/en/QA_process_for_validating_updates, il est dit :
n order not to do the same job as other people from QA, duplicating the work, add a message to the update request on Bugzilla when starting work on it
je n'ai pas trouvé cet "update request"
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
lebarhon :
Sur http://mageia.madb.org/tools/updates 13941 (trojita) semble validé pour le 64 bits, or je n'ai pas de 32.
Si tu as un peu d'espace disque disponible, c'est souvent une bonne chose d'avoir des machines virtuelles pour les autres versions de Mageia pour pouvoir faire des tests (j'ai une machine virtuelle par version et par architecture). Mais pour démarrer en effet, c'est déjà bien de voir ce que tu peux faire avec ton système principal si c'est une Mageia 4 64 bits. Tu pourras toujours te mettre aux machines virtuelles une fois plus confiant :-)
lebarhon :
13960 (Blender) ne se trouve apparemment pas dans core/updates_testing, impossible de le trouver. Dans le MCC, j'ai bien les cases Enabled et Updates de cochées pour Core Update Testing, fait urpmi.update -a, mais pas de Blender.
Il est pourtant bien dans les dépôts, d'après Sophie :
IRC :
<Akien> :v blender -v4 -a x86_64
<Sophie> Akien: 2.69-1.1.mga4 // core-updates_testing (Mga, 4, x86_64)
<Sophie> Akien: 2.69-1.mga4 // core-release (Mga, 4, x86_64)
<Sophie> Akien: 2.69-1.1.mga4 // core-updates_testing (Mga, 4, x86_64)
<Sophie> Akien: 2.69-1.mga4 // core-release (Mga, 4, x86_64)
C'est peut être que ton miroir est un peu lent pour se mettre à jour ?
lebarhon :
je n'ai pas trouvé cet "update request"
Dans https://wiki.mageia.org/en/QA_process_for_validating_updates, il est dit :
n order not to do the same job as other people from QA, duplicating the work, add a message to the update request on Bugzilla when starting work on it
je n'ai pas trouvé cet "update request"
« Update request » dans ce cas signifie juste le rapport de bug attribué à l'équipe QA pour cette mise à jour. Chaque mise à jour (on parle d'« update candidate » tant qu'elles n'ont pas été validées) a son propre rapport de bug utilisé pour les tests. C'est celui qui est listé sur MADB, donc le bug 13960.
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
vouf :
Je vais étudier la documentation et regarder si je peux apporter mon aide. Je pense pouvoir répondre à certaines exigences mais, sans doutes pas à toutes. Pour l'anglais, je ne suis pas excellent mais j'essaye de me débrouiller. J'utilise la double technique de traduction avec Google translate pour m'assurer que mon anglais est compréhensible. Je traduis d'abord le français en anglais, puis l'anglais en français et adapte en conséquence la traduction.. C'est assez efficace.
Je me débrouille avec urpmi, la ligne de commande et connait assez bien Mageia/mandriva, même si tout cela est bien sûr perfectible.
Pour la charge de travail, je suis surtout dispo le vendredi après midi et le weekend. Si je me lance dans cette aventure, je pense qu'une aide via irc serait bienvenue pour m'assurer que je maitrise le process..... On pourrait peut être sans doute se soutenir entre novices ??
Je me débrouille avec urpmi, la ligne de commande et connait assez bien Mageia/mandriva, même si tout cela est bien sûr perfectible.
Pour la charge de travail, je suis surtout dispo le vendredi après midi et le weekend. Si je me lance dans cette aventure, je pense qu'une aide via irc serait bienvenue pour m'assurer que je maitrise le process..... On pourrait peut être sans doute se soutenir entre novices ??
Tu m'as l'air d'avoir le profil parfait pour le job :-D
N'hésite pas à venir sur le canal #MLO de Freenode, il y a souvent david_david ou moi, et on devrait pouvoir t'aider à démarrer. L'entraide entre novices me semble être une bonne chose aussi. Comme l'a dit lebarhon, il y a beaucoup de choses à connaître pour pouvoir faire de la QA « facilement ». Mais à plusieurs novices plus un ou deux mentors, on a largement les connaissances suffisantes pour n'importe quelle mise à jour :-)
ducyp9 Membre non connecté
-
- Voir le profil du membre ducyp9
- Inscrit le : 23/05/2011
- Groupes :
Citation Akien
Citation :
Actuellement il n'y a que deux mises à jour qui me semblent relativement simples à tester :
- Trojita (mga#13941) : C'est juste une dépendance manquante, il faut donc simplement vérifier que la version de core/release de trojita plante si la dépendances manquante n'est pas installée, et que la mise à jour force l'installation de la dépendance pour corriger le problème.
- Trojita (mga#13941) : C'est juste une dépendance manquante, il faut donc simplement vérifier que la version de core/release de trojita plante si la dépendances manquante n'est pas installée, et que la mise à jour force l'installation de la dépendance pour corriger le problème.
Je suis sous Mageia4, 32 bits, KDE. Voici mon retour d'utilisateur.
J'ai essayé quelques manipulations sous le CCM (source activées : Core release, NonFree release, Tainted Release avec Updates correspondantes). J'ai bien compris qu'il faut utiliser urpm(i, e, q et autres ?...) en console dans le cadre des activités de la QA team.
- Installation de Trojita, version 0.3.93, révision 2.mga4 : installation réussie puis plantage du à la dépendance.
- Installation de qt4-database-plugin-sqlite (deux choix version 4.8.5 version 7.mga4 ou version 4.8.6 version 1.mga4) : installation de la version 4.8.6 (est-ce le bon choix?), il n'y a plus de plantage lors du lancement de Trojita.
- Désinstallation de qt4-database-plugin-sqlite : à nouveau plantage du à la dépendance.
- Mise à jour du système (Trojita étant installé) : la mise à jour ne force pas l'installation de la dépendance. Pour tester la correction, est-il nécessaire de configurer d'autres sources (genre Testing, Backport, Debug), le tout en console ?
Enfin, j'ai fait ces manipulations à partir des explication de la citation d'Akien ci-dessus. Je ne comprends pas tout sur mga#13941.
Après avoir fait ces manipulations, je comprends cette partie en anglais, car j'ai pu reproduire le problème :
Citation :
Reproducible: Yes
Steps to Reproduce: Install trojita, assuming the package qt4-database-plugin-sqlite is not installed, there is the following error:
http://up.picr.de/18947527rh.png
After installing the missing dependency qt4-database-plugin-sqlite, the problem is solved
Steps to Reproduce: Install trojita, assuming the package qt4-database-plugin-sqlite is not installed, there is the following error:
http://up.picr.de/18947527rh.png
After installing the missing dependency qt4-database-plugin-sqlite, the problem is solved
Pour autant, je ne pense pas avoir « validé » la correction du bug. Je ne me situe pas dans le processus de validation.
J'espère que ce retour peut donner une idée de la formation nécessaire à mettre en place, sous réserve que je sois un cas suffisamment représentatif des utilisateurs.
Akien Membre non connecté
-
- Voir le profil du membre Akien
- Inscrit le : 12/06/2011
- Groupes :
-
Équipe Mageia
ducyp9 :
Je suis sous Mageia4, 32 bits, KDE. Voici mon retour d'utilisateur.
J'ai essayé quelques manipulations sous le CCM (source activées : Core release, NonFree release, Tainted Release avec Updates correspondantes). J'ai bien compris qu'il faut utiliser urpm(i, e, q et autres ?...) en console dans le cadre des activités de la QA team.
J'ai essayé quelques manipulations sous le CCM (source activées : Core release, NonFree release, Tainted Release avec Updates correspondantes). J'ai bien compris qu'il faut utiliser urpm(i, e, q et autres ?...) en console dans le cadre des activités de la QA team.
- Installation de Trojita, version 0.3.93, révision 2.mga4 : installation réussie puis plantage du à la dépendance.
- Installation de qt4-database-plugin-sqlite (deux choix version 4.8.5 version 7.mga4 ou version 4.8.6 version 1.mga4) : installation de la version 4.8.6 (est-ce le bon choix?), il n'y a plus de plantage lors du lancement de Trojita.
- Désinstallation de qt4-database-plugin-sqlite : à nouveau plantage du à la dépendance.
- Mise à jour du système (Trojita étant installé) : la mise à jour ne force pas l'installation de la dépendance. Pour tester la correction, est-il nécessaire de configurer d'autres sources (genre Testing, Backport, Debug), le tout en console ?
Merci pour ce retour ducyp9, tu es sur la bonne voie. J'ai en effet deux trois choses à préciser sur la méthodologie de QA.
Quand on propose une mise à jour à faire tester par la QA, cette dernière n'est pas encore « officielle », c'est à dire qu'elle n'est pas dans les dépôts « Updates » mais dans les dépôts « Updates Testing ». On parle alors d'« update candidate »..
Le boulot de la QA est donc en règle générale de :
- Tester le paquet de « Core Release » (ou nonfree ou tainted le cas échéant) et vérifier que le bug décrit dans le rapport est bien présent (si on est pas affecté par le bug, il est plus difficile de déterminer si la mise à jour le corrige). Parfois il est difficile de reproduire le bug (par exemple sur des mises à jour de sécurité), et on passe cette étape.
- Tester la mise à jour candidate de « Core Updates Testing ». Pour ce faire il faut activer le dépôt testing, le mettre à jour, puis enfin la mise à jour est disponible. Il faut être vigilant de ne pas mettre à jour tout le système, car il y a beaucoup de paquets en cours de test dans les dépôts testing, et on ne veut en général qu'en récupérer un ou deux. Il ne faut pas oublier de désactiver le dépôt testing après. Pour chaque test, on « pioche » donc dans le dépôt testing pour récupérer uniquement ce qui nous intéresse.
Pour récupérer le bon paquet dans le dépôt testing, il y a trois solutions :
- La ligne de commande, ce qui permet de garder le dépôt testing inactif en temps normal. Sans activer le dépôt testing dans le MCC, on peut faire :
Code :# urpmi.update "testing"
# urpmi trojita --searchmedia "testing" - MageiaUpdate (l'application de mise à jour) : après avoir activé et mis à jour le dépôt testing, on peut aller dans MageiaUpdate, faire décocher toutes les mises à jour, puis cocher seulement celles qui nous intéressent (ici trojita). Une fois les tests terminés, on désactive le dépôt testing.
- Le CCM : si le dépôt testing est activé, le paquet recherché doit apparaître aux côtés de la version de "Core Release". On peut donc l'installer comme on installe un paquet habituellement.
Pour les adeptes de la ligne de commande, il est possible d'activer et de désactiver les dépôts que l'on veut sans passer par le CCM :
Code :
$ urpmi.update --no-ignore "testing"
// active tous les dépôts contenant "testing" dans leur nom
$ urpmi.update -a
// met à jour tous les dépôts actifs
$ urpmi.update --ignore "testing"
// une fois les tests terminés, désactive les dépôts "testing"
Édité par Akien Le 23/08/2014 à 15h50
ducyp9 Membre non connecté
-
- Voir le profil du membre ducyp9
- Inscrit le : 23/05/2011
- Groupes :
J'ai installé le paquet de "Core release" en ligne de commande avec urpmi pour reproduire le bug. C'est parfait, le bug est reproduit. J'ai ensuite tout désinstallé avec urpme.
Étape 2 :
j'ai utilisé la ligne de commande avec la première méthode que tu proposes. Voici le résultat.
Caché :
[root@localhost christian]# urpmi.update "testing"
le média « Core Updates Testing » est à jour
le média « Core Updates Testing Debug » est à jour
le média « Core Backports Testing » est à jour
le média « Core Backports Testing Debug » est à jour
le média « Nonfree Updates Testing » est à jour
le média « Nonfree Updates Testing Debug » est à jour
le média « Nonfree Backports Testing » est à jour
le média « Nonfree Backports Testing Debug » est à jour
le média « Tainted Updates Testing » est à jour
le média « Tainted Updates Testing Debug » est à jour
le média « Tainted Backports Testing » est à jour
le média « Tainted Backports Testing Debug » est à jour
[root@localhost christian]# urpmi trojita --searchmedia "testing"
Pour satisfaire les dépendances, les paquetages suivants vont être installés :
Paquetage Version Révision Arch
(média « Core Updates »)
qt4-database-plugin-sqlite 4.8.6 1.mga4 i586
(média « Core Updates Testing »)
trojita 0.3.93 2.1.mga4 i586
un espace additionnel de 3.5Mo sera utilisé.
915Ko de paquets seront récupérés.
Procéder à l'installation des 2 paquetages ? (O/n) o
rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/i586/media/core/updates/qt4-database-plugin-sqlite-4.8.6-1.mga4.i586.rpm
rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/i586/media/core/updates_testing/trojita-0.3.93-2.1.mga4.i586.rpm
installation de qt4-database-plugin-sqlite-4.8.6-1.mga4.i586.rpm trojita-0.3.93-2.1.mga4.i586.rpm depuis /var/cache/urpmi/rpms
Préparation... #########################################################################################################
1/2: qt4-database-plugin-sqlite
#########################################################################################################
2/2: trojita #########################################################################################################
[root@localhost christian]#
le média « Core Updates Testing » est à jour
le média « Core Updates Testing Debug » est à jour
le média « Core Backports Testing » est à jour
le média « Core Backports Testing Debug » est à jour
le média « Nonfree Updates Testing » est à jour
le média « Nonfree Updates Testing Debug » est à jour
le média « Nonfree Backports Testing » est à jour
le média « Nonfree Backports Testing Debug » est à jour
le média « Tainted Updates Testing » est à jour
le média « Tainted Updates Testing Debug » est à jour
le média « Tainted Backports Testing » est à jour
le média « Tainted Backports Testing Debug » est à jour
[root@localhost christian]# urpmi trojita --searchmedia "testing"
Pour satisfaire les dépendances, les paquetages suivants vont être installés :
Paquetage Version Révision Arch
(média « Core Updates »)
qt4-database-plugin-sqlite 4.8.6 1.mga4 i586
(média « Core Updates Testing »)
trojita 0.3.93 2.1.mga4 i586
un espace additionnel de 3.5Mo sera utilisé.
915Ko de paquets seront récupérés.
Procéder à l'installation des 2 paquetages ? (O/n) o
rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/i586/media/core/updates/qt4-database-plugin-sqlite-4.8.6-1.mga4.i586.rpm
rsync://distrib-coffee.ipsl.jussieu.fr/pub/linux/Mageia/distrib/4/i586/media/core/updates_testing/trojita-0.3.93-2.1.mga4.i586.rpm
installation de qt4-database-plugin-sqlite-4.8.6-1.mga4.i586.rpm trojita-0.3.93-2.1.mga4.i586.rpm depuis /var/cache/urpmi/rpms
Préparation... #########################################################################################################
1/2: qt4-database-plugin-sqlite
#########################################################################################################
2/2: trojita #########################################################################################################
[root@localhost christian]#
Où en suis-je dans la procédure de test?
Édité par ducyp9 Le 23/08/2014 à 17h23
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie