O documento apresenta uma proposta de metodologia de testes para implementação no processo de desenvolvimento de uma empresa. A proposta inclui atividades como a criação de um backlog de testes, planejamento dos testes, execução dos testes e geração de relatórios para acompanhamento.

1. Proposta para Processos
de Testes

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. Objetivo
● Apresentar uma proposta de metodologia de testes, para
implementação no processo de desenvolvimento da Maplink.

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. 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. 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. 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. 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. ● 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. ● 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. 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. 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. 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. 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. 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. 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. Construção dos requisitos:
● Exemplo de Requisito no TestLink:
Atividades de Teste no Processo de
Desenvolvimento - Test Planning
TEST PLANNING

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. ● Exemplo da funcionalidade “Executar Testes”:
Atividades de Teste no Processo de
Desenvolvimento - Test
TEST

31. ● Exemplo da funcionalidade “Executar Testes”:
Atividades de Teste no Processo de
Desenvolvimento - Test
TEST

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. 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. 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. ● Exemplo da associação de Bugs JIRA a um caso de teste:
Atividades de Teste no Processo de
Desenvolvimento - Test
TEST

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. ● 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. ● 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. Relatórios de acompanhamento dos
testes

40. Relatórios de acompanhamento dos
testes

41. Relatórios de acompanhamento dos
testes

42. Relatórios de acompanhamento dos
testes

43. Relatórios de acompanhamento dos
testes

44. Relatórios de acompanhamento dos
testes

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. Questões
???

47. Thank you!
maplink.com.br
Sergio Francisco Rubio
Senior Test Analyst
sergio.rubio@maplink.com.br
+55 11 97287-6778