Le portail de qualité d’Embarcadero fournit un processus communautaire pour résoudre, clarifier et suivre les problèmes de qualité concernant les produits et services d’Embarcadero. Les clients Embarcadero disposant d’un compte EDN peuvent créer des rapports de bogues et des demandes de fonctionnalités, consulter les rapports d’autres clients, commenter et voter sur les rapports les plus importants pour eux. Le personnel d’Embarcadero participe également à Quality Portal, fournissant un lien permanent entre les clients d’Embarcadero et les équipes qui fabriquent les produits d’Embarcadero.
Les développeurs qui ont un contrat de support et de maintenance actif et qui ont besoin d’une réponse urgente à une requête doivent plutôt créer un ticket de support : un enregistrement de portail de qualité n’est pas la même chose qu’un ticket de support.
Ce guide est là pour vous aider à signaler des problèmes concernant le produit RAD Studio , y compris Delphi et C++Builder . Ce billet de blog met à jour et remplace le billet sur https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/
Table des matières
Utiliser le portail qualité d’Embarcadero
Avant d’utiliser Quality Portal (QP), vous devez créer votre compte utilisateur EDN (EDN signifie Embarcadero Developers Network). Rendez-vous sur https://my.embarcadero.com pour créer votre compte, si vous n’en avez pas déjà un. Il s’agit du même compte que vous pouvez utiliser pour enregistrer un produit Embarcadero.
Avec votre compte, rendez-vous sur https://quality.embarcadero.com/ et connectez-vous à Quality Portal (ou QP).
Processus communautaire
Quality Portal est une application soutenue par les pairs, où les autres membres de la communauté peuvent commenter ou voter sur les rapports existants, ou créer les leurs. Avec Quality Portal, la communauté a un grand impact en aidant Embarcadero à prioriser la demande de nos clients. Vous pouvez « Surveiller » les problèmes des autres utilisateurs, pour être averti lorsqu’ils sont mis à jour.
J’ai déjà mentionné ci-dessus, mais cela vaut la peine de le répéter, qu’Embarcadero propose également un programme de support technique, auquel vous pouvez accéder en ligne à l’ adresse https://www.embarcadero.com/support , comprenant à la fois une assistance à l’installation et à l’enregistrement ainsi qu’un certain nombre de tickets de support technique ( en fonction de votre niveau d’assistance). Si vous souhaitez une attention immédiate pour un problème, veuillez utiliser le support Embarcadero et non le portail de qualité.
Maximiser les avantages de votre Quality Portal
Vous pouvez tirer le meilleur parti de QP en l’utilisant « correctement ». Cette section du guide de l’utilisateur décrit des techniques efficaces pour publier des rapports de bogues, faire des demandes de fonctionnalités et des suggestions, et faire travailler les bogues, les fonctionnalités et les suggestions. Après tout, vous utilisez QP parce que vous voulez qu’Embarcadero traite les problèmes qui vous intéressent. Cette section du guide de l’utilisateur décrit les différentes manières de maximiser votre impact positif avec Quality Portal.
Guide de signalement des bogues
Pour beaucoup de gens, l’intérêt initial pour QP sera les rapports de bogues. Les principes abordés dans cette section traitent à la fois des manières évidentes et subtiles de créer et de traiter efficacement des rapports de bogue.
Vous verrez un formulaire similaire à :
Être spécifique
Rédigez des rapports de bogues efficaces. Soyez aussi complet que possible lorsque vous décrivez le bogue et ce qui se passe. Inclure les étapes. Le moyen le plus efficace de corriger un bogue est de fournir un cas de test reproductible. Si vous ne pouvez pas le reproduire facilement, décrivez aussi complètement que possible ce qui s’est passé avant de voir le bogue. Les rapports de bogue doivent fournir toutes les informations requises en un seul endroit . Si vous avez un cas de test reproductible, mais que vous ne souhaitez pas partager le code sur le système QP public pour quelque raison que ce soit, nous pouvons organiser un processus de soumission direct et plus privé : veuillez l’indiquer dans le rapport lui-même. Notez également que pour certains domaines de produits comme CodeInsight et FireDAC, il existe des étapes spécifiques pour nous fournir des informations de journal, comme expliqué dans la section conseils à la fin de ce billet de blog.
Règle d’or : inclure un seul problème dans chaque rapport.
type de probleme
- Bug : Un problème avec le produit
- Bogue de documentation : un problème avec l’aide ou la documentation du produit.
- Demande de fonctionnalité : une nouvelle fonctionnalité que vous aimeriez voir dans le produit
Notez que les demandes de fonctionnalités suivent un chemin différent : elles sont examinées par les chefs de produit (plutôt que par l’équipe d’assurance qualité) et attribuées aux développeurs pour la recherche ou la mise en œuvre dans une future version.
Parfois, nous convertissons un problème d’un type à un autre, par exemple lorsqu’un rapport de bogue peut vraiment être résolu en ajoutant une fonctionnalité importante au produit ou en cas de dépôt incorrect par le client.
Sommaire
Donnez au rapport un résumé court mais descriptif. « TButton ne fonctionne pas » n’est pas un bon titre, mais « [Android] Une erreur est générée lorsque TButton est invoqué par un double tapotement » est meilleur.
Le cas échéant, utilisez des balises dans le titre pour aider celui qui le lit à mieux comprendre le contexte.
Un bon résumé permet d’identifier rapidement ce qui se passe et aide à réduire les problèmes de doublons. Évitez de décrire des problèmes génériques dans le résumé. Vous ne devez jamais utiliser :
- J’ai un problème avec XYZ
- XYZ ne fonctionne pas correctement
Quelques exemples de mauvais résumés et leurs bons équivalents :
Médiocre : violation d’accès dans l’IDE
Mieux : l’ouverture d’un fichier .pas vide génère une violation d’accès
Médiocre : bogue de notification push
Mieux : le nombre de notifications push ajoute une notification supplémentaire
Composant
Identifiez quelle sous-partie du logiciel est affectée par ce bogue.
- Installer
- FireMonkey
- CVL
- Compilateur C++ (voir Compilateur C++ / bogue de l’éditeur de liens soumettant des conseils)
- RTL C++
- Compilateur Delphi
- Delphi RTL
- Linker (voir C++ Compiler / Linker bug soumettant des conseils)
- Base de données
- Débogueur
- IDE (environnement de développement)
- Aide et Doc
- Démos
La description
Toutes les informations générées par le problème. Le cas échéant, inclure :
- Message d’erreur complet
- Pile d’appels complète
- Si vous pensez que cela est pertinent, incluez des informations sur votre environnement (par exemple, la version d’Android ou les paramètres régionaux de Windows)
- Pour les bogues qui se manifestent visuellement (par exemple, les contrôles ne s’affichent pas correctement ou les problèmes de mise en page de l’IDE), incluez une capture d’écran pour aider quiconque lit votre rapport à l’évaluer.
- Le cas échéant, ajoutez des journaux d’appareils, comme la sortie logcat pour Android.
- Pour les messages d’erreur ou les piles d’appels, utilisez les balises {code} ou {quote}.
- Si vous basez votre rapport sur une source d’informations externe (par exemple, une page MSDN pour un appel d’API), incluez un lien vers ces informations.
- Si votre rapport de bogue contient du code, joignez-le au projet ou ajoutez-le à la section Étapes . Si vous ajoutez du code sous forme de texte à votre rapport, veillez à utiliser les balises {code}. Cela empêche JIRA d’interpréter votre code et de le gâcher et contribue également à la lisibilité du rapport (évite de faire défiler quelques pages pour accéder aux champs pertinents).
- Gardez la taille de la pièce jointe au minimum. Compressez vos fichiers et n’incluez jamais de fichiers binaires générés en les compilant (par exemple, des DCU ou des EXE). Utilisez uniquement le format ZIP, n’utilisez jamais d’autres formats qui nécessitent un programme tiers.
- N’incluez pas plus d’un problème dans un rapport. Rapportez séparément et reliez-vous si nécessaire.
Pas
Le but est de montrer comment reproduire le bug. Soyez concis et facile à lire, vous devriez le décrire comme une recette pour reproduire le bogue. Essayez d’atteindre l’objectif avec le nombre minimum d’étapes.
Remarque : les messages d’erreur ou les piles d’appels sont placés dans la description, pas dans les étapes. Par exemple, la description doit indiquer « L’erreur suivante est générée lors de l’appel de TButton en appuyant deux fois dessus sur mon appareil Android : [message d’erreur] » et les étapes doivent simplement fournir des instructions sur la manière de reproduire le problème.
Résultats attendus et réels
À la fin de votre description étape par étape, vous devez décrire ce que devrait être le résultat attendu et ce qui se passe réellement.
Exemple de mauvaise description :
Attendu : l’application ne plante pas
Réel : Plantages de l’application
Mieux utiliser :
Attendu : l’application affiche le menu XYZ
Réel : l’application génère une violation d’accès (voir la trace de pile jointe)
Isoler les rapports
Soyez consciencieux lorsque vous soumettez des réflexions corollaires en tant que nouveaux rapports, et ne vous contentez pas de les mettre sous forme de commentaires pour un rapport existant. Cela garantira que le problème est suivi et éventuellement traité.
Comprendre les rapports en double
Un rapport « en double » est marqué comme tel par l’équipe d’AQ. Quel rapport est marqué comme « maître » et quel « duplicata » est basé sur quel rapport donne les informations les plus précises et les plus détaillées décrivant le problème abordé par les deux (ou plusieurs) rapports.
Le rapport principal peut changer au fil du temps si quelqu’un d’autre soumet un autre duplicata, mais ce duplicata décrit mieux le problème. « Maître » et « duplicata » n’ont rien à voir avec qui est entré en premier, mais quel rapport couvre le plus précisément le problème.
En règle générale, un problème « dupliqué » a le statut « Résolu », une résolution « Dupliqué » et est lié au problème « maître » avec un lien « doublons ». Vous devez vérifier l’état et regarder les mises à jour du problème « maître ».
Comment interpréter certains des champs dans QP
Étant donné que Quality Portal se synchronise avec les systèmes internes, certains champs ont une signification pour nos processus internes qui peuvent ne pas avoir de signification évidente en dehors de nos processus internes. Les tableaux suivants expliqueront, espérons-le, certaines des valeurs de ces champs synchronisés.
Champ d’état
|
Évaluer
|
La description
|
|---|---|
| Signalé | Nouveau défaut, nécessite l’examen du testeur |
| Ouvert | Défaut ouvert, nécessite une résolution. Le problème reste dans cet état tant qu’il est en cours de traitement en interne. |
| Résolu | Travail effectué et livré dans un produit d’expédition, le journaliste peut vérifier ou résoudre un litige |
| Besoin de commentaires | Nécessite des informations/étapes supplémentaires |
| Fermé | Défaut fermé, aucune action requise |
Un signalement commence par le statut « Signalé ». Lorsqu’un testeur QA Embarcadero le valide dans le système interne de suivi des bogues d’Embarcadero, le statut passe de « Rapporté » à « Ouvert ». Lorsque le travail est terminé avec le rapport et que le correctif fait partie d’un produit publié, le statut passe de « Ouvert » à « Résolu ». Notez qu’un problème est marqué comme résolu uniquement lorsque le correctif est disponible, et non lorsqu’il est implémenté en interne par R&D.
Champ de résolution
|
Évaluer
|
La description
|
|---|---|
| Fixé | Le bogue a été corrigé |
| Ne peut pas reproduire | Le bogue n’a pas pu être reproduit tel que soumis dans la dernière version du produit |
| Fonctionne comme prévu | Le comportement est conforme à la conception ou est un effet de la conception actuelle |
| Dupliquer | Le bogue est un doublon (doit noter le numéro de bogue en double) d’un autre problème, qui pourrait encore être ouvert |
| Erreur de scénario de test | La description du bogue n’est pas valide telle qu’elle a été soumise |
| Besoin de plus d’informations | Besoin de plus d’informations/démo/étapes pour que notre équipe puisse reproduire |
| Ne s’applique plus | La fonctionnalité a été supprimée ou le bogue n’est plus pertinent |
| Ne réparera pas | Il a été décidé que cela ne sera jamais mis en œuvre ou corrigé |
Pour les problèmes renvoyés avec Needs More Info , le statut sera marqué comme ‘ Besoin de commentaires ‘ pour permettre au signaleur d’ajouter des informations supplémentaires. Vous devez utiliser le bouton « Mettre à jour le contenu » lorsque vous soumettez des informations supplémentaires. Une fois que les modifications soumises via le statut « Mettre à jour le contenu » reviennent à « Signalé », l’équipe d’assurance qualité répétera la validation en interne. « Mettre à jour le contenu » peut également être utilisé lorsque des corrections sont apportées à un problème déjà soumis.
Essayez généralement de clarifier la description en ajoutant plus de détails et/ou d’informations contextuelles en utilisant les recommandations données ci-dessus ou ajoutez/révisez les étapes à reproduire. Joindre des captures d’écran et/ou des projets serait également utile. Une vidéo courte et ciblée peut aussi être bonne à comprendre.
Quelques conseils supplémentaires
Pour les problèmes liés au moteur LSP CodeInsight, veuillez vous référer aux informations à la fin de cet article docWiki . Notez que les journaux LSP peuvent contenir des parties importantes du code source en cours d’analyse, donc s’il y a des raisons de le garder réservé, veuillez demander un canal de communication direct plutôt que d’ajouter le fichier journal à un rapport QP public.
De même, si vous signalez des problèmes FireDAC, vous devez fournir des données d’environnement et des journaux de suivi. Les étapes sont décrites dans cet article .
Vous pouvez vous référer aux conseils de mise en forme du texte QP de l’article original sur https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips
Enfin, une bonne source de recommandations pour signaler les bogues est disponible sur http://www.mozilla.org/bugs/bug-reporting.html .