Backlog da equipe de Testes

De MSTECH wiki
Revisão de 16h05min de 28 de junho de 2016 por Andre.iguera (Discussão | contribs)

Ir para: navegação, pesquisa
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