Mudanças entre as edições de "Backlog da equipe de Testes"
De MSTECH wiki
(→Em andamento) |
(→Em andamento) |
||
| Linha 64: | Linha 64: | ||
'''Estimativa:''' | '''Estimativa:''' | ||
|- | |- | ||
| − | | Entender os casos de teste: utilidade, eficácia, armazenamento||Avaliar o uso do Youtrack para criação de caso de teste||Ricardo / Mara | + | | Entender os casos de teste: utilidade, eficácia, armazenamento||Avaliar o uso do Youtrack para criação de caso de teste||Ricardo / Mara||16/06/2016||Em andamento||'''Estimativa:''' |
|- | |- | ||
| Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento||'''Estimativa:''' | | Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento||'''Estimativa:''' | ||
| Linha 80: | Linha 80: | ||
| Melhores práticas||Melhores práticas: testes com console aberto||Elizabeth||07/07/2016||Em andamento ||'''Estimativa:''' | | Melhores práticas||Melhores práticas: testes com console aberto||Elizabeth||07/07/2016||Em andamento ||'''Estimativa:''' | ||
|- | |- | ||
| − | |Entender os casos de teste: utilidade, eficácia, armazenamento||Verificar armazenamento de casos de teste na Wiki|| | + | |Entender os casos de teste: utilidade, eficácia, armazenamento||Verificar armazenamento de casos de teste na Wiki||Jaqueline||07/07/2016||Em andamento ||'''Estimativa:''' |
|- | |- | ||
| ||Testes de desempenho e segurança - Marcar um workshop (sábado)||Taynara/Paulo/Mara||07/07/2016||Em andamento ||'''Estimativa:''' | | ||Testes de desempenho e segurança - Marcar um workshop (sábado)||Taynara/Paulo/Mara||07/07/2016||Em andamento ||'''Estimativa:''' | ||
Edição das 17h56min de 22 de agosto de 2016
Atualizado em 22/08/2016.
Não iniciados / Aguardando
| Problema raiz | Atividades | Equipe de avaliação | Data de início | Status | Justificativa ou pendência |
| Descrever os testes não funcionais referente à performance | Desenvolver menu | Taynara | 28/03/2016 | Não iniciado | |
| Descrever os testes não funcionais referente à performance | Desenvolver pré-requisitos | Taynara | 28/03/2016 | Não iniciado | |
| Descrever os testes não funcionais referente à performance | Desenvolver questionário | Taynara | 28/03/2016 | Não iniciado | |
| Descrever os testes não funcionais referente à performance | "Não iniciado / em desenvolvimento / entregue /finalizado" - Kanbam | Não iniciado | |||
| Testes de desempenho | Capacitação do teste de desempenho para os demais | Aguardando | Aguardando Taynara estar com menos atividades. Procurar alguma capacitação externa para desempenho e segurança
Estimativa: | ||
| Não há como garantir a qualidade no final da sprint apenas | Definir um ambiente padrão de testes de homologação para a empresa | Não iniciado | Trazer o DEVOPS junto na conversa
Estimativa: | ||
| Acessibilidade | Não temos profissionais com muita experiência em testes de acessibilidade. É algo interessante para começarmos a estudar. | Aguardando | Taynara mandou um material inicial. Vamos conversar sobre essa capacitação
Estimativa: | ||
| Acessibilidade | Incluir nos testes se o comportamento de forms com "tab" está ok | Não iniciado | |||
| Hoje o teste não é obrigatório para aceite | Ricardo / André | Não iniciado | Na review, apresentar relatório dos bugs para tomada de decisão com o PO. Divulgar isso como parte do processo.
Estimativa: | ||
| Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar? | Construir um repositório de conhecimento | Não iniciado | |||
| Não há como garantir a qualidade no final da sprint apenas | No sprint review, envolver o tester para que este indique como aprovado ou não o RF | Mara / Ricardo | Aguardando | Escritório será envolvido; sugestão de nova questão no questionário da retrospectiva; testers mandarão e-mail com parecer
Estimativa: | |
| Não há uma organização padrão dos casos de testes | Definir o critério de organização dos casos de testes | Aguardando | Está sendo utilizada planilha de casos de teste que o Gestão criou.
Estimativa: | ||
| Pra onde caminha o processo de testes na MSTECH? (Seria interessante passar a visão da empresa sobre a importância dos testes no nosso processo de desenvolvimento) | Levar questões para SM e escritório | Ricardo | Não iniciado |
Em andamento
| Problema raiz | Atividades | Equipe de avaliação | Data de início | Status | Justificativa ou pendência |
| Alocação de última hora | Checklist da planning. Perguntas para confirmar se tudo que o PO e SM tinham que fazer para o planning foi feito (especialmente alocação da base) | Karystha, Debora, Mara, Ricardo | 16/06/2016 | Em andamento | Estimativa: |
| Alocação de última hora | Organizar/Comunicar/Lembrar fluxo de alocação da base | Karystha, Debora, Mara, Ricardo | 16/06/2016 | Em andamento | Muitas vezes os POs e SMs vão falar direto com o tester. O escritório não tem ciência da alocação.
Estimativa: |
| Métricas para acompanhar a evolução da melhoria | Construção de métricas de projeto e da evolução das frentes | André / Ricardo | Em andamento | Construção das métricas de bugs dos projetos. Em relação ao fórum, temos métricas dos itens que já foram resolvidos
Estimativa: | |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Avaliar o uso do Youtrack para criação de caso de teste | Ricardo / Mara | 16/06/2016 | Em andamento | Estimativa: |
| Calendario de alocação | Verificar a possibilidade de construir um calendário com a alocação dos testers | Mara | 07/07/2016 | Em andamento | Estimativa: |
| Testers estão ficando sem alocação / sem resposta do escritório. | Verificar o problema com o escritório. | André / Mara / Ricardo | 07/07/2016 | Em andamento | Estimativa: |
| Verificar a ideia de cada tester ficar em projetos fixos. | André / Mara / Ricardo | 07/07/2016 | Em andamento | Estimativa: | |
| Testers ficam sem atividade no começo da sprint (Halana) | André / Mara / Ricardo | 07/07/2016 | Em andamento | Estimativa: | |
| Testers não são considerados no planning | Testers não participam do planning | André / Mara / Ricardo | 07/07/2016 | Em andamento | Estimativa: |
| Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo | André / Mara / Ricardo | 07/07/2016 | Em andamento | Estimativa: | |
| Melhores práticas | Melhores práticas: testes com console aberto | Elizabeth | 07/07/2016 | Em andamento | Estimativa: |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Verificar armazenamento de casos de teste na Wiki | Jaqueline | 07/07/2016 | Em andamento | Estimativa: |
| Testes de desempenho e segurança - Marcar um workshop (sábado) | Taynara/Paulo/Mara | 07/07/2016 | Em andamento | Estimativa: | |
| Falta de ambiente de testes | Ensinar os testers a publicar | André / Mara | 07/07/2016 | Em andamento | Estimativa: |
| Falta de ambiente de testes | Ambiente exclusivo para testes | André / Mara | 07/07/2016 | Em andamento | Estimativa: |
| Aprendizado de testes não funcionais | Repositório e links para aprendizado | Taynara / Paulo | 07/07/2016 | Em andamento | Estimativa: |
| Padronização de bugs | Rever e apontar sugestões no documento de padrões de cadastro de bugs da Wiki | Equipe | 07/07/2016 | Em andamento | Estimativa: |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Verificar a ferramenta LeanTesting disponível em www.leantesting.com | Equipe | 14/07/2016 | Em andamento | Estimativa: |
Finalizados
| Problema raiz | Atividades | Data de finalização | Resolução |
| Não há uma categorização padrão de bugs | Definir categorias | 11/04/2016 | Foi criado o documento Padrões 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 | 11/04/2016 | 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 | 11/04/2016 | 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 |
26/04/2016 | 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 | 09/05/2016 | 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 | 30/05/2016 | Testar funcionalidades aparentes de acessibilidade, como tamanho de fonte e alto contraste. |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Ferramenta de registro de caso de teste: Avaliar o TestLink | 30/05/2016 | 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 |
| Alocação de última hora | Levantar lista do que cada tester já testou | 13/07/2016 | Foi criada uma pesquisa, onde cada Analista de testes respondeu seu nível de conhecimento em cada produto. Os resultados foram tabulados e enviados para o Escritório de Aplicação. |
| Não há uma categorização padrão de bugs | Comunicar os desenvolvedores sobre o uso das classificações | 04/08/2016 | Foi comunicado aos SMs, POs e Desenvolvedores. |
| Não há como garantir a qualidade no final da sprint apenas | Publicar os critérios de aceite (criticidade e categorização de bugs) | 04/08/2016 | Foram publicados os critérios de aceite e divulgado nas reuniões de PO e SM. |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Avaliar se há algum plugin gratuito do GitLab para test case | 04/08/2016 | Foi considerado o uso do Youtrack para criação de casos de testes. |
| Não há uma categorização padrão de bugs | Criar guia para geração de relatórios de bugs do Youtrack. | 22/08/2016 | Foi criado o Guia para geração de relatórios de bugs do Youtrack. Assim os analistas de testes e demais interessados podem gerar os relatórios no Youtrack. |
