O documento apresenta uma disciplina sobre automatização de testes. Ele discute os problemas do processo de teste manual, ferramentas de teste como TestLink e Mantis, e como migrar casos de teste de um processo manual para essas ferramentas.
2. Roteiro
• Apresentação
• A Disciplina
• Problemas da fase anterior
• Gerenciamento do processo de testes
• O paradigma Open Source vs Proprietário
• Tipos de ferramentas
• Ferramentas padrão(exercícios)
• Outras ferramentas
• Ferramentas Proprietárias
• Vantagens e desvantagens
• Atividade
3. Apresentação
• Quem sou eu ?
– Roberto Alves: Engenheiro de testes no
C.E.S.A.R (Centro de Estudos e Sistemas
Avançados do Recife) Professor em testes
na Gotest, e Fuctura Tecnologia, IBM
Certified Especialist – Software Quality.
• Quem são vocês?
4. Apresentação da Disciplina
• Metodologia:
– Foco prático
– Baseada em atividades e apresentações
• Avaliação:
– participação : 2 pontos
– Apresentação : 8 pontos
será avaliado na apresentação:
- organização
- migração da estratégia de teste
- apresentação do grupo
- justificativa da escolha das ferramentas
5. Atividade
• Encontre o maior número de problemas
que se pode ter ao utilizar o processo de
testes de forma “manual” , sem o auxílio de
ferramentas para gerência de processo e
controle de bugs, atividades e execuções.
• Dividir a turma em equipes.
6. Gerenciamento do Processo de Testes
• A gestão de testes é a parte principal de
um processo de testes. A gestão
é importante para o planejamento e
controle das atividades de um projeto de
teste.
• Se torna difícil manter grandes projetos
de testes.
7. O combate mundial:
SW open source x SW proprietário
• Qual usar?
Identificando Aspectos funcionais.
• Quando usar?
– O momento é de crise?
• Por que usar?
– Será que aquele é melhor?
• Vantagens e desvantagens de cada um.
– levantando pontos fortes e fracos.
8. Tipos de ferramentas
• Gestão de testes
– Ferramentas que automatizam o
gerenciamento dos testes(criação de casos
testes, execução, controle, analise e etc.)
• Gestão de bugs
– ferramentas que automatizam o ciclo de
vida de um bug.
9. • Controle/gerência da matriz de rastreabilidade
• Rastreabilidade:
– representação visual em forma de matriz
bidimensional onde é feito o relacionamento
entre os artefatos, marcando-se o quadrante das
linhas com as respectivas colunas visando o
correto relacionamento dos itens na matriz. Com
isso cria-se uma visão global de todo
ecossistema de modelos e artefatos do sistema
sendo desenvolvido.
10. Ferramentas Padrão
• Ferramentas que iremos utilizar como
padrão da disciplina:
gestão de testes : TESTLINK
gestão de bugs : MANTIS
11. Testlink
• Ferramenta open source web baseada no
Gerenciamento e Execução dos testes;
• Permite criar e gerenciar os casos de
testes, bem como organizá-los nos planos
de testes;
• O time de testes pode executar os CTs,
priorizá-los, associá-los para um
responsável e acompanhar o resultado
dinamicamente, gerando relatórios.
12. Adaptação ao processo
• Plano de Testes
– Seção de Estratégia deve estar alinhada
com a ferramenta TestLink
• Projeto de Testes
– Ferramenta disponibilza geração automática
do documento.
• Planilha de Resultados dos Testes
– A ferramenta disponibiliza relatórios para os
resultados dos testes.
13. • Na ferramenta TestLink
– É uma “boa prática” criar suites com o nome do
requisito/caso de uso para facilitar a rastreabilidade
– Para cada Caso de Teste
• Indicar no campo Summary as informações
sobre:
– Tipo de teste, objetivo, cenário, pré e pós-
condições ...
– As baselines devem ser cadastradas como
Builds na ferramenta TestLink
• Os SQAs avaliam o resultado final a partir dos
relatórios disponibilizados na ferramenta
14. • A ferramenta TestLink não contempla:
– Dependência entre casos de testes
– Não existe o campo de tempo de execução
– Não existe a matriz geral de rastreabilidade
15. Adaptação plano de testes
• Plano de Execução de Testes (PET) da
ferramenta TestLink
– Estará inserido na Estratégia de Testes
– Deve existir um PET para cada ciclo de testes
planejado
Deve estar alinhado com os PETs do ferramenta TestLink.
20. Lista de PETs
Para cada ciclo previsto no Plano de Testes será criado um PET na ferramenta
TestLink.
No Plano de Testes deve ser indicado o mesmo nome para cada ciclo.
21. Detalhes de um PET
Informar a versão ou do plano de projeto
que contém o planejamento desde ciclo
(PET).
36. Para cada suite de teste, indicar os CTs a serem executados para o ciclo
de testes conforme PET da ferramenta TestLink.
Indicar a versão do CT que entrará em execução (saber qual a versão
revisada).
49. Relatórios de Testes
Selecione a opção do formato do relatório e depois clique no
relatório.
Automaticamente abrirá uma tela para salvar o resultado.
50. Para cada build vai existir uma coluna com os resultados.
Essas builds são do PET-G1, por isso para cada ciclo de
testes é necessário um PET novo.
51. Outras ferramentas
• Gestão de testes
rth http://www.rth-is-quality.com
TestMaster http://testmaster.sourceforge.net
Test Case Web http://tcw.sourceforge.net
Testopia http://www.mozilla.org/projects/test
opia
52. RTH
• RTH (Requisitos e Testes Hub) é um sistema open-source
que funciona como instrumento de gestão de testes,
também possui capacidade de gestão de requisitos e de
bug-tracking.
• Algumas funcionalidades:
- Interface gráfica mais intuitiva
- Capacidade de versionar mudanças em requisitos e
documentos anexos
- Visão dos requisitos como uma árvore hierarquizada
- Definição mais granular dos passos de um caso de teste
e das possíveis falhas
- Discussões(estilo fórum) em requisitos
53. TestMaster
• Ferramenta que apoia a gerenciamento
de casos de testes, bem como suas
execuções.
• Possui suporte a algumas automações
em aplicações web(testes de carga entre
outros).
54.
55. Test case web
• Ferramenta desenvolvida em PHP e
SQL que dá suporte a gerência de casos
de teste.
56.
57. Testopia
• Testopia é uma ferramenta de teste gestão
de testes , é extensão para o Bugzilla.
• É concebido para ser um instrumento
genérico para monitorar casos de teste,
permitindo a testagem para integrar os
bugs e os relatórios de casos de teste
executados e seus resultados.
58. Atividade
• Migrar o projeto de testes feito na
disciplina anterior para o testlink.
1,5h
59. Mantis
• O mantis é um gerenciador de erros
(bugtracker) desenvolvido e PHP e
trabalha com bando de dados MySQL e
PostgreSQL. Tem uma interface gráfica
voltada para web e é acessado através
de um browser qualquer.
• Automatiza o ciclo de vida de um bug.
70. Severity
• Deverá ser escolhida a severidade do BUG
– Not applicable
– Minor
– Normal
– Major
– Critical
– blocker
71. Normal
Um problema moderado que restringe, mas não impede, o usuário de realizar a
função desejada. O cliente provavelmente ignorará o problema ou encontrará um
caminho alternativo. Os problemas conhecidos com esta severidade podem ser
liberados em um produto somente se os riscos forem avaliados, documentados, e
aprovados pelo gerente de projeto.
Minor
Um problema menor que não impeça o usuário de realizar as funções desejadas. O
cliente pode ou não perceber o problema, e é improvável registrar uma queixa. A
percepção do cliente da qualidade de produto pode ser danificada se diversos
problemas como essa severidade forem evidentes. A correção destes problemas
pode ser adiada para um release seguinte sem justificação formal.
Trivial
Um problema transparente invisível ao cliente. A correção destes problemas pode
ser adiada para o próximo release sem justificação formal.
72. Blocker:
Um problema que impede a continuação dos trabalhos sobre o produto
até seja resolvido.
Critical
Um problema crítico que faz o produto do trabalho inadequado para o
uso e/ou ser incapaz prestar os serviços. Os problemas desta severidade resultam
geralmente na substituição ou no reparo de todos os produtos que contêm o artigo
defeituoso. Se o produto não ainda tiver sido enviado com o defeito, o defeito fará
com que o produto fique inadequado para a entrega até que esteja resolvido.
Major
Um problema sério que produza a perda intermitente das funcionalidades
ou degrade o desempenho. Os problemas desta severidade usualmente resultam
numa descontinuação da produção e distribuição do produto até que o problema
seja corrigido.
73. Priority
• Deverá ser escolhida a prioridade do BUG
– None
– Low
– Normal
– Hight
– Urgent
– immediate
74. Found in
• Deverá ser informado o LABEL do release onde o
problema foi encontrado.
Baselined in
Baselined in
Campo não obrigatório, particular de cada projeto, ou
estratégia.
75. Assign To
• Todo BUG deve ser atribuído a alguém pra ser
solucinado seja para um desenvolvedor , ou até mesmo
para um gerente.
Target Version
Target Version
Não necessário
76. Summary
• Título do problema encontrado
Description
Description
Descrição detalhada do problema
77. Steps To Reproduce
• Informações para reproduzir o erro, se necessário.
CCB Comments
CCB Comments
Não necessário(no momento)
Review Records
Review Records
Não necessário(no momento)
78. Type
• Deverá ser escolhida tipo do BUG, usar
apenas os tipos:
– Software Defect
– Document Defect
79. Upload File
• Anexar arquivo a requisição, se necessário
View Status
View Status
(x) private (restringe a visualização por projeto)
Report Stay
Report Stay
[ ] Não necessário
87. Outras ferramentas
• Gerência de bugs:
Scarab http://scarab.tigris.org
BugNET http://www.bugnetproject.com
TRAC http://trac.edgewall.org
88. Scarab
• Scarab é um sistema de monitoramento
de artefatos altamente personalizável.
• Scarab é construída utilizando tecnologia
Java Servlet para velocidade,
escalabilidade, capacidade de
manutenção e facilidade de instalação.
89. Bugnet
• BugNET é uma ferremaneta de
monitoramento e solução da gestão de
projetos construída usando ASP.NET.
• Diponibiliza :
– Notificações por e-mail
– Elaboração de relatórios por projeto e
configuração de campos e valores.
– Permite uma gestão eficiente de bugs,
característica pedidos, e outros temas para
projetos de qualquer escala.
90.
91. Trac
• Sistema de monitoramento de bugs,
gerenciamento de projetos e wiki
intergrado.
• fornece uma interface para Subversion
(ou outros sistemas de controle de
versão).
93. Ferramenta sobre rastreabilidade
• Durante a criação de um projeto de
software que use metodologias como,
por exemplo, RUP e OpenUP, são
criados muitos artefatos como diagramas
e documentação. E nesta grande
quantidade de artefatos é necessário
saber quais têm relação entre si. Isso é
feito utilizando-se das matrizes de
rastreabilidade.
94. TRAMA
• Ferramenta desenvolvida em java que
automatiza a criação de matrizes de
rastreabilidade.
• Trabalha com foco em projetos, podendo
ser salvos e exportados.
• Permiti customização e criação de
plugins
95.
96. Atividade
• Utilizando a ferrementa TRAMA crie uma
matriz de rastreabilidade dos seus teste
ligados com seus requisitos.
• Utilizando a ferrementa TRAMA crie uma
matriz de rastreabilidade dos seus bugs
ligados com seus Testes.
97. Ferramentas proprietárias
• Atividade:
pesquisar para cada tipo de ferramenta
mostrado(gestão de testes e Controle de
bug) ferramentas pagas que se igualam
ou superem as ferramentas mostradas,
identificar vantagens e desvantagens( no
mínimo 5 de cada).
98. Apresentação
• Migrar o projeto de testes para a
ferramenta que o grupo escolher. Fazer
no mínimo 3 ciclos de execução para
apresentação do relatório de testes.
Entregar antes da apresentação uma
cópia do Plano de Testes feito na
disciplina anterior.