Um modelo de acompanhamento de erros é um formato predefinido para documentar e comunicar erros no desenvolvimento de software. A utilização de um modelo garante que os detalhes essenciais são registados de forma consistente, permitindo acompanhar e priorizar erros mais facilmente, bem como melhorar a comunicação dentro de uma equipa.
O Jira é uma ferramenta de acompanhamento de problemas da Atlassian e é provavelmente uma das ferramentas de acompanhamento de erros mais populares utilizadas na gestão de projetos de desenvolvimento (especialmente em ambientes ágeis). Utilizei-o em muitos projetos nos últimos anos, tanto com Scrum como com Kanban, e considero-o muito versátil.
Neste artigo, analisarei a versatilidade do Jira no acompanhamento de erros, na personalização e gestão de fluxos de trabalho, bem como no aperfeiçoamento do registo de erros com o Jira.
Quer seja responsável pela configuração dos fluxos de trabalho do Jira, quer comunique defeitos através desta ferramenta, não faz mal saber como funciona. O Jira é mais do que uma simples ferramenta de comunicação de erros, mas neste artigo iremos concentrar-nos mais no acompanhamento de erros do que na gestão de outros tipos de problemas.
Configurar um novo projeto com o Jira Software
Se o seu projeto é novo, a primeira coisa que tem de fazer é configurar o projeto no Jira. Esta tarefa costuma caber ao scrum master ou ao gestor de projeto, mas se a sua função de QA se sobrepuser a uma destas funções, esta tarefa poderá ficar a seu cargo. Não é complicado e, de qualquer forma, deverá ser algo que só terá de fazer uma vez!
O registo é gratuito e, para projetos pequenos com menos de dez utilizadores, pode utilizar o plano gratuito. Se tiver uma equipa maior ou precisar de funcionalidades avançadas, opte por um dos planos pagos. Não entrarei em detalhes, mas pode consultar a página de preços do Jira se tiver interesse.
Criei novos projetos apenas para dar aulas, mas o processo é bastante intuitivo. Terá a opção de escolher entre diferentes tipos de projetos de desenvolvimento de software:
Tipos de projeto
- Um projeto Kanban permite-lhe criar quadros Kanban. Pode utilizar o modelo clássico com as fases clássicas: Por fazer, Em curso e Concluído.
- Scrum - Este modelo permite à equipa gerir os seus sprints e o backlog utilizando a estrutura Scrum.
- Acompanhamento de erros – Um modelo simples que permite acompanhar problemas sem utilizar qualquer metodologia ágil.
Todos os projetos podem ser personalizados para incluir as fases, transições e estados de que o projeto necessita.
Para este tutorial, utilizarei o modelo de projeto Scrum, para que possa acompanhar histórias e erros no mesmo projeto, mas não se preocupe – tudo o que apresento também pode ser aplicado a outros tipos de projeto!
Have an account? Log In
Tipos de problemas
Os tipos de problemas predefinidos fornecidos pelo Jira são:
- Épico: No desenvolvimento ágil, um épico é uma coleção de alto nível de histórias de utilizador e tarefas.
- Erro: O tipo de problema que utilizamos no Jira para acompanhar erros e defeitos encontrados. Iremos concentrar-nos nestes ao longo do resto do artigo.
- História: Uma história de utilizador ágil (a descrição da funcionalidade ou capacidade a desenvolver e testar).
- Tarefa: Normalmente utilizada para acompanhar problemas individuais ou itens por fazer, por exemplo, pesquisar uma nova ferramenta de automatização de testes ou atualizar a documentação.
- Subtarefa: Trata-se de uma tarefa individual atribuída a um membro da equipa e é um problema subordinado ao problema “Tarefa” mencionado acima.
Como já referi, o Jira é muito versátil e, se precisar de criar o seu próprio tipo de problema, pode fazê-lo a qualquer momento no projeto.
Por exemplo, trabalhei num projeto em que tínhamos um tipo de problema separado para melhorias. Estas eram semelhantes às histórias de utilizador, mas estavam sobretudo relacionadas com melhorias de funcionalidades existentes na aplicação.
Ou pode criar um tipo de pedido para casos de teste, mas falaremos disso um pouco mais adiante, quando abordarmos os plugins disponíveis e as ferramentas de integração com o Jira.
Acompanhamento de erros com o Jira
Passando agora ao que nos interessa enquanto testadores — o reporte e o acompanhamento de erros. Embora o Jira seja uma ferramenta de gestão de projetos, e não especificamente uma ferramenta de acompanhamento de erros, nós, enquanto profissionais de QA, iremos provavelmente utilizá-lo para reportar muitos erros 😁.
Fluxo de trabalho e ciclo de vida dos erros
O fluxo de trabalho predefinido para erros (e para todos os pedidos, na verdade) fornecido pelo Jira é o seguinte:
Quando um pedido é aberto, é criado com o estado 'Por fazer'. Depois, o pedido, ou erro, pode ser movido para qualquer um dos outros estados.
A equipa de gestão de testes, o scrum master ou o gestor de projeto estão normalmente encarregados de conceber quaisquer fluxos de trabalho personalizados.
O fluxo de trabalho reflete o ciclo de vida dos erros que pretende ter no projeto. Pode manter o fluxo predefinido e simples, ou torná-lo tão complexo quanto necessário. Sinceramente, nunca trabalhei num projeto que não tivesse os seus próprios estados e transições personalizados.
Para personalizar o ciclo de vida, tem de aceder às definições do projeto, selecionar o tipo de pedido de erro e clicar em 'Editar fluxo de trabalho'.
Aqui, pode adicionar qualquer novo estado e escolher uma transição específica, se necessário. Eis um exemplo:
Neste caso, quando é criado um novo pedido, terá o estado 'Por fazer', a partir do qual só poderá ser movido para 'Em curso'. Depois, antes de o erro poder ser testado, o código tem de ser revisto. A equipa de QA pode fechá-lo assim que for validado no estado 'Em QA'. Naturalmente, a revisão do código e os processos de QA podem falhar e, nesse caso, o erro será movido novamente para 'Em curso'.
Criação de um fluxo de trabalho passo a passo
Irei explicar cada passo necessário para passar do primeiro fluxo de trabalho para o segundo (ou para qualquer fluxo de trabalho personalizado que considere adequado para o seu projeto):
1. Primeiro, clique no botão 'Editar fluxo de trabalho'
2. Para adicionar um novo estado, clique num dos estados — os estados estão divididos em três categorias: 'Por fazer', 'Em curso' e 'Concluído', cada uma com uma cor específica. Pode escolher onde o seu estado se enquadra melhor. Decidi que os estados 'Em revisão de código' e 'Em QA' significam que o pedido ainda está em curso:
Também pode ter outros estados 'Por fazer'; por exemplo, um estado de 'Em revisão', para quando é aberta uma nova funcionalidade e o proprietário do produto ou analista de negócio ainda precisa de adicionar informações sobre a mesma, ou quando a equipa ainda não a refinou nem decidiu sobre a sua complexidade ou estimou os seus pontos de história.
3. Depois de adicionar o novo estado, pode adicionar uma transição para o mesmo. Por predefinição, o estado poderá ser atualizado a partir de qualquer outro estado. Se não quiser regras de transição específicas, não há problema. No entanto, um bom fluxo de trabalho deve permitir que os erros e pedidos sejam movidos apenas para estados específicos depois de passarem por determinadas etapas do processo.
No meu exemplo acima, a equipa de QA não pode começar a trabalhar na verificação da correção antes de outro programador rever o código. Para adicionar esta transição, clique no botão 'Transição' e introduza os detalhes:
4. Também pode eliminar quaisquer transições e estados existentes, se quiser que tudo seja 100% personalizado.
5. Uma funcionalidade bastante interessante são os responsáveis automáticos. Isto também é configurado a partir do fluxo de trabalho, onde pode definir um utilizador responsável predefinido quando é executada uma determinada transição no pedido (este é também um importante benefício do software de acompanhamento de pedidos).
Por exemplo, depois de um erro ser 'Revisto' e passar para 'Em QA', é automaticamente atribuído a um determinado testador ou ao gestor de testes, que decidirá quem trabalhará nele. O mesmo se aplica a 'Em curso' e à equipa de desenvolvimento. Os itens recém-criados podem ser automaticamente atribuídos a um gestor de projeto ou proprietário do produto, que os priorizará no backlog. É altamente personalizável, pelo que pode adaptá-lo da forma que funcionar melhor para a sua equipa.
Mesmo que não seja responsável por configurar os ciclos de vida dos itens, ou que não tenha acesso às definições do projeto, pode consultar o fluxo de trabalho de cada item do Jira expandindo o menu pendente de estado:
Consultar itens no Jira
Se o projeto não for um projeto de acompanhamento de erros, pode consultar os itens atuais nos quadros Kanban ou Scrum:
Isto serve apenas para demonstração; duvido que alguma vez tenha a sorte de ter um sprint com apenas uma história de utilizador e um erro 😅.
Ao clicar em qualquer item, serão apresentados os seus detalhes. Estes incluem, entre outros, um ID, criado automaticamente pelo Jira, um título, uma descrição, o autor do reporte, o responsável e quaisquer anexos ou comentários adicionados pelos membros da equipa.
Os campos também podem ser personalizados, e demonstrarei isso quando discutirmos o que devemos incluir num bom reporte de erro.
Responsáveis
Todos os itens do Jira podem ser atribuídos a um membro específico da equipa. Pode mencionar pessoas nos comentários ou na descrição utilizando o carácter @ antes do nome do utilizador.
Receberá notificações quando alguém o mencionar e quando um item que lhe foi atribuído ou que foi reportado por si for atualizado. Também pode “seguir” itens. Será notificado quando os itens seguidos forem atualizados, independentemente do autor do reporte ou do responsável.
Reportar erros no Jira
Uma aplicação com poucos erros é aquilo por que todos se esforçam, mas sejamos honestos: os testadores ficam sempre satisfeitos quando encontram um bom erro.
Mas um bom erro só é tão bom quanto a forma como o reportamos — um bom reporte de erro garante que este será corrigido com o mínimo possível de trocas entre as equipas de testes e de desenvolvimento. O Jira é uma excelente ferramenta de acompanhamento de erros. Já referi isso? Permite muita flexibilidade.
Para criar um novo item, clique no grande botão 'Criar' e será aberta uma caixa de diálogo. Aqui, selecione o tipo de item 'Erro':
Um bom reporte de erro deve incluir uma boa descrição (ou 'Resumo' no Jira). Deve ser conciso, mas fornecer detalhes suficientes para que fique claro qual é o problema.
Depois, na descrição, adicione todos os detalhes relevantes. Pode estruturá-los de forma clássica:
- Passos para reproduzir
- Resultado esperado
- Resultado real
Depois, inclua quaisquer outros detalhes relevantes para o defeito. As capturas de ecrã ou gravações são sempre uma boa ideia, tal como os registos ou ficheiros específicos utilizados durante a execução.
O Jira permite adicionar campos personalizados aos itens. Gosto de separar a 'Gravidade' da 'Prioridade'. Assim, embora 'Prioridade' seja um campo predefinido adicionado pelo Jira, pode adicionar um campo personalizado para 'Gravidade'.
Outros campos personalizados que vale a pena adicionar podem estar relacionados com o sistema operativo — um campo de texto ou um menu pendente com valores predefinidos, como as versões de Android e iOS utilizadas nos testes, o navegador, o número da compilação ou qualquer outra informação que possa ser relevante ao acompanhar erros.
Para adicionar novos campos, pode aceder às definições do projeto, selecionar o tipo 'Erro' e escolher o tipo de campo de que necessita:
Casos de teste no Jira
A última coisa de que quero falar são os casos de teste. O software Jira pode ser integrado com várias ferramentas de gestão de testes, ou pode adicionar extensões e suplementos da Atlassian, como o Zephyr (que costumava ser o meu favorito) ou o Xray. Quando cria um erro como resultado de um caso de teste falhado, o teste pode ser associado ao erro, o que pode ser muito útil para gerir erros, testes e execução de casos de teste.
Quer saber mais?
O Jira pode ser uma excelente ferramenta de rastreio de defeitos e pode melhorar o processo de desenvolvimento, porque permite uma grande personalização. No que diz respeito aos erros, é realmente útil, porque pode personalizar o fluxo de trabalho para se adequar ao ciclo de vida que pretende ter no seu projeto. Pode associar erros a casos de teste e adicionar campos personalizados da forma que fizer mais sentido para o seu projeto específico.
Para obter mais guias práticos como este, subscreva a newsletter do The QA Lead.
