Desenvolvimento:Tracker

Rastreamento de problemas é parte importante de um contínuo processo de controle de qualidade. Isso envolve o relato dos problemas (bugs), idéias para melhorias e novas funcionalidades. Diferente da maioria dos softwares pagos, a informação de rastreamento e relato de problemas no Moodle é aberta a todos. Esse sistema se chama Moodle Tracker. Seus pedidos de novas funcionalidades, melhorias ou críticas construtivas das funcionalidades existentes serão bem-vindos.

A beleza do open source é que todos podem participar e ajudar a criar um produto melhor para todos se beneficiarem. Nos auxilie utilizando o Moodle Tracker!

Fundamentos

Logando-se no Tracker

Se você é um usuário novo, crie uma conta aqui. É altamente recomendado que seu nome de usuário no Tracker seja o mesmo que utiliza no Moodle.org.
Se esqueceu sua senha, entre aqui e selecione 'esqueci a senha' abaixo do botão de login, e siga os procedimentos.

Resumo: como relatar bugs, melhorias, ou pedidos de nova funcionalidade

NB: Veja a seção 'Campos do Tracker' abaixo, para descrição completa de cada campo.

Faça login no Tracker
Selecione "Criar Nova Questão" do menu abaixo do logo do Moodle Tracker
Selecione “Tipo de Questão” no menu dropdown: Bug, Funcionalidade, Tarefa ou Melhoria
Você verá uma série de menus dropdown e campos de texto. Complete todos que puder. Alguns campos são obrigatórios e outros opcionais.
Clique no botão 'Criar' no final da página para criar a questão.

Como escrever um bom relato de Tracker

Um bom relato incluirá:

Resumo (descreva a questão em 1 ou 2 frases)
Descrição (uma síntese do problema ou melhoria)
Passos de reprodução: Um passo-a-passo detalhado e simples de ser seguido para que o desenvolvedor possa reproduzir o problema. Se possível, forneça uma URL, então o desenvolvedor pode ver o problema em um clique.
Resultados atuais: os resultados da aplicação após os passos acima.
Resultados esperados: o que deveria acontecer, se não fosse a existência do bug. Forneça o maior número de detalhamento possível. Nossa perspectiva pode ser que as instruções de ajuda precisam ser melhoradas ou a interface alterada.

Se possível, inclua informação adicional que possa ser útil ao desenvolvedor:

Versão do Moodle (existe um menu dropdown no topo do formulário, se não tiver a opção que se aplique, você pode adicionar na descrição)
Se você tem uma mensagem de erro, ou informação nos logs de seu PHP ou servidor web, copie e cole no relato de bug. Se puder, habilite o debugging e reproduza o problema para captar a mensagem de erro da melhor maneira possível.
Screen shots são muito úteis para alguns bugs, mas por favor coloque uma descrição textual do problema também.
Forneça detalhes sobre sua instalação, incluindo sistema operacional, banco de dados, etc.
- Sistema operacional e número da versão
- Servidor web e número da versão
- Número da versão do PHP (se estiver utilizando um acelerador, coloque também)
- Banco de dados e número da versão
- Sistema operacional do cliente e número de versão
- Navegador e número de versão

Você não precisa fornecer detalhes o tempo todo. Por exemplo, para um problema de renderização do layout, você precisar fornecer apenas Sistema Operacional do cliente e as informações do navegador, e se é um problema do lado servidor você só precisa descrever a instalação.

Use seu bom senso. Abaixo, alguns exemplos:
- Eu vejo este bug com a última versão do Moodle HEAD rodando em PHP5.1.2/Apache 2.2.3 e em Linux. Meu banco de dados é Postgres 8.1.
- Este problema de renderização acontece utilizando Internet Explorer 6.0 no Windows XP.

No resumo, se atente aos fatos e apresente-os em número suficiente para que outras pessoas possam duplicar o problema.

Seguem alguns exemplos de bons relatos de bug: [https://tracker.moodle.org/browse/MDL-6030 MDL-6030], [https://tracker.moodle.org/browse/MDL-5688 MDL-5688], [https://tracker.moodle.org/browse/MDL-12505 MDL-12505]

Uma boa referência externa para auxiliar a descrição pode ser encontrada nas orientações do mozilla para descrição de bugs.

"O que é mais difícil em um relato de bug?" Na maior parte do tempo, resolver o problema é a parte fácil, a parte difícil é reproduzir o bug. O desenvolvedor precisa ver como está quebrado para ser capaz de consertar. Se ele não puder reproduzir o erro, pode ter certeza de que ele não terá como consertá-lo!

Bons relatos de bug contém o máximo de detalhes possíveis e são muito específicos. Não generalize ou antecipe as conclusões.

Por exemplo, um relatório de bug que diz apenas "O RSS não suporta UTF-8" não é útil. O desenvolvedor sabe que UTF-8 e RSS são compatíveis. O desenvolvedor não tem idéia do que a pessoa está vendo e porque relatou este bug. Neste caso, mais tempo e esforço será necessário para determinar o problema.

Considere um relato de bug que diga que uma descrição para o RSS específico XYZ@abc mostra caracteres não-reconhecidos ao invés dos caracteres esperados.

Processo de Tracker

Relatando novas questões ou melhorias

Todos com uma conta no Tracker podem relatar questões. Veja instruções acima para escrever relatos de bug com boa qualidade. É importante que você realize uma busca no Tracker para determinar se seu problema ou sugestão de melhoria já foi relatado. Se você foi encorajado a adicionar mais informação (use a função “comentário”), vote na questão, ou a observe (mais sobre isso mais tarde).

Você receberá um email quando relatar um novo bug ou atualizar bugs já reportados. Você também receberá notificação quando atualizações forem realizadas em bugs que você estiver observando.

Você pode monitorar, ou observar questões relatadas por outrem. Para isso, abra a questão e selecione “Observar” no lado esquerdo do painel de navegação. Para adicionar outros bugs na lista de observação, abra a questão e selecione a opção “Observando” no lado esquerdo do painel de navegação. Essas pessoas receberão notificações de email quando a questão for atualizada. para visualizar todas as questões que está observando, vá ao Painel (veja abaixo) e procure por “Minhas Observações”.

O Tracker fornece facilidade para linkar questões. Todos os usuários logados no Tracker podem ter links de questões. Vários tipos de link são definidos no sistema; você será requisitado a selecionar um quando linkar bugs.

Vote em bugs que você queira ver consertados no Moodle. Todos os usuários podem votar. Para votar em um bug específico, navegue até ele, então selecione "Votar" no painel do lado esquerdo. Desenvolvedores podem considerar o número de votos de um bug para decidirem entre dois ou mais bugs. Para ver todas as questões em que você votou, vá ao Painel (veja abaixo) e procure por “Meus Votos”. O Painel do Tracker é flexível e customizável dependendo de sua área de interesse. Para instruções de configuração dele, clique aqui.

O Navegador de Questões é usado para encontrar e filtrar bugs. Para instruções de configuração dele, clique aqui.

A função de Busca Rápida do Tracker é explicada aqui.

Resolvendo problemas

Questões são resolvidas no Tracker para demonstrar que elas foram acionadas. Apenas desenvolvedores Moodle e testadores têm permissão para alterar o status de bugs no Tracker para “resolvido” ou “fechado”.

Este é o processo que um desenvolvedor seguirá quando acionando uma questão no Tracker:

Questões são automaticamente assinadas no momento em que são criadas, baseando-se no tipo de componente; elas podem ser assinadas novamente por desenvolvedores ou Condutores de Componentes.
Desenvolvedores consertam, modificam ou adicionam código e testam dentro do CVS. O número da questão do tracker é incluído quando automaticamente links no CVS alteram o Tracker.
Caminhos são anexados a questões de Tracker, então podem ser verificados e possivelmente incluídos no CVS.
Comentários apropriados descrevendo a solução devem ser adicionados no Tracker. O status do bug é alterado para Resolvido.
O desenvolvedor deve indicar em qual versão do Moodle a alteração será incluída utilizando o Versionamento de Soluções. Você deve utilizá-lo para indicar em qual ramificação (branch) você verificou e consertou o bug. (Exemplo abaixo):
.A única exceção para não alterar o status para Resolvido é se o desenvolvedor acredita que não há motivos para testar a questão resolvida, neste caso o status pode ser alterado para Fechado.

Testando Questões

Todos os usuários são encoragados a serem participantes ativos no que se refere a testar o Moodle. Qualquer pessoa com uma conta de usuário no Tracker pode visualizar, comentar , votar e observar bugs. Se você encontrar bugs ou problemas, tem idéias para melhorias, ou quer funcionalidades adicionais para o Moodle, adicione um bug no Tracker.

Nós formalizamos um grupo de testadores no Tracker que são responsáveis por verificar a precisão de alterações realizadas por desenvolvedores. Estes testadores tem responsabilidades e autoridades no Tracker além dos usuários padrão. Testadores normalmente tem um bom entendimento do Moodle, e são ativos na comunidade Moodle. Obviamente, testadores devem ter as perícias e conhecimentos para testar satisfatoriamente a questão – experiência é importante – mas não se esqueça que existem outras pessoas na comunidade que podem ajudar. Se você está interessado em se tornar um membro do Time de Testadores Moodle, faça sua requisição através do Tracker. Nós adoraríamos que você adentrasse o time!Acesse o projeto Tracker em Moodle.org Sites.

Testando um bug no tracker

N: Este é o processo que membros do grupo de testadores do Moodle devem seguir para mover status de bugs de 'resolvidos' para 'fechados'.

Testadores testam bugs com Status=Resolvido. Filtros globais foram criados baseados em próximas atualizações (ex: 1.7 Resolvido) para tornar a identificação simples.
Use o campo QA Assignee para se identificar como testador de um bug específico.
É uma boa idéia adicionar seu nome para a lista de observadores para todos os bugs que você testar. (veja “Lista de observadores do tracker”, abaixo).
Se o bug passa no teste, feche-o utilizando o botão “Fechar Questão”. Você deve adicionar comentários apropriados descrevendo seus métodos de teste, qualquer questão que tenha encontrado, etc.
Se o bug falhou no teste ou você percebe que a restauração está incompleta, reabra-o utilizando o botão “Reabrir Questão”. Tenha certeza de que o bug foi assinado para o desenvolvedor correto. Trabalhe com o desenvolvedor para encontrar uma resolução comum para o bug.
Uma versão será considerada pronta quando todos os bugs específicos dela tiverem sido fechados.
Todos os bugs resolvidos devem ser testados. Bugs com código de solução “fixado” representam bugs cujo código foi atualizado, e provavelmente representam um desafio maior do que bugs com códigos de solução “duplicado”, “sem solução”, e “impossível reproduzir”. Tenha a certeza de que os bugs foram fechados com o código correto. Infelizmente não é fácil alterar um código de solução no Tracker uma vez que o bug já foi resolvido (a única maneira é reabrir e resolvê-lo novamente).
Não tenha medo de discutir seu teste com o desenvolvedor que assinou o bug. Simplesmente adicionar um comentário deve alertar o desenvolvedor e notificá-lo de todas as mudanças.

Descrição detalhada dos campos do Tracker e grupos

Campos do Tracker

Projeto – Campo obrigatório. Tracker é uma coleção de projetos múltiplos. Atualmente, eles são 3: 'moodle', 'moodle.org sites' e 'Non-core contributed modules'. Especificamente 'moodle' para questões/bugs relacionados ao software moodle; espeficamente 'moodle.org sites' para questões/bugs relacionados ao tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, ou moodle.org; especificamente 'Non-core contributed modules' para questões/bugs relacionados aos módulos de contribuintes.

Tipo de Questão - Campo obrigatório. Segue a classificação de bugs:

Bug – Um problema que danifica ou impede o Moodle de funcionar corretamente.
Melhoria – Um aprimoramento para uma funcionalidade Moodle já existente.
Nova funcionalidade – Uma nova funcionalidade Moodle que está para ser desenvolvida.
Tarefa – Uma tarefa que precisa ser completada. Tarefas geralmente se referem a trabalhos que devem ser realizados fora do produto.
Sub-Tarefas – Questões as vezes são divididas em múltiplas sub-tarefas.

Sumário - Campo obrigatório. Uma rápida e concisa descrição do problema.

Nível de Segurança – Quanto mais alto o nível de segurança, menos pessoas podem ver a questão.

Nenhum – visível para todos, incluindo usuários não logados
Pode vir a ser uma questão de segurança – Visível para todos os usuários logados
Questão de segurança menor – Visível apenas para desenvolvedores e testadores
Questão de segurança maior – Visível apenas para o time de segurança

Prioridade- Bugs são divididos por prioridade da seguinte maneira:

Bloqueado – Desenvolvimento bloqueado e/ou em fase de teste, produção pode não rodar corretamente.
Crítico – Quedas, perda de dados, vazamento de memória.
Maior – Alta perda de funcionalidades.
Menor– Baixa perda de funcionalidades, ou outro problema onde pouco trabalho é necessário.
Trivial – Problemas de estilo como palavras erradas ou texto desalinhado.

Componente(s) – Campo obrigatório. Selecione a área do Moodle que é afetada por esse bug. Selecione “Unknow” se você não tem certeza.

Versões Afetadas - Campo obrigatório. Esta é a versão do Moodle na qual o bug foi encontrado. É colocado pela pessoa que cadastrou o bug, e normalmente apenas uma versão é especificada. Coloque sua versão atual quando cadastrando uma 'melhoria', 'tarefa' ou 'nova funcionalidade' pois isso ajudará a avaliar o estado do produto quando a requisição foi feita.

Assinado por – Esta é a pessoa que irá consertar o código da questão. O Tracker automaticamente assina questões para Condutores de Componente. Desenvolvedores ou Testadores podem reassinar questões.

Reportado por – A pessoa que cadastra o bug. Este campo é preenchido automaticamente pelo Tracker.

Ambiente – Especifica o sistema operacional, software e especificações de hardware, se aplicáveis ao bug.

Descrição – Uma completa, mas concisa descrição do problema ou melhoria.

Banco de Dados – Campo opcional. Se aplicável ao bug, identifique o tipo de banco de dados.

URL – Campo opcional. Se possível, providencie a URL que demonstra um exemplo de ocorrência do bug.

Assinatura QA – Utilizado para designar a pessoa que testará a questão..

Versões Fixadas – Esta é a versão do Moodle onde o bug foi ou será consertado. Basicamente você deve pensar em qual lançamento isso deve aparecer? Este campo é normalmente completado pelo desenvolvedor quando o bug for resolvido ou pelos condutores de desenvolvimento alocando bugs para um lançamento específico. Normalmente apenas uma versão é especificada neste campo. Representa a primeira versão do Moodle onde a mudança será vista.

Exemplo: depois que o Moodle 1.9 foi lançado, se você fixar um bug nas ramificações MOODLE_19_STABLE e HEAD, marque como fixado em 1.9.1.

Se você também reportou ao MOODLE_18_STABLE, então adicione também a versão do próximo lançamento da versão 1.8.x.

Se você sinalizar um bug como outra coisa além de “Resolvido” (Impossível Reproduzir, Sem Solução, etc) deixe o campo Versões Fixadas em branco.

Se sinalizar o bug como Duplicado, então crie um link para a questão duplicada. Essas versões são utilizadas para construir automaticamente as notas de lançamento.(veja as abas em http://tracker.moodle.org/browse/MDL).

Anexos - Opcional. Anexe um arquivo que poderá ajudar desenvolvedores e testadores a entender melhor o bug. Tamanho máximo de 512Kb.

Comentários - O campo de comentários é um registro detalhado de todas as alterações que relatam esse bug.

Resolução – Este campo só é mostrado quando resolvendo ou fechando um bug. Especifique um código que descreve da melhor maneira como esse bug foi resolvido.

Resolvido- O Bug foi resolvido; um código de alteração será colocado no CVS. Use esse código de resolução apenas quando alterações atuais forem feitas ao código do Moodle.

Sem solução – O problema descrito nunca será resolvido.

Não é um bug – Esta questão não é um bug; foi cadastrada erroneamente. Utilize este código se o bug foi resolvido por outra requisição ou em uma versão mais recente do Moodle.

Duplicado – O problema é uma duplicata de uma questão existente.

Incompleto – É necessária mais informação para entender o bug.

Impossível reproduzir – Todas as tentativas de reprodução falharam, ou não existe informação suficiente para reproduzi-lo. Ler o código não dá pistas do motivo pelo qual ocorre este comportamento. Se mais informações aparecerem, reabra a questão.

Deferido - A solução para este bug será deferida em um lançamento posterior.

Grupos de Tracker e permissões

Usuários Padrão [groupname=jira-user] – Este é o grupo padrão. Novas contas de usuário são colocadas neste grupo no momento em que ele é criado, e usuários devem ser membros desse grupo para conseguirem fazer login no Tracker. Membros deste grupo podem procurar bugs, criar novos bugs, fazer comentários em bugs existentes, observá-los, criar anexos, sub-tarefas, filtros e votar em bugs. Membros desse grupo também podem resolver bugs, o que é uma maneira de fechar bugs não mais relevantes (como duplicatas ou cadastros errôneos).

Usuários Padrão podem configurar seu espaço de trabalho no Tracker utilizando o botão “Configure seu Navegador” Esta funcionalidade permite que usuários visualizem e votem em listas e gerenciem preferências, perfil, e senha.

Desenvolvedores [groupname=jira-developer] – Desenvolvedores podem fazer tudo que Usuários Padrão podem fazer. Adicionalmente, eles podem copiar bugs, fechá-los, editá-los, linka-los e assiná-los. Membros desse grupo também podem utilizar a Edição em Conjunto, que permite atualizações em conjunto para bugs múltiplos.

Testadores [groupname=moodle-testers] – Testadores tem as mesmas permissões dos desenvolvedores.

Grupos de Segurança do Moodle [groupname=moodle-security] – Desenvolvedores confiáveis e administradores que precisam trabalhar com e aprender sobre questões de segurança.

"Nobody" é um usuário Tracker criado para alertar usuários quando uma questão não foi assinada por um desenvolvedor. Estas questões são revisadas regularmente pelo time do Moodle HQ.

N: você pode navegar por um projeto enquanto não estiver logado no Tracker, entretanto você não será capaz de alterar, editar ou comentar bugs.

Tipos de Link

Os seguintes tipos de links estão disponíveis:

duplicados – duplicatas são inevitáveis em um projeto do tamanho do Moodle. Eles ocorrem quando um usuário está desavisado de um bug existente que descreve o mesmo problema. Utilize links duplicados ao primeiro ou mais compreensivamente descritos na instância do problema. Todas as duplicatas devem ser relacionadas.

bloqueadores – utilize isto para identificar bugs que impedem outros de serem resolvidos.

clonados – em alguns casos, um bug duplicado é intencionalmente criado para rastrear a solução em outra ramificação do código. Isso raramente é utilizado no Moodle.

dependência – na maioria das vezes uma resolução é dependente de outro bug ser resolvido primeiro, em uma ordem específica.

relatos – utilizado para identificar um bug que de alguma forma é relacionado a outro bug.

Não tenha medo de relacionar bugs. Links tem um significado bi-direcional que remete ao conceito de 'interior' ou 'exterior' – afeta a maneira a qual bugs relacionados são demonstrados. É por isso que você verá “bloqueio/bloqueado por” ou “duplicata/duplicado por” na caixa de listagem Link Issue. Não se preocupe em utilizar o tipo de link “certo” - todos trabalham de maneira similar.

Como visualizar o código alteradoclonados – em alguns casos, um bug duplicado é intencionalmente criado para rastrear a solução em outra ramificação do código. Isso raramente é utilizado no Moodle.

dependência – na maioria das vezes uma resolução é dependente de outro bug ser resolvido primeiro, em uma ordem específica. relatos – utilizado para identificar um bug que de alguma forma é relacionado a outro bug.

Se existe alguma alteração de código relacionada a uma questão do tracker, você pode ver o código alterado clicando na aba de controle de versão. Os códigos são listados com o rótulo MODIFICAR e as alterações podem ser vistas clicando nos sinais de “+-” que indicam quantas linhas foram alteradas.

Documentation