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/

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

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

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 .

---

Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Start Free Trial   Upgrade Today

   Free Delphi Community Edition   Free C++Builder Community Edition

---