QA/Triagem de bugs

TDF LibreOffice Brasil Document Liberation Project Community Blogs Traduções Nextcloud Redmine Perguntas e respostas Doar

• Início
• Desenvolvimento
• Design
• Controle de Qualidade (QA)
• Events
• Documentação
• Website
• Localização
• Accessibility
• Marketing
• Diversity
• Wiki Help

• Relatório de Bugs
• Triagem de Bugs
• Projects
• Regression Test
• Automated Tests
• Bibisect
• QA Meetings
• QA FAQs

Introdução

Este documento fornece informações sobre como fazer a triagem de bugs para o LibreOffice. Triaging é o nome dado para confirmar, priorizar e organizar relatórios de bugs e é um bom lugar para novos colaboradores e/ou colaboradores com habilidades de programação limitadas para ajudar o LibreOffice a se tornar um produto melhor para todos. A triagem é um aspecto incrivelmente importante do desenvolvimento que beneficia usuários e desenvolvedores.

Onde encontrar outros membros de Controle de Qualidade

Existem alguns lugares onde você pode encontrar/contatar membros da equipe de controle de qualidade, muitos dos quais podem ajudar com perguntas de triagem e estão fazendo a triagem de si mesmos ativamente.

1. Listas de email
   • libreoffice-qa@lists.freedesktop.org
   • libreoffice@lists.freedesktop.org
2. Canais IRC no Libera Chat
   • #libreoffice-qa ^IRC://
   • #libreoffice-dev ^IRC://
3. Membros de Controle de Qualidade
   Aqui está uma lista de membros de Controle de Qualidade (sinta-se à vontade para adicionar seu próprio nome se você pretende contribuir para o QA). Se o usuário lhe deu permissão para contatá-lo diretamente, sinta-se à vontade para fazê-lo. Além disso, você os encontrará nas salas de bate-papo com certa frequência.
   • Lista de membros do Controle de Qualidade

Passos para Triagem de um Bug

Esta seção lista as etapas necessárias para fazer a triagem corretamente. Este guia tem como objetivo ser conciso, links em algumas seções fornecerão mais informações relevantes para a etapa específica. O processo de triagem pode ser essencialmente dividido em três partes, sendo a primeira a "preparação", a segunda a "reprodução" e a terceira a "priorização".

Resumo das Etapas

1. Encontre Bugs para Triagem
2. Relatórios de bugs pré-filtro
3. Procure por Bug(s) duplicados
4. Verifique as informações fornecidas no relatório de bug

1. Tentativa de reproduzir o bug
2. Definir status de bug
3. Priorizar Bug
4. Notificar desenvolvedores -- Necessário apenas em casos muito específicos se o bug parecer crítico.

Detalhes das Etapas

Preparação

Em geral, você sempre desejará executar as etapas a seguir na preparação para a triagem de bugs. Lembre-se de que você pode trabalhar em bugs somente quando estiver logado (por favor criar uma conta se você ainda não tiver uma). E uma vez que você tenha uma conta, é bom ir para suas preferências e definir 'Automatically add me to the CC list of bugs I change' para 'Only if I have no role on them' se você quiser ser notificado sempre que alguém responder em qualquer um dos relatórios de bug que você comentou.

Etapa 1: Encontre bugs para triagem

a) Bugzilla Search

Navegue até o sistema de rastreamento de bugs do LibreOffice disponível em bugs.documentfoundation.org. Após o login, browse abra problemas por componente ou faça uma pesquisa personalizada por bugs que são:

a) Arquivado em LibreOffice product

b) possuem status UNCONFIRMED ou REOPENED

c) Adicione quaisquer outros critérios que você gostaria de consultar

Quando estiver lá, procure um bug que você gostaria de fazer a triagem. A pesquisa personalizada de bugs pode ser criada usando o Formulário de pesquisa avançada ou inserindo termos de pesquisa no campo Pesquisa rápida (Ajuda de pesquisa rápida do Bugzilla). Você também pode usar o seguindo links diretos para pesquisar. Clicar no link abrirá a página de resultados do Bugzilla:

• Bugs reportados nas duas 2 semanas anteriores
• Bugs reportados no mês passado
• Todos os Bugs que precisam de triagem. (Limitado a 500 bugs, a lista completa levará algum tempo para carregar, pois é uma lista bastante longa - você pode ajudar a mudar isso!)
• Todos os bugs do macOS que precisam de confirmação

Etapa 2: Pré-filtrar relatórios de bugs

Alguns bugs precisam de atenção especial por equipes específicas:

Melhorias no UX

Quaisquer bugs que cobrem melhorias na UI/UX do LibreOffice devem ser entregues à equipe de UX

1. Adiciona a palavra-chave 'needsUXEval'
2. Adicione isto à Lista CC: libreoffice-ux-adviselists.freedesktop.org
3. Atualizar o Status

1. • Se a solicitação parecer completa e plausível, Status -> NEW
   • Se a solicitação parecer incompleta ou precisar de explicação, Status -> NEEDINFO
2. Deixe um comentário ao longo das linhas:

 Equipe de UX – dê uma olhada neste aprimoramento. Obrigado!

Alguns bugs não pertencem ao Bugzilla. Para uma lista de tópicos que pertencem a outro lugar, veja Página do BugReport.

• Se um desses bugs estiver registrado no Bugzilla, altere o Status para RESOLVED NOTOURBUG e adicione o seguinte em um comentário:

Obrigado por entrar em contato conosco!
 Embora o Bugzilla às vezes pareça o centro da
 Universo, existem alguns tópicos que precisam ser
 relatado em outro lugar. Para encontrar o lugar certo para denunciar
 seu problema, consulte a página wiki BugReport:
  https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Etapa 3: Procure por duplicatas

Duplicatas são relatórios muito semelhantes ou idênticos, mas relatados por usuários diferentes. Normalmente, você deseja manter o status NEW para o relatório com as informações mais valiosas e fechar os outros como RESOLVED DUPLICATE. Portanto, mesmo que exista um relatório mais antigo, não há necessidade de mantê-lo aberto, se contiver informações confusas ou incompletas. Duplicatas fechadas são contadas automaticamente pelo Bugzilla e estão disponíveis na página Bugs mais frequentemente reportados. Ao fazer a triagem, verifique essa lista e faça uma rápida pesquisar relatórios no Bugzilla para ver se há duplicatas do relatório que você está examinando. Você não precisa gastar uma vida inteira nisso. À medida que você vê mais relatórios, pode começar a identificar duplicatas sem precisar usar a pesquisa.

Se você encontrar um bug duplicado, pule para o passo #5

Etapa 4: Verifique as informações

A verificação de informações é fundamental para o desenvolvimento. O que você deve procurar é o seguinte:

1. Resumo claro e significativo
2. Limpar descrição do problema
3. Etapas para reproduzir o problema - se não estiver claro no resumo e/ou descrição
4. Anexos -- em muitos casos, os anexos são necessários para reproduzir o problema, se os anexos não forem fornecidos, isso pode dificultar as correções adequadas
5. Se o relatório se referir a dados externos (capturas de tela, documentos, screencasts, etc.), copie e anexe-os ao bug, para que eles não desapareçam posteriormente e eventualmente o tornem irreprodutível.

Se todas as informações não estiverem lá corretamente, pule para o passo #5

Etapa 5: Tentativa de Reprodução

Se o bug "passou" nas etapas de Preparação, é hora de tentar reproduzir o bug.

Faça exatamente isso: siga os passos necessários e tente reproduzir o bug, simples assim! Ao reproduzi-lo, lembre-se do seguinte:

1. O relator do bug deixou informações suficientes no próprio Bugzilla para reproduzir o bug, ou você teve que tomar medidas extras? Se etapas extras forem necessárias, adicione um comentário para descrever as etapas extras.
2. Sua reprodução levou ao mesmo resultado, algo semelhante, mas não idêntico, ou tudo funcionou perfeitamente?

Etapa 6: Definir Status

Esta seção é a última etapa "obrigatória" de uma triagem bem-sucedida e só pode ser realizada quando as etapas #1–#4 forem concluídas (ou #3 se a #4 não for aplicável).

O STATUS do bug depende dos resultados das etapas acima. Abaixo está uma breve descrição do uso de cada status.

1. NEW: Bug confirmado, todas as informações necessárias estão lá
2. NEEDINFO: Todas as informações necessárias para tentar a replicação não estão incluídas no relatório do bug. Por favor, peça a uma pessoa em particular uma informação específica em um comentário.
3. RESOLVED: Esta categoria vem com várias opções, se você não pode replicar o bug, RESOLVED WORKSFORME é o STATUS apropriado, veja AQUI para mais informações.
4. VERIFIED: Esta opção só está disponível quando o status atual do bug é RESOLVED. Você pode marcar um bug RESOLVED FIXED como VERIFIED, quando você pode confirmar que ele foi corrigido com a versão mencionada no relatório do bug. Também é agradável para o desenvolvedor que corrigiu o problema e é uma confirmação de que o problema está resolvido agora. Caso contrário, um relator de bug pode marcar seu próprio bug que está no estado RESOLVED WORKSFORME como VERIFIED WORKSFORME para verificar se foi corrigido de alguma forma.
5. INVALID: Há muitas razões pelas quais um bug pode ser determinado como inválido, mas isso geralmente requer a entrada de outros membros do controle de qualidade. Se você encontrar um bug que acredita ser inválido, a melhor opção é obter uma segunda opinião do canal QA IRC ou enviar um e-mail para a lista de discussão explicando por que você acredita que o bug é inválido.
6. UNCONFIRMED: Este é o status dado a todos os novos bugs que não passaram pelo processo de triagem. Observe que esse bug também pode estar no estado NEEDINFO.

Toda vez que você fizer alterações, você deve colocar um comentário que explique educadamente por que você fez a alteração

Os fluxogramas abaixo são exemplos de como pensar visualmente na configuração de STATUS. Sinta-se à vontade para editar e fazer upload de sua própria versão, se desejar.
Arquivo PDF
Arquivo do LibreOffice Draw

Etapa 7: Testes de regressão

Use versões mais antigas do LibreOffice para descobrir se o bug foi introduzido desde o início do LibreOffice.

Baixe e instale várias versões antigas, sendo a mais antiga LibreOffice 3.3. No mínimo você deve ter uma versão de todas as principais de cada lançamento (3.x, 4.x, 5.x, 6.x...).

Você precisa ter algum conhecimento de quando os recursos foram introduzidos no software para evitar obter resultados de teste irrelevantes. Por favor, consulte outros membros da equipe, se você não tiver certeza de algo.

• Se o bug estiver presente na versão 3.3.0, defina a versão como "inherited from OOo" e adicione o seguinte comentário:

Este bug já está presente no Libreoffice 3.3.0

 Alterando a versão para "inherited from OOo"

• Se o bug não estiver presente na versão 3.3.0 adicione "regression" ao campo palavras-chave e adicione o seguinte comentário:

Este bug não está presente no Libreoffice 3.3.0, portanto é uma regressão

Para regressões anteriores à versão 3.5.0, adicione também a palavra-chave preBibisect. Para regressões mais recentes, adicione a palavra-chave bibisectRequest e atualize o campo de versão para corresponder à versão problemática mais antiga conhecida.

• SI-GUI - Aplicativo IGU (Interface Gráfica do Usuário) simples para instalação paralela no Windows e Android
• Instalação em Paralelo - Instruções sobre como instalar manualmente em paralelo no Windows, Linux e Mac.
• https://downloadarchive.documentfoundation.org/libreoffice/old/ - Baixe versões antigas, betas e alfas

Etapa 8: Priorize o Bug

Atualmente, destacamos apenas bugs críticos por desenvolvedores CC-ing e adicionando palavras-chave. Consulte abaixo para obter mais informações.

Priorizar um bug é relativamente subjetivo, mas o triador deve sempre tentar ser consistente com a forma como eles determinam a priorização de um bug. A triagem dos membros da equipe de controle de qualidade deve ter uma ideia clara do que constitui cada estado prioritário e, em seguida, tentar manter essa metodologia. Além disso, comentar o bug após a priorização é útil, pois permite que o relator do bug (assim como os desenvolvedores e outros usuários) saiba qual processo de pensamento você usou para chegar ao status de prioridade.

Para priorizar bugs acima do normal, você precisa ser adicionado ao grupo de contribuidores no Bugzilla. Para fazer isso, entre em contato com um dos Administradores do Bugzilla.

O fluxograma abaixo mostra diretrizes aproximadas sobre como lidar com a priorização.

Exemplo 1 JPG

Exemplo 1 Draw

Geralmente é mais fácil determinar a gravidade de um problema do que tentar pensar em uma prioridade adequada.

Pequenos ajustes estéticos na interface do usuário podem ser considerados de baixa prioridade e gravidade trivial.

Problemas que o deixam com raiva, mas que você pode tolerar ou contornar de alguma forma, podem ser definidos para uma gravidade menor.

Bugs que quebram alguma funcionalidade e não têm uma solução alternativa são de gravidade normal.

Falhas, travamentos e congelamentos resultantes de um arquivo ou comando específico são de gravidade maior.

Passos Úteis Adicionais (Opcional)

Atalhos

O campo Keywords contém palavras-chave relacionadas à categorização deste bug.

Algumas categorias de palavras-chave incluem:

• Funcionalidade quebrada em áreas específicas: Por exemplo, filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
• Pediu ou forneceu informações de depuração: Por exemplo, bibisectRequest, bibisected
• Hacks fáceis: easyHack, difficultyBeginner, skillCPP

Uma palavra-chave interessante é needsDevEval. Um easyHack é um bug que provavelmente não levará muito tempo para ser corrigido e pode ser feito por um novo desenvolvedor e/ou um desenvolvedor sem muitos conhecimentos de programação. Como QA, NÃO devemos marcar um bug como easyHack, pois requer várias etapas adicionais (incluindo encontrar um desenvolvedor para orientar o bug). Se você acha que um bug se qualifica como easyhack, marque como needsDevEval.

Relatórios de falhas

Ter um relatório de falha (também conhecido como backtrace) para um bug torna mais fácil para um desenvolvedor identificar o que está causando a falha. Se um relatório de travamento for adicionado a um relatório de bug, a palavra-chave havebacktrace deve ser adicionada ao campo Palavras-chave.

• Informações de depuração
• Como obter um backtrace com WinDbg

Meta relatórios

Veja nossos meta relatórios existentes que coletam relatórios do mesmo gênero. Se você encontrar um bom ajuste, adicione o número do meta-relatório ao campo Blocos do relatório que está fazendo a triagem.

Tags de comentários

As tags de comentário atuam como notas que ajudam todos a obter uma visão geral rápida do histórico de comentários e valor/relevância de comentários individuais. Clique no texto da tag no cabeçalho de um comentário, insira sua tag e pressione Enter. Não há necessidade de salvar o relatório. Você pode inventar novas tags ou usar tags existentes. O campo de entrada da tag oferece suporte ao preenchimento automático.

A inclusão de uma dessas tags torna o comentário oculto por padrão: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. Você pode mostrar um comentário oculto clicando no widget "Alternar exibição de comentário" no cabeçalho do comentário. Você também pode ocultar comentários regulares e mostrar comentários marcados clicando no nome da tag de sua escolha na lista "Tags de comentário" ao lado da descrição do bug (comentário 0). Clique em Expandir todos os comentários para mostrar tudo.

Verificando informações adicionais

Como triagem, devemos tentar verificar as informações que foram originalmente relatadas pelo relator do bug. Coisas para verificar incluem:

• Produtos
• Versão
• Plataforma

Adicionando Desenvolvedor à Lista CC

Esta etapa só deve ser realizada se você tiver certeza de que é importante o suficiente para colocar um desenvolvedor em CC. Se você acha que um bug é sério o suficiente para merecer atenção extra, mas talvez não pertença à categoria de Bugs mais irritantes, então você deve procurar um especialista para informações adicionais. Tente usar isso com cuidado, pois não queremos inundar nossos desenvolvedores especializados com pings de bugs menores. Para adicionar o usuário basta adicionar seu nome à lista de CC e colocar um comentário sobre o bug dizendo aos desenvolvedores porque você os adicionou à CC De qualquer forma, os nomes corretos podem ser encontrados na lista de especialistas.

Adicionando controle de qualidade à lista CC

Isso geralmente não é usado, mas se você sentir que adicionar a si mesmo ou a outro membro do controle de qualidade à lista pode ser útil, sinta-se à vontade para fazê-lo. Novamente, certifique-se de adicionar um comentário se estiver adicionando outra pessoa à lista, caso contrário, eles podem ficar irritados por não saber o que está acontecendo.

Teste de interoperabilidade

Se o requisito para o teste for abrir ou salvar um arquivo com o Microsoft Office e você não tiver acesso ao software, poderá usar /2013/04/10/office-web-viewer-view-office-documents-in-a-browser/ Office Web Viewer. Funciona com documentos Word, Excel, PowerPoint e ODF. Você precisa fazer o upload do documento em algum lugar e adicionar a URL ao final deste link:

https://view.officeapps.live.com/op/view.aspx?src=

Você pode clicar no botão Imprimir no menu superior e, finalmente, Abrir PDF para obter acesso a uma renderização em PDF do documento. Isso permitirá que você veja como o documento se parece na versão mais recente do Microsoft Office e compartilhe o PDF no Bugzilla.

Os links de anexo do Bugzilla funcionam com o visualizador.

Para usar convenientemente o visualizador ao vivo no Firefox

• Adicionar um novo marcador
• Defina algum Nome
• Defina o URL para:

https://view.officeapps.live.com/op/view.aspx?src=%s

Defina uma Palavra-chave, como lv, pressione OK. Agora você pode usar a palavra-chave de marcadores mais um URL de bugdoc na barra de endereços para abrir o bugdoc no visualizador de Office ao vivo.

lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

Notas especiais de triagem para a equipe de controle de qualidade

Aqui estão algumas notas para Advanced Triagers no QA/Team. Se você é novo, não se preocupe com nada disso!

Relatórios de bug que são difíceis de selecionar ou fechar

Às vezes precisamos de um software ou hardware especial para reproduzir um bug ou nos deparamos com alguma outra dificuldade que nos impede de investigar. Para esses casos temos:

• Uma coleção de bugs NÃO CONFIRMADOS com os quais os membros da equipe de QA estão tendo dificuldade.

A coleção usa a extensão MediaWiki Bugzilla, que extrai dados de meta-relatórios e várias outras consultas.

Extensões

É melhor envolver o criador da extensão na triagem. A responsabilidade de entrar em contato com o criador é do relator do bug.

Leia também:

• Extensões

Controvérsia relacionada ao local

Às vezes, nos deparamos com tópicos quentes relacionados a localidades. Pode haver uma situação em que um padrão nacional para algo difere da prática real. Nesses casos, pode ser útil direcionar o relator do problema para o Unicode Common Locale Data Repository e sua ferramenta de pesquisa.

Ordem de triagem sugerida

As tabelas abaixo representam uma ordem sugerida para abordar a triagem. O objetivo do controle de qualidade é confirmar primeiro os piores bugs.

Tabela por plataforma (SO)

Descrição	Todos os erros	Windows	Linux	macOS	Comentários
Bugs Relatados como Crashers	CrasherAll	CrasherWindows	CrasherLinux	CrashermacOS	Esses são bugs que têm "crash" ou alguma palavra semelhante no título do bug. Para travamentos, a gravidade deve ser definida como Major/Critical, dependendo de quantos usuários serão afetados. Além disso, o controle de qualidade deve verificar se a falha é uma regressão ou não e adicionar "regression" às palavras-chave se o bug for determinado como uma regressão.
Regressões Potenciais	possibleRegressionAll	possibleRegresionWindows	possibleRegressionLinux	possibleRegressionmacOS	Se for confirmado que o bug é uma regressão, a palavra-chave "possível regressão" deve ser removida e "regressão" deve ser adicionada às palavras-chave.
Palavra-chave Regression	RegressionAll	RegressionWindows	RegressionLinux	RegressionmacOS	O relator do bug ou outra pessoa colocou regressão na palavra-chave. Tão importante quanto a linha acima, mas o Bugzilla não permite uma pesquisa "ou", então teve que dividir em duas linhas.
Bugs relatados como críticos	CriticalAll	CriticalWindows	CriticalLinux	CriticalmacOS	Apenas contribuidores com privilégios especiais podem definir bugs como critical. Critical é reservado para bugs muito sérios (como perda de dados que afetará muitos usuários). Para orientação, consulte PriorityFlowChart.
Bugs relatados como principais	MajorAll	MajorWindows	MajorLinux	MajormacOS	Somente contribuidores com privilégios especiais podem definir bugs como Major. Major é reservado para bugs muito sérios (como perda de dados), mas que provavelmente não afetarão muitos usuários ou estão acontecendo apenas em casos extremos com documentos individuais. Para orientação, consulte PriorityFlowChart.
Todos os erros	AllBugs	AllWindows	AllLinux	AllmacOS	Lista de todos os relatórios de bugs (sem aprimoramentos). Se os bugs acima forem resolvidos primeiro, os restantes terão uma prioridade um pouco menor para confirmar. A sugestão é fazer isso em ordem cronológica (os mais antigos primeiro, para que os usuários que relataram há mais tempo tenham prioridade).
Solicitações de melhorias	EnhancementAll	EnhancementWindows	EnhancementLinux	EnhancementmacOS	As solicitações de aprimoramento têm a prioridade mais baixa para serem confirmadas como solicitações válidas.

Tabela por componente

Descrição	Writer	Calc	Impress	Draw	Base	Outro	Comentários
Bugs Relatados como Crashers	WriterCrasher	SpreadsheetCrasher	PresentationCrasher	DrawingCrasher	DatabaseCrasher	OtherCrashers	A gravidade 'Critical' é reservada apenas para os bugs mais sérios (como a incapacidade de instalar o LibreOffice). Para orientação, consulte PriorityFlowChart
Regressões Potenciais	WriterPosReg	SpreadsheetPosReg	PresentationPosReg	DrawingPosReg	DatabasePosReg	OtherPosReg	Se for confirmado que o bug é uma regressão, a palavra-chave "possibleRegression" deve ser removida e "regression" deve ser adicionada.
Palavra-chave Regression	WriterRegression	SpreadsheetRegression	PresentationRegression	DrawingRegression	DatabaseRegression	OtherRegressions	O relator do bug ou outra pessoa colocou regressão na palavra-chave. Tão importante quanto a linha acima, mas o Bugzilla não permite uma pesquisa "ou", então teve que dividir em duas linhas.
Bugs reportados como críticos	WriterCritical	SpreadsheetCritical	PresentationCritical	DrawingCritical	DatabaseCritical	OtherCritical	Apenas contribuidores com privilégios especiais podem definir bugs como critical. Critical é reservado para bugs muito sérios (como perda de dados que afetará muitos usuários). Para orientação, consulte PriorityFlowChart.
Bugs relatados como principais	WriterMajor	SpreadsheetMajor	PresentationMajor	DrawingMajor	DatabaseMajor	OtherMajor	Somente contribuidores com privilégios especiais podem definir bugs como Major. Major é reservado para bugs muito sérios (como perda de dados), mas que provavelmente não afetarão muitos usuários ou estão acontecendo apenas em casos extremos com documentos individuais. Para orientação, consulte PriorityFlowChart.
Todos os outros Bugs	WriterOther	SpreadsheetOther	PresentationOther	DrawingOther	DatabaseOther	AllOther	Estes são todos os bugs marcados como qualquer coisa abaixo de Major, mas não incluindo aprimoramentos.
Solicitações de melhorias	WriterEnhance	SpreadsheetEnhance	PresentationEnhance	DrawingEnhance	DatabaseEnhance	OtherEnhance	Solicitações de melhorias