![QPdashboard | Embarcadero RAD Studio Delphi C++Builder Blogs qp dashboard](https://i0.wp.com/blogs.embarcadero.com/wp-content/uploads/2022/07/QP_dashboard-2329252.png?resize=1140%2C694&ssl=1)
O Portal de Qualidade da Embarcadero fornece um processo comunitário para resolver, esclarecer e rastrear problemas de qualidade relacionados aos produtos e serviços da Embarcadero. Os clientes da Embarcadero com uma conta EDN podem criar relatórios de bugs e solicitações de recursos, visualizar relatórios de outros clientes e comentar e votar nos relatórios mais importantes para eles. O pessoal da Embarcadero também participa do Portal da Qualidade, proporcionando um vínculo permanente entre os clientes da Embarcadero e as equipes que produzem os produtos da Embarcadero.
Os desenvolvedores que têm um contrato de suporte e manutenção ativo e precisam de uma resposta urgente em uma consulta devem gerar um tíquete de suporte: um registro do Quality Portal não é o mesmo que um tíquete de suporte.
Este guia está aqui para ajudá-lo a relatar problemas sobre o produto RAD Studio , incluindo Delphi e C++Builder . Esta postagem do blog atualiza e substitui a postagem em https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/
Índice
Usando o Portal da Qualidade da Embarcadero
Antes de usar o Quality Portal (QP), você deve criar sua conta de usuário EDN (EDN significa Embarcadero Developers Network). Acesse https://my.embarcadero.com para criar sua conta, caso ainda não tenha uma. Esta é a mesma conta que você pode usar para registrar um produto Embarcadero.
Com sua conta, acesse https://quality.embarcadero.com/ e faça login no Quality Portal (ou QP).
Processo da comunidade
O Quality Portal é um aplicativo suportado por pares, onde outros membros da comunidade podem comentar ou votar em relatórios existentes ou criar seus próprios. Com o Quality Portal, a comunidade tem um grande impacto em ajudar a Embarcadero a priorizar a solicitação de nossos clientes. Você pode “Assistir” aos problemas de outros usuários para ser notificado quando eles forem atualizados.
Já mencionei acima, mas vale a pena repetir, que a Embarcadero oferece também um programa de suporte técnico, que você pode acessar online em https://www.embarcadero.com/support , incluindo suporte para instalação e registro e vários tickets de suporte técnico ( dependendo do seu nível de suporte). Se você deseja atenção imediata para um problema, use o Suporte da Embarcadero e não o Portal de Qualidade.
Maximizando os benefícios do Portal de Qualidade
Você pode obter o máximo benefício do QP usando-o “corretamente”. Esta seção do guia do usuário descreve técnicas eficazes para postar relatórios de bugs, fazer solicitações e sugestões de recursos e realmente obter os bugs, recursos e sugestões trabalhados. Afinal, você está usando o QP porque deseja que a Embarcadero resolva os problemas com os quais você se importa. Esta seção do guia do usuário descreve as várias maneiras de maximizar seu impacto positivo com o Quality Portal.
Guia de relatórios de bugs
Para muitas pessoas, o interesse inicial no QP serão os relatórios de bugs. Os princípios discutidos nesta seção discutem maneiras óbvias e sutis de criar e processar relatórios de bugs com eficiência.
Você verá um formulário semelhante a:
Seja específico
Escreva relatórios de bugs eficazes. Seja o mais completo possível ao descrever o bug e o que acontece. Incluir etapas. A maneira mais eficiente de corrigir um bug é fornecer um caso de teste reproduzível. Se você não puder reproduzi-lo prontamente, descreva o mais completamente possível o que aconteceu antes de você ver o bug. Os relatórios de bugs devem fornecer todas as informações necessárias em um só lugar . Caso você tenha um caso de teste reproduzível, mas não queira compartilhar o código no sistema público de QP por qualquer motivo, podemos providenciar um processo de envio direto e mais privado: Indique isso no próprio relatório. Observe também que, para algumas áreas de produtos, como CodeInsight e FireDAC, há etapas específicas para nos fornecer informações de log, conforme explicado na seção de dicas no final desta postagem do blog.
Regra de ouro: incluir apenas uma questão em cada relatório.
Tipo de problema
- Bug: um problema com o produto
- Bug de documentação: um problema com a ajuda ou a documentação do produto.
- Solicitação de recurso: um novo recurso que você gostaria de ver no produto
Observe que as solicitações de recursos seguem um caminho diferente: elas são avaliadas pelos gerentes de produto (em vez da equipe de controle de qualidade) e atribuídas aos desenvolvedores para pesquisa ou implementação em uma versão futura.
Ocasionalmente, convertemos um problema de um tipo para outro, por exemplo, quando um relatório de bug pode realmente ser resolvido adicionando um recurso significativo ao produto ou no caso de um preenchimento incorreto por parte do cliente.
Resumo
Dê ao relatório um resumo curto, mas descritivo. “TButton não está funcionando” não é um bom título, mas “[Android] Um erro é gerado quando TButton é invocado por toque duplo” é melhor.
Quando apropriado, use tags no título para ajudar quem lê a entender melhor o contexto.
Um bom resumo ajuda a identificar rapidamente o que está acontecendo e ajuda a reduzir problemas duplicados. Evite descrever problemas genéricos no resumo. Você nunca deve usar:
- Eu tenho um problema com XYZ
- XYZ não funciona corretamente
Alguns exemplos de resumos ruins e seus bons equivalentes:
Ruim: violação de acesso no IDE
Melhor: abrir um arquivo .pas vazio gera uma violação de acesso
Ruim: bug de notificação por push
Melhor: a contagem de notificações push adiciona uma notificação extra
Componente
Identifique qual subparte do software é afetada por esse bug.
- Instalar
- FireMonkey
- VCL
- Compilador C++ (veja dicas de envio de bug do compilador/vinculador C++)
- C++ RTL
- Compilador Delphi
- Delphi RTL
- Linker (veja dicas de envio de bug do compilador C++ / Linker)
- Base de dados
- Depurador
- IDE (Ambiente de Desenvolvimento)
- Ajuda e Documento
- Demonstrações
Descrição
Todas as informações geradas pelo problema. Quando disponível, inclua:
- Mensagem de erro completa
- pilha de chamadas completa
- Se você achar que é relevante, inclua informações sobre seu ambiente (por exemplo, versão do Android ou configurações de localidade do Windows)
- Para bugs que se manifestam visualmente (por exemplo, controles não exibidos corretamente ou problemas de layout do IDE) inclua uma captura de tela para ajudar quem lê seu relatório a avaliá-lo.
- Se relevante, adicione logs do dispositivo, como saída do logcat para Android.
- Para mensagens de erro ou pilhas de chamadas, use as tags {code} ou {quote}.
- Se você basear seu relatório em uma fonte externa de informações (por exemplo, página do MSDN para uma chamada de API), inclua um link para essas informações
- Se o seu relatório de bug contiver código, anexe-o ao projeto ou adicione-o à seção Etapas . Se você adicionar código como texto ao seu relatório, use as tags {code}. Isso impede que o JIRA interprete seu código e estrague tudo e também ajuda na legibilidade do relatório (evita rolar algumas páginas para acessar os campos relevantes).
- Mantenha o tamanho do acessório no mínimo. ZIP seus arquivos e nunca inclua binários que são gerados ao compilá-los (por exemplo, DCU’s ou EXE’s). Use apenas o formato ZIP, nunca use outros formatos que exijam um programa de terceiros.
- Não inclua mais de um problema em um relatório. Relate separadamente e vincule uns aos outros conforme necessário.
Passos
O objetivo é mostrar como reproduzir o bug. Mantenha-o conciso e fácil de ler, você deve descrevê-lo como uma receita para reproduzir o bug. Tente atingir o objetivo com o número mínimo de etapas.
Nota: Mensagens de erro ou pilhas de chamadas vão na Descrição, não nas Etapas. Por exemplo, a descrição deve dizer “O seguinte erro é gerado ao invocar o TButton ao tocar duas vezes nele no meu dispositivo Android: [mensagem de erro]” e as etapas devem fornecer apenas instruções sobre como reproduzir o problema.
Resultados esperados e reais
Ao final de sua descrição passo a passo, você deve descrever qual deve ser o resultado esperado e o que realmente acontece.
Exemplo de uma descrição ruim:
Esperado: o aplicativo não falha
Real: falha do aplicativo
Melhor uso:
Esperado: O aplicativo mostra o menu XYZ
Real: o aplicativo gera uma violação de acesso (consulte o rastreamento de pilha anexado)
Isolar relatórios
Seja consciente ao enviar pensamentos corolários como novos relatórios, não apenas colocá-los como comentários para um relatório existente. Isso garantirá que o problema seja rastreado e, eventualmente, trabalhado.
Noções básicas sobre relatórios duplicados
Um relatório “duplicado” é marcado como tal pela equipe de controle de qualidade. Qual relatório é marcado como “mestre” e qual “duplicado” é baseado em qual relatório fornece as informações mais precisas e detalhadas que descrevem o problema que ambos (ou muitos) relatórios discutem.
O relatório mestre pode mudar com o tempo se outra pessoa enviar outra duplicata, mas essa duplicata na verdade descreve melhor o problema. “Mestre” e “duplicado” não têm nada a ver com quem entrou primeiro, mas qual relatório cobre o problema com mais precisão.
Normalmente, um problema “duplicado” tem o status “Resolvido”, uma resolução “Duplicado” e está vinculado ao problema “mestre” com um link “duplicados”. Você deve verificar o status e acompanhar as atualizações do problema “mestre”.
Como interpretar alguns dos campos no QP
Como o Quality Portal é sincronizado com os sistemas internos, existem alguns campos que têm significado para nossos processos internos que podem não ter significado óbvio fora de nossos processos internos. Espera-se que as tabelas a seguir expliquem alguns dos valores para esses campos sincronizados.
Campo de status
Valor
|
Descrição
|
---|---|
Relatado | Novo defeito, requer revisão do testador |
Abrir | Defeito aberto, requer resolução. O problema permanece nesse status enquanto está sendo trabalhado internamente. |
Resolvido | Trabalho feito e entregue em um produto de envio, o relator pode verificar ou resolver disputas |
Precisa de feedback | Requer informações/etapas adicionais |
Fechadas | Defeito fechado, nenhuma ação necessária |
Um relatório começa com um status de “Relatado”. Quando um testador de controle de qualidade da Embarcadero o valida no sistema interno de rastreamento de bugs da Embarcadero, o status passa de “Reportado” para “Aberto”. Quando o trabalho é concluído com o relatório e a correção faz parte de um produto lançado, o status passa de “Aberto” para “Resolvido”. Observe que um problema é marcado como resolvido apenas quando a correção está disponível, não quando é implementada internamente por P&D.
Campo de resolução
Valor
|
Descrição
|
---|---|
Fixo | Bug foi corrigido |
Não pode se reproduzir | O bug não pôde ser reproduzido conforme enviado na versão mais recente do produto |
Funciona como o esperado | O comportamento é conforme projetado ou é um efeito do projeto atual |
Duplicado | O bug é uma duplicata (deve observar o bug duplicado #) de outro problema, que ainda pode estar em aberto |
Erro de caso de teste | A descrição do bug é inválida conforme enviada |
Precisa de mais informações | Precisa de mais informações/demonstração/etapas para nossa equipe reproduzir |
Não se aplica mais | O recurso foi removido ou o bug não é mais relevante |
Não vai corrigir | Houve uma decisão de que isso nunca será implementado ou corrigido |
Para problemas retornados com Precisa de mais informações , o status será marcado como ‘ Precisa de feedback ‘ para permitir que o relator adicione informações adicionais. Você deve usar o botão “ Atualizar conteúdo ” ao enviar informações adicionais. Depois que as alterações enviadas por meio do status ‘Atualizar conteúdo’ voltarem para ‘Relatado’, a equipe de controle de qualidade repetirá a validação internamente. “ Atualizar conteúdo” também pode ser usado quando são feitas correções em um problema já enviado.
Geralmente, tente esclarecer a descrição adicionando mais detalhes e/ou informações de contexto usando as recomendações fornecidas acima ou adicione/reveja as etapas para reproduzir. Anexar capturas de tela e/ou projetos também seria útil. Um vídeo curto e focado também pode ser bom de entender.
Mais algumas dicas
Para problemas relacionados ao mecanismo CodeInsight LSP, consulte as informações no final deste artigo docWiki . Observe que os logs do LSP podem conter partes significativas do código-fonte que está sendo analisado, portanto, se houver motivos para mantê-lo reservado, solicite um canal de comunicação direto em vez de adicionar o arquivo de log a um relatório QP público.
Da mesma forma, se você estiver relatando problemas do FireDAC, deverá fornecer dados do ambiente e logs de rastreamento. As etapas são abordadas neste artigo .
Você pode consultar as dicas de formatação de texto QP do artigo original em https://blogs.embarcadero.com/rad-studio-quality-portal-user-guide/#Hints_and_Tips
Finalmente, uma boa fonte de recomendações para relatar bugs está disponível em http://www.mozilla.org/bugs/bug-reporting.html .
Design. Code. Compile. Deploy.
Start Free Trial Upgrade Today
Free Delphi Community Edition Free C++Builder Community Edition