Organisation Tickets et rapports d'erreurs - TecostNetwork/Network GitHub Wiki

Routine journalière

Il faut chaque jour aller vérifier s'il y a des tickets ou des rapports d'erreurs.

Si des tickets/rapports vous concernent :

Finissez ce que vous êtes entrain de faire, pas la peine de tout lâcher.
Corrigez les tickets/rapports les plus urgents en premier.
Corrigez les tickets/rapports moins urgents pour qu'on ne les accumule pas non plus.

Conseil : utilisez un workspace dédié pour les corrections (ou 2 si nécessaire) :

Vous pourrez restaurer un dump du client sans perdre votre base de dev.
Vous pourrez commiter les corrections rapidement sans attendre sur votre dev.
Vous n'aurez pas d'interférences entre les tests unitaires qui plantent à cause du dev ou de la correction.
Votre commit sera plus petit et vous serez plus serein en le faisant.

Télécharger un Dump

Pour reproduire un problème, il faut souvent reprendre la base de données du client.

Allez dans le menu de debug, sous Dump base de données.
Téléchargez le dump.
Restaurez-le chez vous avec NukeRestoreAndUpdateAnonymizedDump.java

Tickets

Les tickets sont écrits par nos clients lorsqu'ils rencontrent des bugs de comportement ou d'affichage inadéquats. Ils se trouvent dans l'ERP sous Produits > Gestion des tickets.

Les status des tickets sont :

Soumis : le ticket a été créé par le client et on y a pas encore touché.
Assigné ou en cours : lorsqu'on travaille dessus.
En attente du client : si le ticket nécessite des précisions de la part du client. Posez vos questions directement dans le champ "Remarque/Réponse au client".
Rejeté : si le problème est un faux positif ou une demande abracadabrante. Indiquez la raison dans le champ "Remarque/Réponse au client".
Terminé : lorsque le problème est corrigé et la correction commitée. N'oubliez pas de cocher "(Network) head" et de vérifier que le no de version est bien le suivant.
Validé : lorsque le client a validé la correction du problème. Le ticket est considéré comme fait et on peut l'oublier.
Validation refusée : lorsque le client a re-testé mais continue à rencontrer le problème.

Pour les tickets soumis :

Si un ticket vous concerne, attribuez-le à vous et réglez-le dans un délai de 4 jours. Si vous n'arrivez pas à régler le ticket car vous êtes pris par d'autres trucs urgents, on en parle et on trouve quelqu'un d'autre.

Si la "plainte" du client semble injustifiée :

Le client aimerait une amélioration : refuser le ticket en indiquant qu'il s'agirait plutôt d'une amélioration et qu'il faut en parler avec Alexandre.
Le client n'a pas configuré ou utilisé la fonctionnalité correctement : refuser le ticket en indiquant comment il peut arriver à ses fins.
Le client n'a pas donné de détails suffisants pour comprendre le problème et le situer : mettre le ticket au statut "En attente du client"

Pour résoudre un ticket :

S'attribuer le ticket et le mettre au statut "En cours".
Reproduire le bug chez soi (si nécessaire aller chercher un dump).
Régler le problème.
Faire un test anti-régressif si applicable (dans la plupart des cas).
Commiter les corrections.
Passer au statut "Terminé" en indiquant la prochaine version (la dernière).

Quand le client répond à votre "En attente du client" :

Changez son statut à "En cours" quand vous re-travaillez dessus.
Puis traitez-le selon le cas (peut-être qu'il sera refusé, peut-être corrigé si le problème est réel).

Si le client invalide une correction (statut "Validation refusée") :

Cliquez sur le bouton loupe "Validations" et regardez ses remarques, en principe il indiquera d'autres détails.
Si vous constatez que le problème persiste également, remettez-le à "En cours" quand vous re-travaillez dessus.
Si le problème est bien résolu chez vous, vérifiez le no de version et indiquez en commentaire qu'il faut attendre le prochain déploiement.
Après ça si le problème persiste chez le client mais pas chez nous, on en parle, là c'est bizarre.

Dans tous les cas :

Notez le temps passé sur le ticket dans votre feuille horaire (en faisant référence au ticket).

Rapports d'erreurs

Les rapports d'erreurs sont à traiter directement sur l'instance de test.

Attribuez-vous les rapports qui semblent vous concerner.
Vous pouvez attribuer un rapport à quelqu'un d'autre, prévenez juste, c'est plus sympa.
Une fois le rapport corrigé, marquez-le comme "Corrigé" et indiquez la prochaine version (elle est remplie automatiquement, mais n'est pas à jour juste après déploiement, il faut au moins que quelqu'un la mette une fois. Vérifiez toujours que le no de version indiqué est celui de l'instance + 1).
Les rapports "Régression" indiquent que l'erreur s'est reproduite après correction. Soit l'erreur persiste, soit le no de version indiqué n'était pas bon.
En principe on ne met jamais un ticket sur "Abandon", sauf confirmation de la part d'Alexandre.