Maplink - Proposta Processos de Teste_v3.ppt

72 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
72
No SlideShare
0
A partir de incorporações
0
Número de incorporações
11
Ações
Compartilhamentos
0
Downloads
7
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Maplink - Proposta Processos de Teste_v3.ppt

  1. 1. Proposta para Processos de Testes
  2. 2. Agenda ● Objetivo ● Conceitos básicos de teste ● Atividades de Teste no Processo de Desenvolvimento "As Is" Proposta Backlog Testes Test Planning Test Rejected ● Relatórios de acompanhamento dos testes ● Próximos passos
  3. 3. Objetivo ● Apresentar uma proposta de metodologia de testes, para implementação no processo de desenvolvimento da Maplink.
  4. 4. Conceitos Básicos de TesteFonte: ISTQB Certified Tester Foundation Level Syllabus (http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_2011br.pdf) ● Erro <> Defeito <> Falha ● Quanto teste é suficiente? ● Testes podem possuir objetivos diferentes: Encontrar defeitos; Ganhar confiança sobre o nível de qualidade; Prover informações para tomada de decisão; Prevenir defeitos.
  5. 5. Conceitos Básicos de TesteFonte: ISTQB Certified Tester Foundation Level Syllabus (http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_2011br.pdf) Os sete princípios do teste: 1. Teste demonstra a presença de defeitos; 2. Teste exaustivo é impossível; 3. Teste antecipado; 4. Agrupamento de defeitos; 5. Paradoxo do Pesticida; 6. Teste depende do contexto; 7. A ilusão da ausência de erros.
  6. 6. Conceitos Básicos de TesteFonte: ISTQB Certified Tester Foundation Level Syllabus (http://www.bstqb.org.br/uploads/docs/syllabus_ctfl_2011br.pdf) Níveis de Teste: ● Teste de Componente ou Unitário ● Teste de Integração ● Teste de Sistema ● Teste de Aceite Tipos de Teste: ● Testes Funcionais ● Testes Não Funcionais ● Testes Estruturais
  7. 7. Atividades de Teste no Processo de Desenvolvimento - “As Is” BACKLOG BACKLOG FABRÍCIO BACKLOG SU BACKLOG MALOSTE SELECTED FOR DEVELOPMENT WAITING TO TEST TEST READY TO VALIDATE DONE IN PROGRESS
  8. 8. Atividades de Teste no Processo de Desenvolvimento - Proposta BACKLOG TESTES TEST PLANNING REJECTED BACKLOG BACKLOG FABRÍCIO BACKLOG SU BACKLOG MALOSTE SELECTED FOR DEVELOPMENT WAITING TO TEST TEST READY TO VALIDATE DONE IN PROGRESS
  9. 9. ● A equipe de testes deverá participar das reuniões de Planning, com a intenção de definir qual Story passará pela equipe de testes. ● Uma vez definido o Story e selecionado para desenvolvimento, o mesmo fará parte de um backlog de testes. Atividades de Teste no Processo de Desenvolvimento - Backlog Testes BACKLOG TESTES
  10. 10. ● Neste momento, serão construídos os casos de testes para as funcionalidades definidas no Story. ● Toda a documentação de teste será produzida no TestLink: ○ Construção dos requisitos (detalhamento do Story); ○ Construção dos casos de testes e atribuição aos requisitos; ○ Construção das instâncias dos casos de teste para execução; ○ Automação dos casos de teste; ○ Construção das instâncias dos casos de teste para execução. Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  11. 11. Construção dos requisitos: ● Um requisito no TestLink deve possuir o nível de detalhe suficiente para a construção dos casos de teste. ● Como sugestão, este detalhamento pode ser efetuado no formato de especificação de caso de uso. Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  12. 12. Construção dos requisitos: ● Exemplo de caso de uso para o story “PSL-187 - Alteração da nomenclatura TAGs” ○ Descrição: ■ Alterar o nome 'TAGS' para 'Categorias' em todos os locais onde esta aparece na ferramenta ○ Fluxo Básico ■ Acessar as telas que contém atualmente o nome "TAGS": ● Tela 1 - Navegação: Menu 1 > Submenu 1 ● Tela 2 - Navegação: Menu 2 > Submenu 2 ● Tela 3 - Navegação: Menu 3 > Submenu 3 ○ Fluxos Alternativos ■ Não há ○ Fluxos de Exceção ■ Não há ○ Regras de Negócio ■ Alterar o nome 'TAGS' para 'Categorias' em todos os locais onde esta aparece na ferramenta ○ Pós-Condições ■ Deve exibir o nome 'Categorias' em todos os locais onde estava o nome "TAGS" aparece na ferramenta ○ Pontos de Extensão ■ Não há ○ Requisitos Especiais ■ Não há Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  13. 13. Construção dos requisitos: ● Estrutura no TestLink: ○ Maplink - Produtos (Projeto TestLink) ■ <Produto Maplink> (Pasta em Requisitos) ● <JIRA Project Key> - <JIRA Project Description> (Subpasta em Requisitos) ○ <Jira Story Key> - <JIRA Story Description> (Requisito) ○ Maplink - Projetos (Projeto TestLink) ■ <JIRA Project Key> - <JIRA Project Description> (Pasta em Requisitos) ● <Jira Story Key> - <JIRA Story Description> (Requisito) ○ Maplink - Serviços (Projeto TestLink) ■ <Serviço Maplink> (Pasta em Requisitos) ● <JIRA Project Key> - <JIRA Project Description> (Subpasta em Requisitos) ○ <Jira Story Key> - <JIRA Story Description> (Requisito) Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  14. 14. Construção dos requisitos: ● Exemplo de Estrutura no TestLink - Produtos: ○ Maplink - Produtos (Projeto TestLink) ■ Store Locator (Pasta em Requisitos) ● PSL - Store Locator (Subpasta em Requisitos) ○ PSL-187 - Alteração da nomenclatura TAGs (Requisito) ○ PSL-208 - Melhorar a escolha de raizes e folhas das categorias (Requisito) ○ PSL-193 - refactoring do design - app (Requisito) ■ Logistics (Pasta em Requisitos) ● RS - PJI2015001 - Projeto Produto Logistica (Subpasta em Requisitos) ○ RS-48 - Implementar skills (Requisito) ○ RS-47 - Adequação da estrutura da api para ambiente de produção (Requisito) ○ RS-43 - Retirar base/garagem de veículos em VehicleRouting (Requisito) Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  15. 15. Construção dos requisitos: ● Exemplo de Estrutura no TestLink - Projetos: ○ Maplink - Projetos (Projeto TestLink) ■ PPJ - PJE2015005 - Projeto JBS (Pasta em Requisitos) ● PPJ-4 - CRUD - Grupo de zonas de restrição (Requisito) ● PPJ-5 - Atribuições de grupos às áreas de restrições (Requisito) ● PPJ-7 - [JBS] Colocar serviço IBGE em homologação. (Requisito) ● PPJ-1 - JBS Análise dos endereços por Revgeo (Requisito) ● PPJ-6 - Subir aplicação em Homologação (Requisito) ■ PPPB - PJE2015006 - Projeto Pag Bem (Pasta em Requisitos) ● PPPB-12 - Adaptar layout aprovado pelo cliente na aplicação. (Requisito) ● PPPB-1 - Adaptar projeto Siga Fácil para Pague Bem (Requisito) Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  16. 16. Construção dos requisitos: ● Exemplo de Estrutura no TestLink - Serviços: ○ Maplink - Serviços (Projeto TestLink) ■ AuthService (Pasta em Requisitos) ● AUT - [MANUT]AuthService (Subpasta em Requisitos) ○ AUT-43 - Desacoplamento dos Modelos e DTO's do Auth com Service Stack (Requisito) ○ AUT-42 - Suporte a Idioma Padrão por Usuário (Requisito) ○ AUT-40 - Implementação de regras de acesso para permitir atualização de um (Requisito) Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  17. 17. Construção dos requisitos: ● Exemplo de Requisito no TestLink: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  18. 18. Construção dos casos de teste e atribuição aos requisitos: ● Criar uma estrutura de pastas semelhante a criada para os requisitos, sendo o Story o último nível de pasta. ● Os casos de teste devem cobrir o máximo de passos definidos nos casos de uso ● Durante a construção dos casos de teste no TestLink, atribuir o requisito correspondente, para possibilitar a rastreabilidade dos casos de teste Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  19. 19. Construção dos casos de teste e atribuição aos requisitos: ● Exemplo de casos de teste para o story “PSL-187 - Alteração da nomenclatura TAGs” Sumário Pré-Condições Ações do Passo Resultado esperado Validar a alteração do nome TAGS exibido na Tela 1 Usuário válido e autenticado no sistema Acessar o menu Menu > Submenu Deve acessar a tela 1 Validar a alteração do nome TAGS Deve exibir o nome “Categorias” ao invés do nome TAGS Validar a alteração do nome TAGS exibido na Tela 2 Usuário válido e autenticado no sistema Acessar o menu Menu > Submenu Deve acessar a tela 2 Validar a alteração do nome TAGS Deve exibir o nome “Categorias” ao invés do nome TAGS Validar a alteração do nome TAGS exibido na Tela 3 Usuário válido e autenticado no sistema Acessar o menu Menu > Submenu Deve acessar a tela 3 Validar a alteração do nome TAGS Deve exibir o nome “Categorias” ao invés do nome TAGS Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  20. 20. Construção dos casos de teste e atribuição aos requisitos: ● Exemplo de caso de teste construído no TestLink: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  21. 21. Construção dos casos de teste e atribuição aos requisitos: ● Exemplo de atribuição de requisito a caso de teste no TestLink: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  22. 22. Construção das instâncias dos casos de teste para execução: ● Neste momento, é definido o plano de execução dos testes. Os seguintes critérios são levados em consideração: ○ Definição da baseline de testes; ○ Definição das plataformas (versões de aplicações e componentes envolvidos no teste); ○ Casos de testes envolvidos na execução, atribuindo o mesmo a suas respectivas plataformas; ○ Definição da sequência da execução dos testes e priorização dos testes; ○ Atribuir casos de teste aos usuários para execução. Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  23. 23. Construção das instâncias dos casos de teste para execução: ● Exemplo da definição da baseline de testes: ○ Ativo / Inativo Define se a baseline está ou não disponível para funcionalidade do TestLink. Baseline inativa não é listado nas páginas de execução e relatórios. ○ Fechado / Aberto Define se os Resultados do Teste podem ser modificados para a baseline. Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  24. 24. Construção das instâncias dos casos de teste para execução: ● Exemplo da funcionalidade “Adicionar / Remover Plataforma”: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  25. 25. Construção das instâncias dos casos de teste para execução: ● Exemplo da ordenação da execução dos testes: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  26. 26. Construção das instâncias dos casos de teste para execução: ● Exemplo da priorização do caso de teste: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  27. 27. Construção das instâncias dos casos de teste para execução: ● Exemplo da atribuição de casos de teste aos usuários para execução: Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  28. 28. Automação dos casos de teste: ● Após a finalização do script de testes, analisar os casos de teste passíveis de automação. Em caso positivo, os mesmos serão automatizados utilizando o Selenium WebDriver; ● Caso já exista automação para algum caso de teste, os mesmos serão associados aos casos de teste no TestLink (mecanismo para associação em estudo). Atividades de Teste no Processo de Desenvolvimento - Test Planning TEST PLANNING
  29. 29. Execução dos casos de teste ● A execução dos testes iniciará após a finalização do planejamentos dos testes, e o deploy da aplicação ou serviço correspondente ao story no ambiente HMLG. ● Toda a execução dos testes deverá ser registrada no TestLink, através da funcionalidade “Executar Testes” ● Qualquer que seja o resultado (Passed ou Failed), toda a execução deverá ser registrada juntamente com a sua evidência ● Entende-se por evidência de teste um screenshot, arquivo de log ou qualquer outro artefato relacionado a execução do teste Atividades de Teste no Processo de Desenvolvimento - Test TEST
  30. 30. ● Exemplo da funcionalidade “Executar Testes”: Atividades de Teste no Processo de Desenvolvimento - Test TEST
  31. 31. ● Exemplo da funcionalidade “Executar Testes”: Atividades de Teste no Processo de Desenvolvimento - Test TEST
  32. 32. Registros de Bugs no JIRA ● Os casos de testes falhos deverão estar associados a um Bug registrado no Story do JIRA. ● Um Bug no JIRA pode estar associado a um ou mais casos de teste falhos, porém não podem existir casos de teste falhos sem um Bug associado ● Bugs seguirão o mesmo processo de desenvolvimento de um Story. ● A correção de um Bug pode demandar ou não um novo planejamento dos testes. ● Na existência de defeitos com prioridade Blocker e Critical, o Story associado deverá passar para o status Rejected Atividades de Teste no Processo de Desenvolvimento - Test TEST
  33. 33. Atividades de Teste no Processo de Desenvolvimento - Test TEST Prioridade de Bugs: ● Blocker: Defeito que bloqueia a execução dos testes como um todo, não possibilitando a continuidade dos testes. ● Critical: Defeito que bloqueia a execução de casos de teste associados a funções vitais à aplicação. ● Major: Defeito associado a funcionalidades previstas nos requisitos, porém que não bloqueiam a execução dos testes. ● Minor: Defeito não associado a requisitos previstos na execução, e que não impedem a aprovação do projeto. ● Trivial: Defeito “cosmético” que não afetam a funcionalidade da aplicação.
  34. 34. Integração JIRA -> TestLink 1. Acessar o TestLink com o usuário “admin” 2. Clicar no link “Issue Tracker Management” 3. Clicar no botão “Create” 4. Preencher os dados conforme a figura abaixo e clicar no botão “Save”: Atividades de Teste no Processo de Desenvolvimento - Test TEST
  35. 35. ● Exemplo da associação de Bugs JIRA a um caso de teste: Atividades de Teste no Processo de Desenvolvimento - Test TEST
  36. 36. Finalização dos testes ● Um teste será considerado como finalizado com sucesso quando: ○ Todos os casos de testes forem executados; ○ Todos os Bugs com prioridade “Blocker” e “Critical” estejam corrigidos; ○ Defeitos com prioridade “Major”, “Minor” e “Trivial” estejam corrigidos, ou que não sejam defeitos impeditivos para deploy em Produção. ● Se os três critérios de finalização acima forem atendidos, será efetuado um “smoke test” no ambiente HMLG, após deploy da aplicação e seus componentes. ● Um Story somente passará para “Ready To Validate” após a conclusão do “smoke test”. Atividades de Teste no Processo de Desenvolvimento - Test TEST
  37. 37. ● Um Story passará para “Rejected” caso todos os testes tenham sido finalizados, porém existam defeitos impeditivos para deploy em Produção. ● Os testes para o Story serão retomados assim que os defeitos forem corrigidos, e o Story passe para “Waiting To Test” novamente. Atividades de Teste no Processo de Desenvolvimento - Rejected REJECTED
  38. 38. ● Periodicidade Diária. ● Agrupados por Equipe de Desenvolvimento e por Sprints. ● Para cada Story, será informado: ○ Progresso da construção dos casos de teste (% de requisitos cobertos pelos casos de teste); ○ Sumário da execução dos testes; ○ Progresso e tendência da execução dos testes; ○ Sumário dos defeitos encontrados. ○ Índice de Qualidade (Defeitos / Casos de teste executados) Relatórios de acompanhamento dos testes
  39. 39. Relatórios de acompanhamento dos testes
  40. 40. Relatórios de acompanhamento dos testes
  41. 41. Relatórios de acompanhamento dos testes
  42. 42. Relatórios de acompanhamento dos testes
  43. 43. Relatórios de acompanhamento dos testes
  44. 44. Relatórios de acompanhamento dos testes
  45. 45. ● Criação de serviço para integração entre os resultados produzidos no Selenium/MSTest e o TestLink; ● Configuração da interface entre o JIRA e o TestLink; ● Definição de modelos para a criação de requisitos e scripts de teste Próximos Passos
  46. 46. Questões ???
  47. 47. Thank you! maplink.com.br Sergio Francisco Rubio Senior Test Analyst sergio.rubio@maplink.com.br +55 11 97287-6778

×