Exibir código-fonte para Backlog da equipe de Testes

 Atualizado em 27/03/2017.


==Não iniciados / Aguardando==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Estimativa'''
| align="center" style="background:#f0f0f0;"|'''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==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Equipe de avaliação'''
| align="center" style="background:#f0f0f0;"|'''Data de início'''
| align="center" style="background:#f0f0f0;"|'''Status'''
| align="center" style="background:#f0f0f0;"|'''Estimativa'''
| align="center" style="background:#f0f0f0;"|'''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 [https://wiki.mstech.com.br/index.php/M%C3%A9tricas_de_teste_e_qualidade 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==

{| {{table}} class="wikitable"
| align="center" style="background:#f0f0f0;"|'''Problema raiz'''
| align="center" style="background:#f0f0f0;"|'''Atividades'''
| align="center" style="background:#f0f0f0;"|'''Data de finalização'''
| align="center" style="background:#f0f0f0;"|'''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 [http://portal.mstech.com.br/base/ct/Documentos%20Compartilhados/Forms/AllItems.aspx 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 [http://portal.mstech.com.br/base/ct/Documentos%20Compartilhados/Forms/AllItems.aspx 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
|
|-
|}