Le ticketing est un processus essentiel dans la gestion des incidents, des demandes de service et des problèmes que se soit entre les clients et nous ou entre l'assistance et les développeurs

Un élément du ticketing
Créer un ticket est crucial pour assurer une résolution rapide et précise d'un problème.
Voici les éléments clés à inclure dans un ticket :

• Titre clair et précis : Indiquez le problème en quelques mots.
• Description détaillée : Décrivez le bug, en précisant ce qui s'est passé et le comportement attendu
• Étapes de reproduction : Fournissez les étapes précises pour reproduire le problème
• Environnement du système : Mentionnez les informations sur le système (OS, navigateur, version de l’application) pour mieux identifier le contexte
• Résultats observés et attendus : Décrivez le résultat obtenu et ce que vous attendiez pour clarifier le problème
• Capture d'écran/vidéo : Ajoutez des captures d’écran ou une vidéo pour illustrer le problème si nécessaire
• Urgence : Évaluez la priorité du problème selon son impact

Faire un ticket par sujet, jamais deux problèmes dans le même

Nos outils de ticketing propose trois niveaux d'urgence Pour classer un bug dans l'une de ces catégories, vous pouvez utiliser les critères suivants :

• Impact sur les utilisateurs : Combien d'utilisateurs sont affectés et à quel point leur expérience est-elle perturbée ?
• Criticité de la fonctionnalité : La fonctionnalité affectée est-elle essentielle ou secondaire ?
• Fréquence : À quelle fréquence le bug se produit-il ?
• Conséquences : Quelles sont les conséquences potentielles si le bug n'est pas résolu rapidement ?

Description : Les bugs classés comme non urgents sont ceux qui n'ont pas d'impact immédiat sur les utilisateurs ou le fonctionnement du système. Ils peuvent être des problèmes mineurs ou des améliorations cosmétiques, voir des demandes d'évolutions.

Exemples :

• problèmes d'interface utilisateur mineurs (par exemple, un bouton légèrement mal aligné).
• Fonctionnalités secondaires qui ne fonctionnent pas parfaitement mais n'affectent pas l'utilisation principale du logiciel.
  

Traitement : Ces bugs peuvent être traités lorsque les développeurs ont du temps disponible, après avoir résolu les bugs plus critiques.

Description : Les bugs urgents sont ceux qui ont un impact significatif sur les utilisateurs ou le système, mais ne rendent pas le logiciel complètement inutilisable. Ils nécessitent une attention rapide mais pas immédiate.
Exemples :
* Fonctionnalités principales qui ne fonctionnent pas correctement.
* Problèmes de performance qui ralentissent considérablement l'application.
* Erreurs qui affectent une partie importante des utilisateurs.
Traitement : Ces bugs doivent être traités rapidement, mais peuvent être mis en attente si des bugs bloquants nécessitent une attention immédiate.

*Description : Les bugs bloquants sont ceux qui rendent le logiciel inutilisable ou empêchent les utilisateurs d'accomplir des tâches critiques. Ils nécessitent une attention immédiate et doivent être résolus en priorité.
Exemples :
* Le logiciel ne démarre pas.
* Les utilisateurs ne peuvent pas se connecter.
* Fonctionnalités essentielles qui ne fonctionnent pas du tout.
Traitement : Ces bugs doivent être traités immédiatement. Toutes les autres tâches peuvent être mises en attente jusqu'à ce que le problème soit résolu. ===== Réflexion sur les délais de mise en ligne d'une version en fonction de la gravité du ticket ===== Les délais de mise en ligne d'une nouvelle version d'un logiciel peuvent varier en fonction de plusieurs facteurs, notamment la gravité du ticket, la complexité de la correction, les ressources disponibles, et les processus de validation et de test. Voici une estimation générale des délais en fonction de la gravité du ticket : * Bug Bloquant : La correction doit être effectuée immédiatement, souvent dans les heures suivant la détection du problème. La nouvelle version peut être mise en ligne dans les 24 à 48 heures, après des tests rapides mais rigoureux pour s'assurer que la correction ne introduit pas de nouveaux problèmes. * Bug Urgent : La correction doit être effectuée dans les jours suivant la détection du problème, généralement dans les semaines à suivre. La nouvelle version peut être mise en ligne en suivant, après des tests approfondis pour s'assurer de la stabilité de la correction. * Bug Non Urgent ou évolution : La correction doit être planifiée pour une prochaine version ou mise à jour régulière du logiciel.
Facteurs Influents : * Complexité de la correction : Les bugs complexes peuvent nécessiter plus de temps pour être corrigés et testés. * Ressources disponibles : La disponibilité des développeurs et des testeurs peut influencer les délais. * Processus de validation** : Les processus de validation et de test, y compris les tests unitaires, les tests d'intégration et les tests de régression, peuvent ajouter du temps au déploiement.

En résumé, les délais de mise en ligne d'une nouvelle version dépendent fortement de la gravité du bug, de la complexité de la correction, et des ressources disponibles. Une communication claire et une planification rigoureuse sont essentielles pour gérer efficacement ces délais.