Mudanças entre as edições de "Backlog da equipe de Testes"
De MSTECH wiki
(→Não iniciados / Aguardando) |
(→Em andamento) |
||
| Linha 51: | Linha 51: | ||
| align="center" style="background:#f0f0f0;"|'''Data de início''' | | align="center" style="background:#f0f0f0;"|'''Data de início''' | ||
| align="center" style="background:#f0f0f0;"|'''Status''' | | align="center" style="background:#f0f0f0;"|'''Status''' | ||
| + | | align="center" style="background:#f0f0f0;"|'''Estimativa''' | ||
| align="center" style="background:#f0f0f0;"|'''Justificativa ou pendência''' | | align="center" style="background:#f0f0f0;"|'''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|| | + | | 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|||| |
|- | |- | ||
| − | | 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. | + | | 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. |
| − | + | ||
|- | |- | ||
| − | | 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 | + | | 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|| '''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|| | + | | Calendario de alocação||Verificar a possibilidade de construir um calendário com a alocação dos testers||Mara||07/07/2016||Em andamento|||| |
|- | |- | ||
| − | | 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 || | + | | 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 |||| |
|- | |- | ||
| − | |Alocação||Verificar a ideia de cada tester ficar em projetos fixos.||André / Mara / Ricardo||07/07/2016||Em andamento || | + | |Alocação||Verificar a ideia de cada tester ficar em projetos fixos.||André / Mara / Ricardo||07/07/2016||Em andamento |||| |
|- | |- | ||
| − | |Alocação||Testers ficam sem atividade no começo da sprint (Halana)||André / Mara / Ricardo||07/07/2016||Em andamento || | + | |Alocação||Testers ficam sem atividade no começo da sprint (Halana)||André / Mara / Ricardo||07/07/2016||Em andamento |||| |
|- | |- | ||
| − | |Testers não são considerados no planning||Testers não participam do planning||André / Mara / Ricardo||07/07/2016||Em andamento || | + | |Testers não são considerados no planning||Testers não participam do planning||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 || | + | |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 |||| |
|- | |- | ||
| − | | 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 |||| |
|- | |- | ||
| − | |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 |||| |
|- | |- | ||
| − | | ||Testes de desempenho e segurança - Marcar um workshop (sábado)||Taynara/Paulo/Mara||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|| | + | |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|| | + | |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 | |Entender os casos de teste: utilidade, eficácia, armazenamento | ||
| Linha 88: | Linha 87: | ||
|14/07/2016 | |14/07/2016 | ||
|Em andamento | |Em andamento | ||
| − | | | + | | |
| + | | | ||
|- | |- | ||
|} | |} | ||
Edição das 18h59min de 25 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 | Estimativa | 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 | Paulo / Taynara / Mara | 16/06/2016 | 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 | |||
| Acessibilidade | Não temos profissionais com muita experiência em testes de acessibilidade. É algo interessante para começarmos a estudar. | Equipe de testes | 16/06/2016 | Aguardando | Taynara mandou um material inicial. Vamos conversar sobre essa capacitação | |
| 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 | 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 | Não iniciado | 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. |
| 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 | ||
| 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. | |
| Falta de ambiente de testes | Ensinar os testers a publicar | André / Mara | 07/07/2016 | Não iniciado | ||
| Falta de ambiente de testes | Ambiente exclusivo para testes | André / Mara | 07/07/2016 | Não iniciado |
Em andamento
| Problema raiz | Atividades | Equipe de avaliação | Data de início | Status | Estimativa | 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 | ||
| 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. | |
| 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 | 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 | ||
| 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 | ||
| Alocação | Verificar a ideia de cada tester ficar em projetos fixos. | André / Mara / Ricardo | 07/07/2016 | Em andamento | ||
| Alocação | Testers ficam sem atividade no começo da sprint (Halana) | André / Mara / Ricardo | 07/07/2016 | Em andamento | ||
| Testers não são considerados no planning | Testers não participam do planning | 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 | ||
| Melhores práticas | Melhores práticas: testes com console aberto | Elizabeth | 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 | ||
| 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 |
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. |
