Mudanças entre as edições de "Backlog da equipe de Testes"
De MSTECH wiki
(→Finalizados) |
(→Em andamento) |
||
| Linha 40: | Linha 40: | ||
| Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento|||| | | Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento|||| | ||
|- | |- | ||
| − | |Alocação||Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo||André / Mara / Ricardo||07/07/2016||Em andamento |||| | + | |Alocação||Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo||André / Mara / Ricardo||07/07/2016||Em andamento ||'''15/09/2016'''|| |
|- | |- | ||
| − | | Melhores práticas||Melhores práticas: testes com console aberto||Elizabeth||07/07/2016||Em andamento |||| | + | | Melhores práticas||Melhores práticas: testes com console aberto||Elizabeth||07/07/2016||Em andamento ||'''15/09/2016'''|| Terminado. Falta passar para a Wiki. |
|- | |- | ||
|Entender os casos de teste: utilidade, eficácia, armazenamento||Verificar armazenamento de casos de teste na Wiki||Jaqueline||07/07/2016||Em andamento |||| | |Entender os casos de teste: utilidade, eficácia, armazenamento||Verificar armazenamento de casos de teste na Wiki||Jaqueline||07/07/2016||Em andamento |||| | ||
Edição das 15h00min de 2 de setembro de 2016
Atualizado em 22/08/2016.
Não iniciados / Aguardando
| Problema raiz | Atividades | Equipe de avaliação | Data de início | Status | Estimativa | Observação / Motivo da pendência |
| Falta de ambiente de testes | Cada projeto deve ter seu ambiente de testes exclusivo. Ensinar os testers a publicar nos ambientes - O tester deve ser responsável pela configuração do ambiente de testes. | André / Mara | 07/07/2016 | Não iniciado | ||
| Testes de desempenho | Capacitação do teste de desempenho para os demais | Paulo / Taynara / Mara | 16/06/2016 | Aguardando | Aguardando Taynara estar com menos atividades. Procurar alguma capacitação externa para desempenho e segurança | |
| Acessibilidade | Não temos profissionais com muita experiência em testes de acessibilidade. É algo interessante para começarmos a estudar. Incluir nos testes se o comportamento de forms com "tab" está ok | Equipe de testes | 16/06/2016 | Aguardando | 15/09/2016 | No fórum do dia 15/09, Taynara irá realizar uma apresentação de 20 minutos sobre o material pesquisado. A partir daí, iremos estudar e propor um plano de testes básico de acessibilidade. |
| Hoje o teste não é obrigatório para aceite | Na review, apresentar relatório dos bugs para tomada de decisão com o PO. Divulgar isso como parte do processo. | Ricardo / André | 16/06/2016 | Aguardando | 10/09/2016 | O guia para gerar o relatório de bugs já está pronto. Falta apenas divulgar para as células e depois verificar se estão seguindo o processo. |
| Não há uma organização padrão dos casos de testes | Definir o critério de organização dos casos de testes | Equipe de testes | 16/06/2016 | Aguardando | Está sendo utilizada planilha de casos de teste que o Gestão criou. |
Em andamento
| Problema raiz | Atividades | Equipe de avaliação | Data de início | Status | Estimativa | Observação / Motivo da pendência |
| Métricas para acompanhar a evolução da melhoria | Construção de métricas de projeto e da evolução das frentes | André / Ricardo | 07/07/2016 | Em andamento | 15/09/2016 | Construção das métricas de bugs dos projetos. Em relação ao fórum, temos métricas dos itens que já foram resolvidos. Sugestão de montar uma planilha que possa ser utilizada em todas as frentes. |
| Calendario de alocação | Verificar a possibilidade de construir um calendário com a alocação dos testers | Mara | 07/07/2016 | Em andamento | ||
| Alocação | Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo | André / Mara / Ricardo | 07/07/2016 | Em andamento | 15/09/2016 | |
| Melhores práticas | Melhores práticas: testes com console aberto | Elizabeth | 07/07/2016 | Em andamento | 15/09/2016 | Terminado. Falta passar para a Wiki. |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Verificar armazenamento de casos de teste na Wiki | Jaqueline | 07/07/2016 | Em andamento | ||
| Testes de desempenho e segurança - Marcar um workshop (sábado) | Taynara/Paulo/Mara | 07/07/2016 | Em andamento | |||
| Aprendizado de testes não funcionais | Repositório e links para aprendizado | Taynara / Paulo | 07/07/2016 | Em andamento | ||
| 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 | ||
| 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 | ||
| Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar? | Construir um repositório de conhecimento | André / Mara / Samuel | 01/09/2016 | Em andamento | 15/09/2016 | Falamos com o Samuel em 01/09. Iremos criar um repositório no ambiente de treinamento da MSTECH. |
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. |
| 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) | Ressaltar a importância dos testes para a MSTECH | 22/08/2016 | Nos últimos meses os analistas de testes tiveram reuniões com o RH e com o Ricardo. Nessas reuniões ficou bem claro a todos que a MSTECH está engajada na melhoria contínua dos produtos. Os testes são essenciais. |
| Entender os casos de teste: utilidade, eficácia, armazenamento | Avaliar o uso do Youtrack para criação de caso de teste | 22/08/2016 | O Youtrack não se mostrou eficiente no armazenamento de casos de teste. |
| Descrever os testes não funcionais referente à performance | Desenvolver menu, pré-requisitos e questionário | 01/09/2016 | Foi desenvolvido e será publicado na Wiki |
| 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 | 01/09/2016 | Trouxemos a Débora no fórum. O processo de desenvolvimento deixa claro que as tarefas são dadas como concluídas apenas depois dos testes. Deve haver testes. Em caso de irregularidades, devemos procurar o Escritório e o Grupo de qualidade. |
| Alocação | Os testers estão sendo alocados de última hora. Muitas vezes os POs e SMs vão falar direto com o tester. O escritório não tem ciência da alocação. Organizar/Comunicar/Lembrar fluxo de alocação da base. Verificar a ideia de cada tester ficar em projetos fixos. Testers ficam sem atividade no começo da sprint. Testers não são considerados no planning. Testers estão ficando sem alocação / sem resposta do escritório. | 01/09/2016 | Todas as orientações foram passadas para o Escritório de aplicação e Grupo de qualidade, através da Débora que participou do fórum no dia 01/09. As células devem alocar os testers corretamente para que participem do planning, assim como o Escritório deve organizar as alocações para que ninguém fique sem alocação. Devemos contribuir para o processo informando e documentando qualquer irregularidade ou problema encontrado aos responsáveis (falta de alocação, falta de atividades, não participação no planning, etc.). A ideia de que um analista de testes fique fixo no projeto não é viável no momento, visto que há menos analistas do que células. |
