1 - Tarefa de Bug
1.1 - Informações técnicas
1.1.1 - Painel Motivo da Inconsistência
Utilizar o painel do tipo “erro” para documentar o motivo da inconsistência
Nesse painel descrever o motivo da inconsistência, o porquê ela ocorre. Também adicionar os nomes das classes e métodos onde o erro acontece.
1.1.2 - Painel Sugestão da correção
Utilizar o painel do tipo “sucesso” para descrever a sugestão da correção.
Nesse painel descrever o que pode ser feito para corrigir a situação, pode-se adicionar trechos de código como exemplo de como ajustar o bug e também descrever as classes e métodos que precisam ser alterados.
Correto: |
1.2 - Descrição da implementação
Descrever o que foi alterado para resolver o problema.
Utilizar o formato:
Correção: Descrição do que foi alterado.
Motivo: A razão do ajuste que foi realizado.
Observação: esse tópico é utilizado para revisão de código e também para ter documentado o que foi feito para resolver o problema, caso em outro momento for necessário lembrar.
Correto: |
Caso a tarefa possuir reprovação, adicionar um painel do tipo erro com o seguinte formato:
Correto: |
1.3 - Plano de testes
1.3.1 - Checklist de desenvolvimento
Utilizar um painel do tipo sucesso para documentar o “checklist de desenvolvimento”.
Nesse painel, deve-se documentar, em forma de tópico, tudo o que foi ajustado na tarefa.
Ele deve ser feito pensando em quem testará a tarefa, ou seja, não é necessário colocar nome de métodos e classes, apenas documentar, de maneira objetiva e não técnica, todas as correções realizadas.
1.3.2 - Rotinas/Módulos
Utilizar um painel do tipo nota para documentar as “rotinas/módulos”.
Painel para listar todas as rotinas que a correção pode impactar.
1.3.3 - Plano de teste
Utilizar um painel do tipo info para o “plano de testes”.
Nesse painel, deve-se colocar um passo a passo do que fazer para realizar os testes, quanto mais detalhado melhor. Descrever as configurações a serem realizadas para o teste e o comportamento esperado em cada cenário.
Correto: |
2 - Tarefa de Melhoria
2.1 - Informações técnicas
Utilizar o status de análise técnica apenas para mapear os arquivos e métodos que será necessário mexer.
Na documentação, separar os tópicos por projeto, descrevendo os arquivos e métodos a serem criados ou alterados, também é interessante colocar arquivos já existentes para se utilizar como base, caso necessário.
Correto: |
2.2 - Descrição da implementação
Descrever o que foi alterado para resolver o problema.
Utilizar o formato:
Correção: Descrição do que foi alterado.
Motivo: A razão do ajuste que foi realizado.
Observação: esse tópico é utilizado para revisão de código e também para ter documentado o que foi feito para resolver o problema, caso em outro momento for necessário lembrar.
Correto: |
Caso a tarefa possuir reprovação, adicionar um painel do tipo erro com o seguinte formato:
Correto: |
2.3 - Plano de testes
2.3.1 - Checklist de desenvolvimento
Utilizar um painel do tipo sucesso para documentar o “checklist de desenvolvimento”.
Nesse painel, deve-se documentar, em forma de tópico, tudo o que foi ajustado na tarefa.
Ele deve ser feito pensando em quem testará a tarefa, ou seja, não é necessário colocar nome de métodos e classes, apenas documentar, de maneira objetiva e não técnica, todas as correções realizadas.
2.3.2 - Rotinas/Módulos
Utilizar um painel do tipo nota para documentar as “rotinas/módulos”.
Painel para listar todas as rotinas que a correção pode impactar.
2.3.3 - Plano de teste
Utilizar um painel do tipo info para o “plano de testes”.
Nesse painel, deve-se colocar um passo a passo do que fazer para realizar os testes, quanto mais detalhado melhor. Descrever as configurações a serem realizadas para o teste e o comportamento esperado em cada cenário.
Correto: |
Add Comment