Este artigo necessita de uma revisão editorial. Como posso ajudar.
Este artigo fornece um gua para apresentação e manipulação de bugs relacionados com o projeto Firefox OS.
Bugzilla
Assim como a maioria dos projetos na Mozilla, nós usamos o Bugzilla para rastrear o status de bugs e outras questões relacionadas a problemas encontrados. Você pode registrar os bugs que você encontrar no bugzilla -- Nós temos um projeto separado para o Firefox OS, que contém componentes abrangendo o Gaia, Gonk e o Gecko do Firefox OS.
Observação: A página da Wiki B2G QA também tem alguns recursos úteis para manipular bugs no Firefox OS. As páginas mais úteis são O uso do Bugzilla, e Triagem de erros de entrada para o Firefox OS.
Registrando bugs
Para arquivar um bug de forma eficaz, você pode seguir as instruões em Diretrizes para o registro de Bugs.
Campos obrigatórios e opcionais
Ao criar um bug, alguns campos são obrigatórios:
| Campo | Descrição |
|---|---|
| Component | Escolha a categoria a qual o bug deve pertencer. Se você não tem ideia de qual categoria este problema pertence, inclua em "General". |
| Summary | Escreva um resumo para descrever brevemente o bug. |
| Description | Descreva a situação claramente. Um bom bug deve conter: STR (Passos para Reproduzir ou Step to reproduce - em inglês), Resultado esperado, Resultado Atual, e número de Versão. Um número de versão pode ser um commit do Gaia/Gecko ou uma identificação do Build (disponível em servidores privados de compilação ou versões públicas). |
Os campos a seguir são opcionais:
| Campo | Descrição |
|---|---|
| Attachment (Anexos) | Qualquer anexo pode ajudar a analisar o problema. Vídeo, imagens, testcases ou logs são bons para analisar. |
| Depends/Block | Exibe as dependencias entre bugs. |
| Keywords | Palavras chave para o bugzilla. Isso ajudará ao grupo específico rastrear bugs semelhantes. |
| Whiteboard | Contém tags. Adicione qualquer tag para o bug para rastreá-lo. Você não deve remover outras tags de outras pessoas sem permissão. |
| See Also | As vezes, dois problemas estão relacionados e você pode especificar isto nesta área. |
| Flags | Flags para rastrear o status; A flag mais usada nos bugs do FireFox OS é a blocking-b2g. Isso significa que nós devemos dar mais atenção a ele, uma vez que ameaça a liberação do release. |
| Security | Se um bug está relacionado a segurança de dados pessoais, If a bug is related to personal data security, perda de rendimento, e outras questões desse cunho, você deve marcar este checkbox e este será visivel somente às pessoas diretamente envolvidas. |
Para saber mais sobre os campos do bugzilla, consulte essaa página.
Palavras-chave comuns
A tabela a seguir fornece informações sobre as palavras-chave mais comuns utilizadas nos bugs do Firefox OS.
| Palavra-chave | Descrição |
|---|---|
| meta | Indica que o bug está num status de "tracking". Mozilla usa essa tag para rastrear múltiplos bugs ou o histórico de status de implementação. Uma vez marcado como meta, desenvolvedores não devem lançar patches (correções) desses bugs. Por favor, tenha em mente que os gerentes de projeto e as equipes de qualidade usam meta bugs para rastreamento. |
| qablocker | Use essa palavra-chave para bugs que impedem o prosseguimento de testes (testes manuais ou automáticos de um recurso) e precisam ser corrigidos para o próximo marco Beta ou RC. |
| qawanted | Use essa palavra-chave para bugs que necessitam de maiores informações, requerem ser reproduzidos ou de casos de testes, ou são duplicados (mas você não consegue encontrar o bug original). Requisição do trabalho da equipe de QA é registrado no whiteboard, você deve remover essa palavra-chave quando o trabalho de QA foi finalizado. |
| regression |
Essa palavra-chave indica que o problema foi corrigido, mas por uma regressão e o bug em questão é um novo bug, registrado para rastrear a regressão. Também pode se referir a problemas que não os identificados nos testes pre-checked ou smoke tests, que foram encontrados em compilações correntes e que são conhecidos em versões anteriores. Rastrear esses bugs nos ajuda a identificar áreas mais frágeis propensos à ruptura e são bons candidatos para adoção de smoke tests e pré-check. |
| regressionwindow-wanted | Indica que o bug é uma regressão e é utilizado para qualquer um identificar o período no qual ocorreu. Ideal para verificações específicas. |
| steps-wanted | Identifica um bug que deve ter um passo-a-passo para reproduzi-lo. |
| verifyme |
Significa que esse bug está pronto para ser verificado com o a última compilação B2G por alguém que não seja o representante indicado do time de QA. O bug tem o detalhamento de uma configuração específica de máquina para verificar a correção. Você pode tentar reproduzir a falha e se você concordar que a resolução do problema está correta, altere o Status como Verified. |
Qual a diferença entre status tracking e bugs da engenharia?
Mozilla possui um perfil especial chamado Sheriff. Sheriffs têm a responsabilidade do merge de códigos e manter os status dos branches. Uma vez que nós temos um número limitado de Sheriffs para testes de falhas nas equipes do Firefox OS, fica difícil para eles are in charge of merging code and maintaining branch status. Since we have limited sheriffs scouting for test failures in Firefox OS teams, voltar o processo de todas as correções imperfeitas.
Portanto, no Firefox OS, ao examinar se uma correção funciona ou não preferimos abrir um novo bug para lançar novas correções para consertar o novo problema. Do contrário pode trazer problemas no status de rastreamento para as equipes de QA e de gerenciamento de projetos.
Assim, nós separamos os bugs em dois status: tracking bugs e engineering bugs.
- Bugs com Status tracking devem ser identificados com a palavra-chave "meta". O bug pode ser reaberto se ele não cumprir os critérios de aceitação ou falhou durante os passos para reproduzir.
- Um bug "engineering" pode ser reaberto somente se falhou nos testes automáticos ou a correção não funciona como um todo. Se um patch corrige um engineering bug parcialmente, você deve clonar o bug e use o campo "See also" para referenciar o bug original descrevendo o ponto de falha.
Nota: Se também for um bug "story bug", o gerente de projeto deve regsitrar o campo user story com o histórico e o critério de aceitação.
Como eu recupero se acidentalmente lançar uma correçaão no bug com status tracking?
Não entre em pânico! Se você acidentalmente lançou uma correção, tem um review+, lançou no tunk ou tem reportado como nada corrigido, a seguir o que você precisa fazer:
- Pressione "Clone this bug" no canto inferior direito da tela para criar um novo bug, clonando a maioria dos campos originais. Verifique os os campos: witheboard, keyword e STR/User Story foram copiados para o novo bug.
- Marque o novo bug como bloqueado pelo bug anterior. O novo bug terá o novo status tracking bug.
- Use a flag needinfo para alertar o gerente de projeto. Você pode pode encontrar os endereços de e-mail dos gerentes de projeto do Firefox OS na nossa Wiki.
- Crie um novo engineer bug para descrever o passo com a falha ou o critério de aceitação. Também use o novo bug para bloquear o status tracking bug.
- Tente consertar o novo bug.
Promovendo correções para branches antigos
Você pode encontrar versões diferentes de tags nos bugs. Se você deseja promover correções para branches antigos do Firefox OS, certifique-se que preencham as regras para lançamento de uma correção. Maiores detalhes nessa página.