maplink - proposta processos de teste_v3.ppt

Proposta para Processos de Testes

Agenda●Objetivo●Conceitos básicos de teste●Atividades de Teste no Processo de Desenvolvimento

"As Is"PropostaBacklog TestesTest PlanningTestRejected

●Relatórios de acompanhamento dos testes●Próximos passos

Objetivo

●Apresentar uma proposta de metodologia de testes, para implementação no processo de desenvolvimento da Maplink.

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.

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.



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

● Testes de Confirmação e de Regressão


Atividades de Teste no Processo de

Desenvolvimento - “As Is”BACKLOG

BACKLOGFABRÍCIO

BACKLOGSU

BACKLOG MALOSTE

SELECTED FOR DEVELOPMENT

WAITING TO TEST

TEST

READY TO VALIDATE

DONE

IN PROGRESS

Atividades de Teste no Processo de

Desenvolvimento - Proposta

BACKLOGTESTES

TEST PLANNING

REJECTED

BACKLOG

BACKLOGFABRÍCIO

BACKLOGSU

BACKLOG MALOSTE

SELECTED FOR DEVELOPMENT

WAITING TO TEST

TEST

READY TO VALIDATE

DONE

IN PROGRESS

● 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

BACKLOGTESTES

● 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

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.


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á



● 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)



● 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)



● 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)



● 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)



● Exemplo de Requisito no TestLink:


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


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













● Exemplo de caso de teste construído no TestLink:



● Exemplo de atribuição de requisito a caso de teste no TestLink:


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.



● 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.



● Exemplo da funcionalidade “Adicionar / Remover Plataforma”:



● Exemplo da ordenação da execução dos testes:



● Exemplo da priorização do caso de teste:



● Exemplo da atribuição de casos de teste aos usuários para execução:


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).


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

● Exemplo da funcionalidade “Executar Testes”:


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



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.

Integração JIRA -> TestLink1. 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”:


● Exemplo da associação de Bugs JIRA a um caso de teste:


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”.


● 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

● 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

Relatórios de acompanhamento dos testes

● 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

Questões???

Thank you!maplink.com.br

Sergio Francisco RubioSenior Test Analyst

[email protected]+55 11 97287-6778

mailto:[email protected]

maplink - proposta processos de teste_v3.ppt

Documents