O documento discute a viabilidade e demonstração da automação de testes com QTP. Aborda conceitos como planejamento da automação, análise de viabilidade, ferramentas de automação e uma demonstração prática com QTP. O documento fornece diretrizes para uma automação de testes bem-sucedida.

1. Automação:
Viabilidade e Demo
com o QTP
Marcos José Hermes
marcos_hermes@dell.com

2. Agenda
 Automação de Testes de Software
 Planejamento em Automação
 Viabilidade em Automação
 Conceitos Básicos
 Hands On
 Resumo

3. Expectativa
 Revisar alguns conceitos relacionados à
automação
 Dicas sobre o que deve/não deve ser
automatizado
 Fomentar a discussão sobre diferentes tipos de
automação (não apenas UI)
 Dicas para aumentar a efetividade da
automação
 Ver como o QTP implementa algumas
funcionalidades comuns às ferramentas de
automação

4. Introdução
 Diferentes tipos de testes (e de automação)
 Unit Test, UI, banco de dados, web services, etc.
 Estimativas para escrita X execução de
testes automatizados
 Métricas em automação
 Tempo de escrita, # de execuções,
estabilidade dos scripts
 Automação de necessidades (tarefas) X
automação de testes

5. Automação de Testes de Software
 Automação de teste de software é o uso
de software para controlar a execução
de testes, comparação de saídas
previstas com entradas fornecidas,
configuração de pré-condições de
ambiente e de dados, além de outros
controles de testes e geração de
relatórios.

6. Avaliação de Viabilidade da
Automação: Macro e Micro
 Viabilidade macro diz respeito à
maturidade da empresa para a adoção de
processos de teste com custo baixo e alta
efetividade. Está diretamente ligada à
gerência sênior da empresa.
 Viabilidade micro diz respeito aos cenários
de teste e quão rápido pode-se recuprar o
investimento em dado cenário. Está
diretamente ligada à equipe de testadores.

7. Planejamento em Automação:
Alguns Critérios Importantes
 Planejar o que e quando algo deve ser
automatizado é fundamental
 Estabelecer cronogramas de entregas
 Treinar os usuários dos testes
 Monitorar a execução dos scripts
 Padronizar os processos de desenvolvimento
 Fomentar o reuso de componentes
(bibliotecas de funções e trechos de script)
 Desenvolver aplicações “testáveis”

8. Planejamento em Automação:
Cronogramas de Entrega
 Assim como no desenvolvimento de
aplicações, o desenvolvimento de scripts
automatizados deve seguir um processo
consistente, desde o estabelecimento dos
requisitos do teste, até sua codificação,
teste e aceitação por parte dos usuários
 Hein?! Testar o teste?
 Mas então não é só gravar o script uma vez e
depois reproduzir infinitas vezes?

9. Planejamento em Automação:
Treinamento
 Treinamento aos futuros usuários dos
scripts automatizados é fundamental!
 Os usuários não usarão o que não conhecem
ou não serão efetivos na tarefa
 Além de criar e executar scripts, é preciso
interpretar os resultados das execuções de
maneira correta
 Muitas empresas sofrem com a resistência de
seus testadores, pois eles temem perder seus
empregos (boicote) => quebra de paradigma

10. Planejamento em Automação:
Monitoramento da Execução
 Além de criar excelentes scripts
automatizados, é preciso verificar se os
usuários estão de fato tirando proveito dos
mesmos
O custo do desenvolvimento de scripts é alto
 Para um script “se pagar”, é preciso que ele
seja de fato executado no lugar do seu
equivalente manual
 Estabelecer metas quanto ao uso dos scripts
automatizados

11. Planejamento em Automação:
Padronização do Desenvolvimento
 Projetos de automação devem ser
controlados como projetos reais de
desenvolvimento
A equipe inteira deve seguir um único padrão
de desenvolvimento
 Padrões diminuem os custos do
desenvolvimento e facilitam a manutenção do
código
 Hummm… estamos ainda falando de teste??!

12. Planejamento em Automação:
Reuso de componentes
 Como parte do planejamento, deve-se
identificar os processos comuns dentro da
aplicação e dividí-los em diferentes
componentes, de modo a reutilizá-los em
diversos scripts
 Facilita a codificação, pois basta chamar o
componente em vez de codificar a mesma
função diversas vezes, diminuindo custos
 Facilita a manutenção, pois basta atualizar
um componente para arrumar todos os scripts

13. Planejamento em Automação:
Aplicações Testáveis
 As ferramentas de automação devem ter
acesso direto, simples e consistente
aos objetos de teste da aplicação
O custo de métodos de acesso avançados é
muito superior aos métodos diretos
 A manutenção dos scripts também fica mais
cara
 Como testador, você confia na mensagem
“A operação foi realizada com sucesso”?

14. Tá, mas… e a Viabilidade?
 A automação é viável em empresas maduras, cujos
processos de desenvolvimento sejam mensuráveis e
padronizados, bem como as aplicações a ser testadas
sejam desenvolvidas levando a automação em conta
 A adoção da automação como um requisito não
funcional das aplicações é muito importante
 Além da “viabilidade macro” (a nível de organização),
também devemos avaliar a “viabilidade micro” (a nível
de cenário de teste)

15. Viabilidade Micro: Cenários que
Devemos Automatizar
 Cenários repetitivos (casos de teste diferentes)
e executados com freqüência
 Testes de Performance
 Testes unitários
 Testes de regressão
 Criação de dados
 Smoke tests
 Camada de negócio / Webservices
 Custode manutenção geralmente inferior aos testes
baseados em GUI

16. O que Não Devemos Automatizar?
 Cenários/requisitos que serão alterados
 Execução baixa X custo de manutenção alto
 Scripts que serão executados apenas uma vez (existem
excessões!)
 Cenários novos/instáveis
 “Testes” sem entradas/saídas bem definidas (ad hoc e
exploratórios)
 Testes muito simples ou muito complicados
 Aplicações que não serão alteradas ou em fase de
desligamento/descontinuadas (existem excessões!)
 A quantia de ciclos de teste não paga o custo dos scripts

17. CBA – Cost Benefit Analysis
 Ajuda a identificar os scripts que trarão o maior
retorno ao serem automatizados
 Cálculo simples que leva em conta:
 Número de casos de teste a serem substituídos
 Tempo de desenvolvimento dos scripts manuais e
automatizados
 Ciclos de teste futuros
 Número estimado de execuções por ciclo de teste
 Tempo de execução manual e automatizado (?)
 Algo mais?

18. Ferramentas
 Sim, mas… e a ferramenta de automação??!!
Qual é a mais viável??

19. ATENÇÃO!
 CUIDADO com ferramentas (ou
fabricantes/vendedores de ferramentas) que
prometem resolver todos os seus problemas!
 De nada adianta possuir a melhor ferramenta se
não souber utilizá-la!
 Os scripts apenas fazem o que foram
codificados para fazer!
 Nem tudo deve ser automatizado! Na maioria
dos ciclos de teste haverá tanto scripts
automatizados quanto manuais

20. Viabilidade e a Ferramenta a
ser Escolhida
 Após a análise de viabilidade macro, deve-se
avaliar quais ferramentas disponíveis no
mercado são capazes de atender as
necessidades identificadas
 Deve-se levar em conta:
 Tecnologias suportadas X necessidades da empresa
 Facilidade de uso
 Integração com outras ferramentas
 Custo de licenças ao longo dos anos
 Adaptação a diferentes cenários, simples ou
complexos

21. Viabilidade: Resumo
 Mais importante que a ferramenta de automação, temos
que ter em mente que planejar adequadamente os
testes a serem automatizados é uma parte fundamental
e crítica para o sucesso (CBA, ROI). Além disso, temos
que considerar a forma com que a aplicação foi
codificada (Design for Testability)
 É preciso seguir as boas práticas relacionadas tanto a
desenvolvimento quanto teste manual de software
 Treinamento adequado é essencial para o sucesso da
automação
 Criação e execução de scripts, além de avaliação de resultados
 Ferramentas mal escolhidas tornam-se shelfware

22. Propaganda 
 Oficina de QTP
 Carga horária: 8 horas
 Data: 24 a 27 de maio
 Horário: 19h às 21h
 A distância - web conferência
 Automação de Testes Funcionais com QTP
 Carga horária: 16 horas
 Data: 21 a 24 de junho
 Horário: 18:45 às 22:45
 Local: TargetTrust - Porto Alegre
 Mais Informações em http://www.qualister.com.br (link
"Cursos")
 Vendo AP 2 dorm. Semi-mobiliado, vaga garagem e
depósito – Chácara das Pedras

23. Conceitos Básicos e Demo com
QTP
 Considerações:
 Não é um curso de QTP
 Foco principal em ver como os conceitos são
implementados com uma ferramenta líder no
mercado
 Exemplo simples, para demonstrar conceitos
 Os conceitos são válidos para outras ferramentas
 Existem infinitas maneiras de resolver o mesmo
problema

24. Conceitos Básicos
 Componente de interface (objeto)
 Identificados por propriedades (atributos e valores)
 Comandos básicos
 Clicar, entrar valores, comparar resultados (checkpoint), salvar
dados (output values)
 Cenário de teste
 Caso de teste
 Tipos de teste:
 Record/playback, Keyword driven, Data driven
 Relatórios
 Devem ser completos e consistentes. O usuário deve saber
inequivocamente se o teste passou ou falhou, bem como o
motivo da falha, se for o caso

25. Exemplo de Cenário e Testes
 Cenário de teste: inserir novo usuário
 Casos de teste:

26. Hands On

27. Script Manual
Script Manual
Ações Resultados Esperados
Abra o browser e navegue para a Verifique que a tela de login do backend
URL do Prestashop é exibida
“http://localhost/prestashop/backoffi
ce”
- Entre com o endereço de email na - Verifique que a tela principal do
caixa de texto “E-mail address:” backend do Prestashop é exibida
- Entre com a senha na caixa de - Verifique que o nome do usuário é
texto “Password:” exibido no canto superior direito da tela
- Clique no botão “Connection” do sistema
- Verifique que o applet “Statistics” é
exibido

28. Q&A
 Perguntas?
 Críticas?
 Sugestões?

29. Backup Slides

30. Design for Testability
 Ferramentas de automação precisam manipular
objetos na tela
 Propriedades dos objetos devem estar expostas
 Devem identificar cada objeto de maneira única
 Devem permanecer inalteradas entre as diferentes
sessões de teste
 Usar somente componentes de interface padrões do
toolkit gráfico
 Documentar as camadas de negócio (webservices)

31. Design For Testability - Exemplo
 tabGeral.txtNome
 frmGeral.txtSobrenome
 tabInfoTutor.txtNome
 frmGeral.txtSobrenome