Tracker

Tracker – Sistema de gestão de bugs do Moodle

A detecção e reparação de bugs constituem um processo contínuo de controlo de qualidade. No caso do Moodle, esta detecção e reparação de bugs, por ser uma plataforma open-source, está aberta a todos quantos queiram participar, constituindo este facto uma vantagem em relação às plataformas proprietárias. O sistema que permite fazer esta detecção e posterior correcção de erros associados à plataforma Moodle chama-se Tracker. O ponto interessante do open-source está no facto em que todos os utilizadores interessados podem ajudar de várias formas, quer no código ou na detecção de erros, com o objectivo de trabalhar num produto que seja do agrado da comunidade.

Login no Tracker

Caso seja um novo utilizador do Tracker, o processo de registo poderá ser realizado aqui. Recomenda-se aqui que o username usado seja o mesmo do site moode.org. Caso a conta de acesso ao Tracker não funcione, a mesma pode ser recuperada aqui: http://tracker.moodle.org

Resumo: Como reportar um erro, um melhoramento, ou um pedido de funcionalidade

1. Fazer o login na homepage do Moodle Tracker.
2. Seleccionar “Create New Issue” no menu baixo do logótipo do Moodle Tracker.
3. No passo 1, no menu desdobrável seleccionar o “Issue type”: Erro (bug), Nova Funcionalidade (New Feature), Tarefa (Task) ou Melhoramento (Improvement).
4. No passo 2, será visível várias áreas desdobráveis em branco.

• Resumo (Summary): Breve descrição do problema. O objectivo aqui é tentar fazer com que a descrição seja o mais precisa possível. A simples expressão do “Não funciona” não se revela de grande importância. È importante também pensar as palavras-chave que identificam o problema, para que o problema seja rapidamente encontrado pelos utilizadores pesquisarem pelo mesmo erro.

• Componentes (Components): usar a teclas Ctrl e com um click do rato seleccionar uma ou mais áreas do Moodle. Por exemplo, pode ser encontrado um erro numa funcionalidade que tenha impacto em vários módulos.

• Seleccionar a versão do Moodle, e caso não esteja listada por informação relativa á versão na descrição.

• O Ambiente (Enviroment) é para a informações relativas ao sistema operativo e outras informações. Ver guias gerais mais abaixo.
• A Descrição (Descritpion) informa-nos acerca do assunto tratado. Informações sobre este tópico, mais abaixo.

• Base de Dados (Database), se não estiver na lista, por a informação relativa no campo Ambiente(Enviroment)

Guia geral para a submissão de relatórios

Um bom relatório deve incluir:

• Resumo do problema em uma ou 2 frases
• Descrição concreta e concisa do problema ou melhoramento em causa
• Deve ser também feita uma descrição passo-a-passo da sequência de passos a fazer com o objectivo de reproduzir o erro. Se possível, indicar o endereço para o que o programador consiga ver o erro apenas com um click.
• Resultados actuais: indicar o que é que a aplicação faz após os passos serem executados
• Resultados esperados: explicitar os resultados que são esperados, caso o erro não estivesse presente. É importante que a explicação seja bastante pormenorizada pois isso ajudará na resolução do erro, bem como no interface que poderá ser ajustado de forma a ser mais amigável.

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

• Versão do Moodle (se a versão não se encontrar no menu desdobrável no topo do formulário, adicionar essa informação na descrição)
• Se existir uma mensagem de erro ou outra informação, quer nos logs do PHP ou do servidor web, inclua uma cópia dessa informação no relatório. Se for possível, ligar o modo “debug” na página configuração do Administrador com o objectivo de obter a melhor mensagem de erro possível.

• Os ecrãs capturados podem também ser uma grande ajuda, mas devem ser acompanhados de uma descrição.
• Fornecer as informações relativas à configuração do sistema operativo, base de dados, etc. Se o espaço disponível na secção Ambiente (Enviroment), pode ser feita a continuação na secção da descrição. Algumas das informações que neste caso podem ser relevantes, são:

• • Sistema operativo do servidor e número de versão.
  • Tipo de servidor e número de versão.
  • Versão de PHP usada (e se é usado algum optimizador).
  • Tipo de base de dados e número de versão.
  • Tipo de sistema operativo do cliente e número de versão.
  • Tipo e número de versão do browser utilizado.

• Não é necessário fornecer sempre todos os dados. Por exemplo, se for um problema de layout, será só necessário fornecer informação sobre o sistema operativo e browsers utilizados pelos clientes. Ficam aqui alguns exemplos:
  • Detecção de um erro na última versão do HEAD do Moodle, a correr em PHP5.1.2/Apache 2.2.3 em Linux. A base de dados utilizada é Postgres 8.1.
  • Existe um problema de renderização, utilizando o Internet Explorer 6.0 em Windows XP.

Em resumo, deve fazer-se uma reunião de facto suficientemente boa para que outros utilizadores possam duplicar o problema.

Aqui estão alguns exemplos de boas práticas na submissão de relatórios de erro: MDL-6030, MDL-5688, MDL-12505. Muitas vezes a parte difícil neste processo, não consiste na reparação do erro, mas sim na reprodução do mesmo por parte do programador. O programador tem assim de poder conseguir reproduzir o erro submetido, caso contrário nunca o poderá resolver.

Bons relatórios são os que contêm informação o mais detalhada e especifica possível. Por exemplo, um relatório de erro que contenha apenas “ O feed RSS não suporta UTF-8” não ajuda em nada. O programador sabe que o UTF-8 e os RSS feeds são compatíveis. Além do mais o programador não faz ideia do que o utilizador vê no seu computador e porque submeteu o erro. Neste caso terá de ser dispendido mais tempo e esforço na determinação de qual será o problema.

O processo do Tracker

Acompanhamento de novas matérias e melhorias

Qualquer um com uma conta no Tracker pode acompanhar matérias que são submetidas. Acima estão descritas boas práticas sobre como escrever relatórios de erro de boa qualidade. É importante procurar no Tracker para determinar se o seu problema ou sugestão para a melhoria foram já objecto de relatório. Caso exista a intenção de adicionar mais informação (use a função do “comment”), voto para a edição, ou acompanhar para ver mais tarde (watch it). Receberá depois um email cada vez que for subscrito um novo erro novo ou forem feitas actualizações aos erros que foram relatados. Será também enviada uma notificação quando são feitas actualizações aos erros que foram marcados para serem acompanhados.

Podem também ser monitorizados ou acompanhados, erros submetidos por outros utilizadores. Para fazer isto, abra o erro em questão, depois seleccione “Watch it” que se encontra na parte esquerda do painel de navegação. Para que outras pessoas sejam adicionadas para acompanhar problemas submetidos por nós, seleccionar a opção “Watching” que se encontra na parte esquerda do painel de navegação. Essas pessoas serão depois notificadas por correio electrónico cada vez que houver uma actualização ao problema.

O Tracker fornece uma facilidade fazer o link entre matérias submetidas. Qualquer usuário registado no Tracker pode ligar matérias. Os tipos de ligação múltipla estão definidos no sistema; será solicitada a escolha de um tipo ao ser feito o link de erros. Veja [nome da secção da inserção] para lista detalhada de tipos da ligação.

Vote em erros que você quer ver abordados no Moodle. Todos os utilizadores podem votar. Para votar para um erro específico, seleccione o erro, seleccionando depois “Vote for it” do painel de navegação esquerdo. Os programadores podem considerar o número dos votos que um erro tem para fazer a escolha entre dois ou mais erros.

O painel (Dashboard) do Tracker é flexível e pode ser modificado conforme as áreas de interesse de cada utilizador. Para mais instruções acerca da configuração do Painel do Tracker clicar aqui. O Issue Navigator do Tracker é a ferramenta que permite encontrar e filtrar erros. Para mais instruções sobre o Issue Navigator clicar aqui.

A função de pesquisa rápida (Quick Search) do Tracker está explicada aqui.

Resolvendo assuntos no Tracker

Só os programadores e responsáveis pelos testes ao Moodle têm permissão para mudar o estado dos erros no Tracker para “resolvido” ou “fechado” ("resolved" or "closed").

Este é o processo geral que o programador irá seguir, quando mudar o estado de um assunto referido no Tracker:

1. Os assuntos são automaticamente atribuídos no momento da sua criação tendo como base o componente a que são relativos; caso os programadores ou os responsáveis do componente entendam, o assunto pode ser novamente atribuído a outro módulo
2. Os programadores reparam, modificam ou adicionam código e fazzem a verificação do CVS. O número que identifica o assunto no Tracker faz automaticamente a ligação entre a mudanças no CVS ao Tracker.
3. Os patchs estão anexos aos assuntos no Tracker para que possam ser analisados e depois possivelmente adicionados no CVS.
4. Devem ser acrescentados comentários no Tracker com a descrição da reparação feita. O estado do erro é depois alterado para Resolvido (Resolved).
5. O programador deve indicar em que versão do Moodle a alteração irá ser incluída usando o Fix Version/s. Deve depois ser indicado qual o ramo ou ramos nos quais a alteração foi verificada
6. A única excepção que pode existir na alteração de estado de um erro para Resolvido (Resolved) dá-se no caso de o programador entender que não existe valor em testar o assunto resolvido. Neste caso a alteração de estado será para Fechado (Closed).

Testes á plataforma

Todos os utilizadores são incentivados a serem participantes activos no que diz respeito a testar o Moodle. Qualquer pessoa que tenha um registo no Tracker pode registar, ver, comentar, votar, e acompanhar erros. Caso existam alguns erros, problemas, ideias para aperfeiçoamentos, o se existir o desejo de que alguma funcionalidade seja adicionada ao Moodle, o utilizador deve reportar isso no Tracker.

Foi formalizado um grupo de pessoas responsáveis por fazer testes no Tracker que são responsáveis por verificar o rigor das alterações feitas pelos programadores. Este grupo de pessoas tem responsabilidades e autoridade no Tracker que vão além do utilizador comum. Além disto são utilizadores com grande conhecimento de toda a estrutura do Moodle, sendo também membros muito activos na comunidade Moodle. É claro que estes devem ter um nível suficiente em termos de atributos e conhecimentos necessários para os testes que realizam – a experiência é muito importante – mas também não pode ser esquecido que existem sempre utilizadores na comunidade dispostos a ajudar em qualquer eventualidade. Se quiser fazer parte da Equipa de Testes do Moodle, manifeste a sua intenção reportando-a no Tracker. Reporte a sua intenção em Moodle.org Sites Tracker project.

Teste de erros no Tracker

Este é o processo que a equipa de testes do Moodle deve seguir para alterar o estado dos erros de resolvidos (resolved) para fechados (closed).

• Os membros desta equipa testam os erros que se encontram no estado Resolvido (Resolved). Foram criados filtros global baseados em futuros lançamentos (ex. 1.9 Resolvido) para que a identificação seja feita de uma maneira mais facilitada.
• Usar o campo QA Assignee para fazer a identificação como inspector (membro responsável pelos testes) do erro.
• Uma boa ideia será subscrever todos os tópicos relativos aos erros que são testados (ex. todos os erros em que nós fomos responsáveis pela fase de testes).
• Caso o erro passar a fase de testes, alterar o estado do erro usando o botão “Fechar Assunto” (“Close Issue”). Devem ser adicionados comentários com a descrição do método usado para fazer os testes, todas as incorrecções encontradas, etc.
• Caso o erro não passe a fase de testes ou se houver o sentimento de que o erro não foi completamente reparado, deve fazer-se a alteração do seu estado através do botão “Reabrir Assunto” (“Reopen Issue”) de forma a este ficar novamente com a indicação que não está completamente resolvido. Certificar-se de que o problema é entregue ao programador correcto. Trabalhar com o programador no sentido de ser encontrada uma resolução que seja acertada para ambas as partes.

• Uma versão será dada como pronta quando todos os erros a ela relativos forem dados como estando fechados.
• Todos os erros resolvidos devem ser testados. Erros que no final tenham a indicação de reparados (fixed) representam erros sujo o seu código foi actualizado, e provavelmente representaram um maior desafio do que os erros que tenham no final a indicação de sendo duplicados, que não constituem um erro, ou que foi conseguido reproduzir esse erro. É aconselhável a certificação de que os erros foram finalizados com a indicação correcta. Infelizmente não é fácil alterar o código quando ele é posto no Tracker ( a única solução será reabrir e depois fechar o tópico).

• Os processos de teste devem ser discutidos sem receios com os programadores afectos ao erro. Muitas vezes um comentário chama logo a atenção do programador enquanto são notificados de todas as mudanças.

Descrição detalhada de todos os grupos e campos do Tracker

Em cada campo no Tracker é sempre apresentada uma pequena explicação.

Projecto (Project) – Campo obrigatório - o Tracker é constituído por vários projectos. No presente existem 3: 'moodle', 'moodle.org sites' and 'Non-core contributed modules'. Escolha ‘moodle’ para erros/assuntos relacionados com o software moodle; escolha 'moodle.org sites' para erros/assuntos relacionados com tracker.moodle.org, docs.moodle.org, demo.moodle.org, download.moodle.org, ou moodle.org; escolha 'Non-core contributed modules' para erros/assuntos relacionados com módulos.

Tipo de assunto (Issue Type) - Campo obrigatório – os erros são classificados segundo as seguintes categorias:

• Erro (bug)- um problema que afecta o funcionamento correcto do Moodle.
• Melhoramento (Improvement) - uma melhoria a uma funcionalidade já existente no Moodle
• Nova funcionalidade (New Feature) – uma nova funcionalidade que tem ainda de ser desenvolvida
• Tarefa (Task) – uma tarefa que necessita de ser completada. Usualmente refere-se a trabalho que tem de ser executado fora do âmbito do produto.
• Sub-tarefa (Sub-task) – assuntos que por vezes são divididos em assuntos mais pequenos

Sumário (Summary) - Campo obrigatório – uma descrição breve e concisa do problema.

Nível de segurança (Security Level) – Campo opcional. Indica se o erro ou modificação tem implicações de segurança para o Moodle. Erros que tenham seriam implicações a nível de segurança, são reservados para a equipa de segurança do Moodle.

Prioridade (Priority) – os erros têm os seguintes níveis de prioridade:

• Blocker – bloqueia o desenvolvimento e/ou trabalho de teste, a produção não pode continuar.
• Critical - Crashes, perdas de informação, fugas sérias a nível de memória.
• Major – perda importante de funcionalidade.
• Minor – perda de uma funcionalidade acessória, ou outro problema de fácil resolução
• Trivial – problema de nível cosmético como por exemplo erros ortográficos ou texto desalinhado

Componentes (Components) – Campo obrigatório. Seleccionar a área do Moodle afectada pelo erro. Em caso de incerteza, seleccionar “Unknown”.

Versão Afectada (Affects Version) – Campo obrigatório. Esta é a versão do Moodle na qual o erro foi encontrado. Esta informação é inserida pela pessoa que reporta o erro, e normalmente apenas uma versão é apontada. Inserir a versão actual no momento em que se reporta o melhoramento, tarefa ou nova funcionalidade ajudará avaliar o estado do produto quando o pedido foi feito.

Afecto a (Assigned To) – Esta será a pessoa a que irá ser responsável pela resolução do problema. Este campo irá ser preenchido por programadores ou equipas responsáveis por módulos.

Reportador (Reporter) – Pessoa que reporta o erro. Este campo é automaticamente preenchido pelo Tracker. Ambiente (Environment) – Especifica qual o sistema operative, plataforma de software e/ou especificações de hardware, se aplicáveis ao erro em questão.

Descrição (Description) – Uma descrição complete e concise do problema ou melhoramento.

Base de dados (Database) – Campo opcional. Se for aplicável ao erro, identifica o tipo de base de dados utilizado. URL – Campo opcional. Se possivel, fornecer o endereço URL que demonstre um exemplo do erro.

Responsável pelos testes (QA Assignee) – Usado para designer o responsável que irá fazer os testes.

Versões reparadas (Fixed Version/s) – Versão do Moodle onde o erro esteve ou irá ser reparado. Basicamente deverá ser pensado em que notas de lançamento irão aparecer as alterações. Este campo é normalmente completado pelo programador quando o erro é dado como resolvido, ou então pelas equipas de desenvolvimento que afectaram os erros a determinada versão. Normalmente apenas uma versão é referida neste campo. Temos assim a indicação de qual a primeira versão onde a alteração irá ser visível.

Exemplo: depois da versão 1.9 ser lançada, ser for reparado um erro na versão MOODLE_19_STABLE, ela irá ser marcada como reparada na versão 1.9.1. Se a reparação for a uma versão anterior, como por exemplo MOODLE_18_STABLE, deverá também ser adicionada na versão seguinte 1.8.x .

Se for resolvido um erro como tudo menos “Reparado” (Não possível de reproduzir, Não Reparado, etc) deixar este campo em branco.

Se for resolvido um erro anteriormente duplicado, deve ser criado um link para o duplicado do erro.

Este campo é usado automaticamente para construir as notas de lançamento da versão (ver http://tracker.moodle.org/browse/MDL).

Anexos (Attachment) - Opcional. Anexar um ficheiro que possa ajudar os programadores e responsáveis por testes a perceber melhor qual o erro. O tamanho máximo do anexo é de 512 Kb.

Comentário (Comment) – O campo destinado aos comentários contém um registo detalhado de todas as alterações feitas a este erro.

Resolution – Este campo apenas está disponível no momento de resolver ou fechar o erro. Deve então ser especificado no cógigo o modo como foi feita a resolução do erro.

Reparado (Fixed) – O erro foi reparado; o código irá ser alterado no sistema CVS. Este código de resolução deve ser usado apenas quando forem feitas alterações ao código do Moodle.

Impossível de reparar (Won't Fix) – O problema descrito diz respeito a um assunto que nunca irá ser reparado.

Não é erro (Not a bug) – Não se trata de um erro; foi erradamente reportado. Use este código se o erro foi anteriormente reportado e reparado numa versão anterior do Moodle.

Duplicado (Duplicate) – O problema é duplicado de outro problema já existente.

Incompleto (Incomplete) – É necessária mais informação para a compreensão do problema.

Impossível de reproduzir o erro (Can't Reproduce) – Todas as tentativas de reproduzir o erro falharam, ou não existia suficiente informação para que fosse possível a sua reprodução. A leitura do código não fornece pistas sobre a razão porque existe determinado comportamento. Se entretanto mais informações relevantes aparecerem, o assunto será novamente reaberto.

Adiado (Deferred) – A resolução do problema será adiada para uma futura versão que será lançada.

Grupos do Tracker e Permissões

Utilizadores normais [groupname=jira-user] - Este é o grupo por defeito. As novas contas de utilizador são colocadas neste grupo na altura da sua criação, e os utilizadores devem ser membros deste grupo para poderem submeter relatórios no Tracker. Os membros deste grupo podem pesquisar erros, criar erros novos, comentar erros, criar anexos, criar sub-tarefas, criar filtros, subscrever erros, e votar em erros. Os membros deste grupo podem também resolver erros, que é primeiramente uma maneira de fechar os erros que são já não relevantes (por exemplo duplicados, ou reportados por engano). Os utilizadores padrão podem configurar seu Tracker que o espaço de trabalho usando o botão "Configure your Issue Navigator". Esta característica permite que os utilizadores vejam as suas subscrições e listas de votos e controlem preferências, perfil, e senhas relativas ao Tracker.

Programadores [groupname=jira-developer] - Os programadores podem fazer tudo o que utilizadores normais podem fazer. Além podem duplicar erros, subscrever erros, editar erros, ligar erros, e atribuir erros. Os membros deste grupo podem também usar a função Bulk Edit que permite a actualização bulk de múltiplos erros.

Responsáveis por testes [groupname=moodle-testers] – Os responsáveis por executar testes, podem fazer tudo o que os programadores fazem.

Grupos de segurança do Moodle [groupname=moodle-security] – Programadores acreditados e administradores que necessitam de trabalhar no sentido de desenvolver competências na área de segurança.

Tipos de ligações

Estão disponíveis os seguintes tipos de ligações:

• Duplicados (duplicates) – duplicados são inevitáveis num projecto com a dimensão do Moodle. Ocorrem quando um utilizador reporta inconscientemente um erro relativo a um problema que já existe. Usa-se assim esta ligação para fazer a conexão entre o outro problema que estará descrito de modo mais compreensivo. Todos erros duplicados devem ser ligados.
• Bloqueador (blockers) – usar esta ligação para a identificação de problemas que estão a bloquear a reparação de outros.
• Clonadores (cloners) –nalguns casos um erros é propositadamente duplicado com o objectivo de reparar outro ramo de código – este sistema quase nunca é usado no projecto Moodle.
• Dependência (dependency) – muitas vezes a reparação de uma falha está dependente de outra falha que deverá ser resolvida primeiro. Este tipo de ligações serve assim para definir a ordem pela qual deveram ser resolvidos erros que são dependentes entre si.
• Correlações (relates) – é usado para identificar um erros que pode de alguma maneira estar relacionado com outro erro existente.

Não receie ligar os erros entre si. As ligações são bidireccionais o que significa que existe um conceito que prevê os dois sentidos da ligação – isto afecta a maneira como os erros são mostrados. Esta é a razão pela qual de poderá ver “bloqueado /está bloqueado por” ou “duplicado/é duplicado de” na lista de ligações “Link Issue”. Não precisa de existir muita preocupação em colocar o tipo correcto de ligação, uma vez que todos funcionam de maneira semenhante.