Mudanças entre as edições de "Backlog da equipe de Testes"
De MSTECH wiki
(Criou página com ' Atualizado em 16/06/2016. {| {{table}} class="wikitable" | align="center" style="background:#f0f0f0;"|'''Problema raiz''' | align="center" style="background:#f0f0f0;"|'''Ati...') |
|||
| Linha 4: | Linha 4: | ||
| align="center" style="background:#f0f0f0;"|'''Problema raiz''' | | align="center" style="background:#f0f0f0;"|'''Problema raiz''' | ||
| align="center" style="background:#f0f0f0;"|'''Atividades''' | | align="center" style="background:#f0f0f0;"|'''Atividades''' | ||
| − | | align="center" style="background:#f0f0f0;"|''' | + | | align="center" style="background:#f0f0f0;"|'''Data''' |
| align="center" style="background:#f0f0f0;"|'''Resolução''' | | align="center" style="background:#f0f0f0;"|'''Resolução''' | ||
|- | |- | ||
| − | |Não há uma categorização padrão de bugs||Definir categorias|| | + | |Não há uma categorização padrão de bugs||Definir categorias|| ||Foi criado o documento [[Guia para classificação de bugs]] |
Novos campos de classificação adicionados ao TFS e ao Youtrack (apenas em projetos criados a partir de 25/05/2016). | Novos campos de classificação adicionados ao TFS e ao Youtrack (apenas em projetos criados a partir de 25/05/2016). | ||
|- | |- | ||
| − | |Não há como garantir a qualidade no final da sprint apenas||Definir critérios de aceite de um requisito|| | + | |Não há como garantir a qualidade no final da sprint apenas||Definir critérios de aceite de um requisito|| || 1. Requisito finalizado (todas as tarefas da sprint para o requisito terminadas) |
2. Testes unitários aprovados (passou ou não) - Opcional | 2. Testes unitários aprovados (passou ou não) - Opcional | ||
| Linha 21: | Linha 21: | ||
5. Aprovação do PO (PO aprovaria requisito com baixa criticidade) | 5. Aprovação do PO (PO aprovaria requisito com baixa criticidade) | ||
|- | |- | ||
| − | |Entender como o desenvolvedor recebe o bug: o que pode ser melhorado?||Pesquisa com desenvolvedores|| | + | |Entender como o desenvolvedor recebe o bug: o que pode ser melhorado?||Pesquisa com desenvolvedores|| ||Vídeos só em casos em que o problema é complicado de explicar |
Imagens - utilizar anotações na imagem e anotar, no nome da imagem, uma descrição rápida do bug + data | Imagens - utilizar anotações na imagem e anotar, no nome da imagem, uma descrição rápida do bug + data | ||
| Linha 33: | Linha 33: | ||
Apresentar planilha usada pela célula do Gestão | Apresentar planilha usada pela célula do Gestão | ||
| − | || | + | || ||Realização de Dojo na construção de casos de teste |
Avaliação do TestLink | Avaliação do TestLink | ||
|- | |- | ||
| − | |Solicitações para não cadastrar bugs||Alinhamento com a equipe de testes|| | + | |Solicitações para não cadastrar bugs||Alinhamento com a equipe de testes|| ||Bugs devem ser cadastrados sempre. Se foi aberto por engano, deve ser fechado, e não excluído. Não há exceções. |
|- | |- | ||
| − | |Acessibilidade||Definir escopo dos testes|| | + | |Acessibilidade||Definir escopo dos testes|| ||Testar funcionalidades aparentes de acessibilidade, como tamanho de fonte e alto contraste. |
|- | |- | ||
| − | |Não há uma categorização padrão de bugs||Definir critérios para a priorização de severidade|| | + | |Não há uma categorização padrão de bugs||Definir critérios para a priorização de severidade|| ||Criado critério de severidade inicial. Será publicado na Wiki. |
|- | |- | ||
| − | |Entender os casos de teste: utilidade, eficácia, armazenamento||Ferramenta de registro de caso de teste: Avaliar o TestLink|| | + | |Entender os casos de teste: utilidade, eficácia, armazenamento||Ferramenta de registro de caso de teste: Avaliar o TestLink|| ||Testlink foi avaliado e, nesse momento, não parece adequado para nossa realidade. Revisitar futuramente. |
| + | |- | ||
| + | |Como é o apontamento de sugestões de melhorias? | ||
| + | |Estudar como registrar QoS de forma que o PO, o SM, o tester e a empresa tenham acesso. | ||
| + | |16/06/2016 | ||
| + | |Pesquisa indicou que as empresas não usam QoS. Será utilizado Bug com criticidade "Melhoria" | ||
| + | |- | ||
| + | |Não há uma categorização padrão de bugs | ||
| + | |Definir critérios para a priorização de severidade | ||
| + | |16/06/2016 | ||
| + | | Foi criado o documento [[Padrões para definição de criticidade de bugs]] | ||
| + | |||
|} | |} | ||
Edição das 16h05min de 28 de junho de 2016
Atualizado em 16/06/2016.
| Problema raiz | Atividades | Data | Resolução |
| Não há uma categorização padrão de bugs | Definir categorias | Foi criado o documento Guia para classificação de bugs
Novos campos de classificação adicionados ao TFS e ao Youtrack (apenas em projetos criados a partir de 25/05/2016). | |
| Não há como garantir a qualidade no final da sprint apenas | Definir critérios de aceite de um requisito | 1. Requisito finalizado (todas as tarefas da sprint para o requisito terminadas)
2. Testes unitários aprovados (passou ou não) - Opcional 3. Testes funcionais (pelos testers ou teste cruzado) Como comprovar teste cruzado? Criar tarefa e o escritorio validar se foi realizado 4. Review ser no ambiente de Homologação Interna - opcional 5. Aprovação do PO (PO aprovaria requisito com baixa criticidade) | |
| Entender como o desenvolvedor recebe o bug: o que pode ser melhorado? | Pesquisa com desenvolvedores | Vídeos só em casos em que o problema é complicado de explicar
Imagens - utilizar anotações na imagem e anotar, no nome da imagem, uma descrição rápida do bug + data Tudo, até ortografia, deve ser registrado Anexar também evidências de que o item foi corrigido | |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Realizar dinâmica para cada um apresentar como descrever caso de teste
Como tratar o armazenamento dos casos de teste pensando no reaproveitamento deles Apresentar planilha usada pela célula do Gestão |
Realização de Dojo na construção de casos de teste
Avaliação do TestLink | |
| Solicitações para não cadastrar bugs | Alinhamento com a equipe de testes | Bugs devem ser cadastrados sempre. Se foi aberto por engano, deve ser fechado, e não excluído. Não há exceções. | |
| Acessibilidade | Definir escopo dos testes | Testar funcionalidades aparentes de acessibilidade, como tamanho de fonte e alto contraste. | |
| Não há uma categorização padrão de bugs | Definir critérios para a priorização de severidade | Criado critério de severidade inicial. Será publicado na Wiki. | |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Ferramenta de registro de caso de teste: Avaliar o TestLink | Testlink foi avaliado e, nesse momento, não parece adequado para nossa realidade. Revisitar futuramente. | |
| Como é o apontamento de sugestões de melhorias? | Estudar como registrar QoS de forma que o PO, o SM, o tester e a empresa tenham acesso. | 16/06/2016 | Pesquisa indicou que as empresas não usam QoS. Será utilizado Bug com criticidade "Melhoria" |
| Não há uma categorização padrão de bugs | Definir critérios para a priorização de severidade | 16/06/2016 | Foi criado o documento Padrões para definição de criticidade de bugs |
