Les bugs sont à déceler en pré-prod, avant la MEP

Hello !

Je viens pour dire "pas content ! pas content !", mais je ne suis pas égyptien un esclave de l'antiquité bâtissant des pyramides.

Théorie

On met la version en release, on la test en préprod, on corrige les bugs, on la passe en prod et le monde est beau est rose.

Pratique

Tout le monde (ou quasi) se contre tape de la préprod et tous les rapports de bug sont arrivés en masse au moment de la MEP de la 1.2. Donc ça n'a pas été testé en préprod.

En plus de ça, on a une foultitude de doublons dans les issues et beaucoup trop souvent des imprécisions en ce qui concerne le front. Pour rappel, pour un débug aisé il faut :

• navigateur
• OS
• résolution
• densité de pixel (@2/retina, @3, @4 ?)

Un "tout est sur le screen" n'avance généralement à pas grand chose et on est obligé de faire 15 tests avant d'arriver à reproduire le bug. C'est frustrant quand on sait que la personne aurait pu le mettre directement en 1 minute.

Je trouve ça vraiment dommage. Au final, ça me conforte dans l'idée que la préprod ne fait que rallonger le process et ne sert quasiment à rien, puisque la plupart des bugs sont signalés après coup.

Personnellement, je trouverais judicieux de lancer à la façon des meetings une soirée où les gens se réunissent pour tester en masse (10-20) la préprod aussitôt la branche de release créée. Tout le monde pourrait échanger et valider les bugs des un et des autres.

Voilà pour la suggestion et mon petit message de râleur.

Assez d'accord, la preprod est clairement sous-utilisée. Ça permet de se rendre compte des trucs évidents mais pas des détails.

Personnellement, je trouverais judicieux de lancer à la façon des meetings une soirée où les gens se réunissent pour tester en masse (10-20) la préprod aussitôt la branche de release créée. Tout le monde pourrait échanger et valider les bugs des un et des autres.

C'est pas con.

En parlant de préprod, est-ce que ce serait possible de synchroniser la table membres, si ce n'est à chaque version, au moins de temps en temps ?

C'est très exactement ce que je précisait ici. On lance la preprod, c'est bien. Mais dans mon cas par exemple, je n'ai pas le temps de tester toutes les issues je vais surement laisser tomber (de peur de faire des tests en doublons inutiles) car rien ne me dit ce qui a déjà été testé par d'autres.

Donc pour une preprod plus efficace on a besoin de savoir combien de personnes ont testés quoi, sinon, on pourrait passer du temps à retester tous les mêmes issues.

Le fait que la préprod soit mal utilisé (ou sous utilisé) actuellement ne veut pas forcément dire qu'il faut la supprimer pour tester en prod. On connait tous un exemple de boite qui font leur tests en prod et c'est pas beau à voir. Non ce qu'il faut c'est modifier notre process pour que la préprod soit utile, pas la supprimer. Si ça doit passer par des rush de tests, pourquoi pas. Mais virer la préprod n'est clairement pas la solution.

Donc pour une preprod plus efficace on a besoin de savoir combien de personnes ont testés quoi, sinon, on pourrait passer du temps à retester tous les mêmes issues.

C'est là même l'intérêt de mettre 50 personnes sur la preprod : chacun testera sur un environnement différent, une machine différent, une résolution différente, n'écrira pas la même chose dans les champs de textes, etc.

C'est à ça que ça sert la préprod. C'est une sorte de bêta. Et quand tu lance une bêta tu dis pas "J'ai testé ça, ça marche. C'est prouvé scientifiquement." si une seule personne l'a testé.

Le fait que la préprod soit mal utilisé (ou sous utilisé) actuellement ne veut pas forcément dire qu'il faut la supprimer pour tester en prod.

L'idée de mon message est de marquer les esprits pour amener à la réflexion. J'espère bien que l'idée d'une preprod persistera, mais il faudrait qu'elle soit correctement utilisée.

C'est là même l'intérêt de mettre 50 personnes sur la preprod : chacun testera sur un environnement différent, une machine différent, une résolution différente, n'écrira pas la même chose dans les champs de textes, etc.

Oui, sauf que justement il y'avait pas 50 personnes dessus. Et donc quand il y'a moins de personne, pour optimiser il faut repartir, et pour répartir il faut savoir qui a déjà fait quoi.

Bref, mais j'aime l'idée d'organiser un gros rassemblement de test sur la beta, ça serait déjà plus efficace quand il y'a peu de monde.

Faudrait une mini-news, un bandeau en haut du site, genre "Venez tester la bêta et nous donner vos retours" avec un lien vers un sujet dans le forum (un forum dédié ? un post-it) qui présente les améliorations à tester sur la pré-prod.

Autre idée : présenter ça comme un petit jeu de "bounty hunters", c'est rigolo, tu peux foutre ça dans ta signature, ça amusera tout le monde. Et plus c'est ludique, plus tu peux être certain d'avoir de gens intéressés.

Il y a un sujet créé dans la dev-zone a chaque mise en pré-prod. C'est probablement suffisant. En effet tes idées peuvent être bonnes pour attirer plus de monde, à creuser.

Le soucis de la dev zone c'est que tout le monde s'en fou : c'est le cambouis et seuls ceux qui touchent au code s'y penchent ou occasionnellement des curieux. Mais les release c'est en gros toutes les 2 semaines qu'il faut les tester. Donc il faut mettre ça en avant.

+1 pour une bannière sur l'accueil pour membres connectés uniquement pour signifier que l'on a besoin de testeurs.

Je ne dis pas le contraire, je disais que le sujet où envoyer quelqu'un est toujours dispo.

Bon donc ça suppose de faire un peu de dev front (styliser une bannière) et back (permettre a un admin de les activer ou désactiver et de spécifier le message à afficher). Ça ne me parai pas énorme, suffit qu'un dev de chaque coté soit volontaire.

Bon donc ça suppose de faire un peu de dev front (styliser une bannière)

Ça peut même être la bannière des cookies.

Indeed mais il faut dès lors prévoir que les deux puissent être actifs en même temps.

Si ça ne concerne que les membres authentifiés tu n'auras pas les deux en même temps, si ?

Indeed mais il faut dès lors prévoir que les deux puissent être actifs en même temps.

Impossible. Si tu es connecté, tu es au moins sur la deuxième page (login + accueil) et donc le message est masqué.

Toutefois, je pense qu'il ne faut pas utiliser cette bannière à cet effet. Pour moi, ça doit être visible dans le contenu et non au dessus du header, simplement parce que sur mobile la bannière des cookies prend tout l'écran : ça n'est pas adapté.

Il ne faut pas vouloir trop réutiliser les choses, ça n'est pas toujours adapté.

Je suis d'accord, ce sont deux messages de nature assez différentes (alerte CNIL, légale, concernant l'utilisateur et ses données, vs. alerte sur la vie du site == effet d'annonce), il vaudrait mieux les présenter différemment. (ne serait-ce que pour un utilisateur peu regardant ne ferme le bandeau d'annonce parce qu'il pense que c'est celui de la CNIL).

Je vais réfléchir au système de "chasseurs de bugs". Ça peut être rigolo.

Je vous propose d'organiser une soirée "cassons la préprod" lors de la release de la v1.3 pour que nous puissions saquer sur la QA à ce moment et de manière efficace.

Je vais faire mon Cassandre : qui a le temps d'organiser sérieusement ce dont vous parlez ?

Parce que c'est beau la théorie. Mais ce que je vois, c'est que personne n'a pris ne serait-ce que 10 minutes pour aller tester cette préprod. Et ce que vous proposez là nécessite une préparation et un suivi qui sont vraiment loin d'être neutres.

Alors en théorie oui, c'est une bonne idée. En pratique, il va falloir trouver du monde pour organiser ça…

Je vais redire ici, ce dont j'ai discuté avec Eskimon sur IRC.

Ce que je pense, c'est qu'il faudrait amener plus de personne sur cette préprod' pour la permettre de tester de fonte en comble. Et comment faire cela ? Nous sommes un site open-source, et nous essayons à chaque fois de faire le maximum pour que la communauté participe, tant au-niveau de contenu, que développement, en tentant dans chacune des phases, de la faire rentrée. Donc, pourquoi ne pas le faire ici ? Je pense donc, qu'il faudrait créer un sujet et le mettre en post-it dans le forum B&S, pour faire un grand appel, un peu avant la mise en préprod' d'une nouvelle version, et le remonter avant ces dernières. Et de soit, communiquer les accès aux membres qui se sont manifesté, soit de dégager pendant une durée de 1 ou 2 jours le htaccess pour permettre à tout le monde d'y aller et donc espérer avoir un maximum de retours.

Après il faut aussi essayer de centraliser derrière les retours que nous pourrions avoir.

Je conçois que mon idée, peut paraître très brouillon et peut-être irréalisable, mais vu que j'en ai parlé sur IRC, je me suis que ça serait pas mal de la remettre aussi ici.

Il y a bien assez de monde pour tester les choses. Même si les gens ne savent pas décrire un bug, s'ils sont tous sur IRC en même temps que quelques devs, à chaque bug le dev peut prendre le temps de comprendre comment la personne est arrivée à produire le bug et créer un ticket plus détaillé que la plupart des tickets faits à l'arrache actuellement.

Pourquoi c'est réalisable ? Parce qu'on gagnerait beaucoup de temps et qu'il y a du monde qui voudrait participer mais qui ne sait pas trop comment car pas l'expérience/compétence pour taper directement dans la technique pure.

Je répète l'idée qu'une bannière sur l'accueil qui amènerait sur le sujet lié serait suffisant pour mettre en valeur la chose.