Backlog da equipe de Testes

De MSTECH wiki
Ir para: navegação, pesquisa
Atualizado em 27/03/2017.


Não iniciados / Aguardando

Problema raiz Atividades Status Estimativa Observação / Motivo da pendência
Automatização Definir as diretrizes: quando, quanto e por quê automatizar um teste funcional. Não iniciado

Em andamento

Problema raiz Atividades Equipe de avaliação Data de início Status Estimativa Observação / Motivo da pendência
Estudos e especialização Todo fórum definiremos um assunto de interesse da equipe, que possa agregar qualidade ao trabalho, aumentar a produtividade, técnicas de teste. Um membro da equipe irá preparar uma apresentação de 20 a 30 minutos sobre o tema e apresentar.
Assuntos: ferramentas de automatização, melhores práticas, testes em mobile, testes em api, testes exploratórios, teste em metodologia ágil, etc.
Equipe 16/06/2016 Em andamento
  • 15/09 - André - BrowserSync
  • 29/09 - Taynara - Acessibilidade.
  • 27/10 - Halana - Requisições
  • 10/11 - Taynara e equipe - Automatização
  • 25/11 - André - Automação com Selenium IDE
  • 22/12 - Daniel DevOps - Apresentação do ambiente Loadtest
  • 30/01 - André - Acessando o ambiente Loadtest
  • 30/03 - André - Introdução aos testes de desempenho com o VS Enterprise 2017
Métricas para acompanhar a evolução da melhoria Construção de métricas de projeto e da evolução das frentes: definição de novas métricas Equipe 03/03/2017 Em andamento Outras métricas sugeridas: tempo de resolução dos bugs, acompanhamento dos bugs entre cada sprint. Pensar sobre métricas que não podem ser distorcidas.

Em 04/10/2016 foi criada a página Métricas de teste e qualidade. Foram pesquisadas várias métricas de teste na literatura, e as mais relevantes para o cenário atual foram colocadas na página para discussão e análise.

26/10/2016 - Por conta do MPSBR, continuaremos utilizando as métricas que já temos por enquanto.

16/02/2017 - Já podemos estudar novas métricas.

03/03/2017 - Realizamos um alinhamento com o Escritório de aplicação para apoio na definição de métricas. As métricas de teste serão incorporadas nos indicadores oficiais da empresa. Atualmente temos três indicadores no relatório de bugs: Índice de severidade, Índice de correção e Índice de confiabilidade.

16/03/2017 - Em reunião com a Débora, foram sugeridas novas métricas: custo de não testar e bugs de produção.

Fluxo de trabalho Desenhar os fluxos da área de testes - Processo, classificação, cadastro de bugs Equipe

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

Criado o documento Padrões para o cadastro de bugs.

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. Futuramente iremos definir um padrão de testes de acessibilidade.
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.
Testes de segurança Workshop 01/09/2016 Foi realizado nos dias 25 e 26/08, com duração de 4 horas, um workshop com os fundamentos do teste de segurança. O workshop contou com a teoria de segurança da informação com os principais tipos de ataques. Na prática, fizemos exercícios para tentar realizar ataques, como SQL Injection.
Entender os casos de teste: utilidade, eficácia, armazenamento Verificar armazenamento de casos de teste na Wiki 01/09/2016 Verificamos que a Wiki não é a melhor opção para o armazenamento de casos de teste.
Comunicação entre os testers Além da ferramenta TeamWork, criar uma lista de e-mails para os testers. 05/09/2016 Foi criado o grupo de e-mails testes@mstech.com.br
Padronização de bugs Rever e apontar sugestões no documento de padrões de cadastro de bugs da Wiki 12/09/2016 O documento Padrões para o cadastro de bugs foi atualizado.
Entender os casos de teste: utilidade, eficácia, armazenamento Verificar a ferramenta LeanTesting disponível em www.leantesting.com 15/09/2016 No momento a ferramenta não é adequada.
Entender os casos de teste: utilidade, eficácia, armazenamento Incluir o template na Wiki 29/09/2016 Foi criado o documento Padrões para criação de casos de teste
Alocação Testers precisam ficar próximos ao projeto que estão testando e participar do ciclo 29/09/2016 Através de alinhamento com o Escritório e Diretoria, no momento, não é viável uma bancada específica de testes. É importante que os testers fiquem próximos às equipes de desenvolvimento. Em casos de testes em mais de uma célula, a melhor opção é procurar um lugar entre essas células.
Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar? Melhores práticas: testes com console aberto 29/09/2016 A página Melhores práticas de teste de software foi atualizada.
Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar? Criar guia básico de SQL 29/09/2016 Foi criada a página Guia básico de sql
Entender os casos de teste: utilidade, eficácia, armazenamento Fazer um piloto e armazenar os casos de teste no novo Youtrack, criando os casos de testes como tarefas. 29/09/2016 Foi constatado que esse método de armazenamento de casos de teste não é adequado.
Entender os casos de teste: utilidade, eficácia, armazenamento Apresentar e avaliar proposta de tabela no Youtrack 29/09/2016 O armazenamento de casos de teste na tarefa de testes do Youtrack foi definido como padrão. Foi criado o documento Padrões para criação de casos de teste, onde padronizamos o layout dos casos de teste e o local de armazenamento.
Youtrack: padronização entre os projetos Verificar a padronização nas colunas dos boards. Foi comentado que existem projetos com configurações diferentes. 03/10/2016 Foi definida a seguinte configuração:

Não iniciada – A tarefa ainda não foi iniciada;

Em progresso - Quando o desenvolvedor está realizando a tarefa;

Em espera - Quando o desenvolvedor terminou a tarefa, mas não está liberada para testes;

Submetida - Ambiente atualizado e liberado para testes;

Finalizada - Quando a tarefa já foi testada e fechada;

Impedimentos - Quando há qualquer impedimento.

A definição foi passada ao Escritório de Aplicação para as devidas providências.

Calendario de alocação Construir um calendário com a alocação dos testers 06/10/2016 Foi construído o Mapa de alocação no Blueinfo, disponível em http://blueinfo.mstech.com.br.
Métricas para acompanhar a evolução da melhoria Construção de métricas de projeto e da evolução das frentes: relatório de bugs. 26/10/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.

A Débora passou um documento para auxiliar na elaboração de métricas.

Foi apresentada a proposta no fórum do dia 15/09. A equipe irá avaliar e retornar no dia 29/09. A proposta é que cada tester preencha o documento Excel de relatório de bugs. Esse relatório deve ser anexado a uma tarefa própria na sprint. O Documento será enviado por e-mail.

No fórum do dia 29/09, ficou decidido que:

  • Todos os testers deverão preencher o Relatório de bugs por tipo e severidade por sistema e sprint.
  • A cada sprint, deverá ser criada uma tarefa administrativa no Board para anexo do relatório.
  • O relatório possui a planilha Histórico. A cada sprint, o Analista de testes deverá copiar os dados de histórico das sprints anteriores, para acompanhamento da evolução.
  • Adicionalmente, o relatório poderá ser enviado ao SM por e-mail.
  • O SM deverá apresentar o relatório na retrospectiva.
Teste de desempenho - bugs funcionais Verificar a possibilidade de colocar bugs funcionais encontrados durante os testes de desempenho no backlog do projeto. 26/10/2016 Ao encontrar um bug funcional durante os testes de desempenho:
  • Criar o bug no backlog do produto.
  • No corpo do bug, informar que foi encontrado durante os testes de desempenho.
  • Enviar um e-mail para o PO do produto. Caso o produto não tenha PO, enviar e-mail ao Escritório.
Melhorar a produtividade Tester: como fazer mais? Materiais de estudo: onde e como se especializar? Construir um repositório de conhecimento. 26/10/2016 Os materiais de teste foram adicionados no curso "Testes de software", no endereço https://treinamento.mstech.com.br/course/view.php?id=32
Processo de desenvolvimento - fechamento de tarefas Algumas células, quando terminam o desenvolvimento, colocam a tarefa de DEV como Submetida em vez de Finalizada. Verificar. 27/10/2016 Ficou decidido que:
  • O SM ou outra pessoa designada deverá criar todas as tarefas de teste para cada requisito ou funcionalidade a ser testada;
  • O desenvolvedor, ao terminar sua tarefa, deverá mudar seu status para Finalizada;
  • Só serão testadas os requisitos que possuírem tarefas de teste.
Estimativas de teste estão baixas Verificar junto ao Escritório o problema. Algumas células estão colocando tempo de teste de 5%. 10/11/2016 Em 26/10/2016, passei o problema para a Flávia, que verificou junto à célula. A orientação é que os testers conversem mais com os SMs, sinalizando quando houver algum problema ou divergência.
Métricas de teste Melhorar o relatório de bugs, automatizar através de fórmulas, melhorar os gráficos e layout. 10/11/2016 O relatório foi melhorado: fórmulas, gráficos, inclusão da métrica. Repositório: http://portal.mstech.com.br/base/ct/Documentos%20Compartilhados/Forms/AllItems.aspx
Acessibilidade Criar guia mínimo 10/11/2016 O guia foi criado pela equipe: Guia básico de Acessibilidade
Testes de desempenho Capacitação do teste de desempenho 10/11/2016 A capacitação ocorreu nos dias 13 e 14 e 19/10/2016. Em 26/10, foi proposto um exercício de análise dados, com data de entrega em 04/11.
Testes de desempenho Criação de guias e documentos de apoio 08/12/2016 Foram criados os documentos:

Guia de testes de desempenho

Configurações básicas para acesso ao ambiente de testes de desempenho

Descrição de códigos HTTP

Templates do Perfmon

Contadores de desempenho

Scripts para teste de desempenho

Automatização de testes Criação de guias e documentos de apoio 08/12/2016 Foram criados os seguintes documentos:

Guia de automatização de testes

Funções do Selenium IDE

Expressão regular e XPath

Inclusão de novos campos no relatório de bugs Foi pedido para incluir no relatório de bugs a quantidade de bugs gerados na sprint através dos requisitos e a quantidade de bugs legados incluídos na sprint. 05/01/2017 O relatório de bugs foi atualizado com os campos de bugs legados. O relatório foi armazenado no repositório Base de testes - Documentos
Atualização de documentos Criar guia do BrowserSync 12/01/2017 O guia foi criado e está disponível em Guia de utilização da ferramenta BrowserSync
Criticidade não atende todas as situações Rever a criticidade de bugs que são de layout e usabilidade, pois hoje a definição está coerente para bugs de funcionalidade. 02/02/20/17 Definições:
  • Todos os bugs de usabilidade/conformidade podem ser classificados com a criticidade no máximo Moderado.
  • Foi identificado que a criticidade de um bug funcional pode variar de acordo com a frequência que ocorre, a gravidade e a importância da funcionalidade perante a estória do usuário.
  • Foi identificado que a criticidade de um bug de usabilidade pode variar de acordo com a abrangência e impacto na estória do usuário.

Foram criadas tabelas para auxiliar a classificação da criticidade em ambos os casos.

O documento Padrões para definição de criticidade de bugs foi atualizado.

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. 02/02/2017 Atividade descontinuada. Os testes continuarão a ser realizados nos ambientes fornecidos pelos SMs.
Atualização de documento padrão Rever o padrão definido para o cadastro de bug, pois alguns campos podem ser opcionais. Elaborar um padrão que seja mais flexível e atenda a nossa necessidade do dia-a-dia 16/02/2017 O documento foi atualizado, deixando flexível o preenchimento dos campos de acordo com a necessidade do projeto.
Criticidade de bugs Procurar sinônimos de barreira / obstáculos / ruídos para melhor entendimento das classificações nos bugs de usabilidade. 16/02/2017 As nomenclaturas Barreira, Obstáculo e Ruído são termos técnicos da usabilidade de softwares e devemos nos adequar a esses termos.
Classificações não atendem a todas as situações Rever as classificações de bugs. Motivações:

- Não é intuitivo o fato de categorias não possuírem subcategorias. Causa confusão para classificar.

- Algumas classificações são difíceis de serem identificadas. Ex: Integração.

- Muitas vezes, os bugs são transformados em regras de negócio e não existem classificações para esse caso. Exemplo: Foi aberto um bug para corrigir uma informação errada no relatório gerado para o Ensino Infantil. Após a verificação do bug, decidiram que a Educação infantil não será mais exibia no relatório. Como alterar a classificação e severidade desse bug?

13/03/2017 As classificações foram atualizadas em todos os projetos. As mudanças podem ser vistas na página Padrões para classificação de bugs
Relatório de bugs Atualizar o relatório de bugs com os novos campos: reason, índices. 13/03/2017 O relatório foi atualizado e publicado em Base de testes - Documentos. Relatório de bugs versão 2.0.
Armazenamento dos testes de performance Estudar a possibilidade de implantar um repositório de testes no GIT para armazenamento dos projetos de teste de performance. 12/05/2017
Testes de performance - Visual Studio Implantar o Visual Studio Enterprise como ferramenta de teste de performance no ambiente Loadtest, em conjunto com o JMeter. 12/05/2017