Hoje participei do treinamento no CInTeQ 2010 com a Dorothy Graham e gostaria de passar pra vocês minha experiência em ter participado deste treinamento.
O início
Cheguei bem mais cedo do que estava previsto (as 8:00 e o curso iniciaria as 09:30), mas até aí tudo bem. Desci e tomei um café. Quando a sala estava disponível entrei e me deparei com uma senhora com aparência de vovó (daquelas que dá vontade de apertar os bochechas) sentada. Logo o meu raciocínio lógico e a apurado me diz: essa é a Dorothy.
Objetivos do treinamento
O treinamento, basicamente, segue essa ordem (mas no nosso curso ela fez uma ordem diferente do material que recebemos, diz ela que com o intuito de experimentar para ver se o entendimento fica melhor):
- Planejando e Gerenciando a Automação de Teste
- Técnicas de Desenvolvimento
- Arquitetura de Testes Automatizados
- Pré e Pós processamento
- Comparação da Automação (resultados)
- Recomendações e Direções
Foram colocados alguns pontos interessantes nessa primeira parte.
- A Automação é um projeto (com todos as fases), e ainda é um projeto de desenvolvimento
- Que ele precisa de objetivos bem definidos para ser desenvolvido
- Executar testes tediosos ou difíceis de serem executados manualmente
- Executar Testes de Regressão com maior frequencia
- Garantir a repetibilidade dos Testes Regressivos
- Ter o ROI (Retorno de Investimento) em não mais do que 6 interações de teste
- Melhorar os testes
- Reduzir a equipe
- Reduzir o tempo e custo para arquitetar os testes
- Automatizar todos os testes
Dentro das Métricas de Automação de Teste, podemos citar
- Esforço para automatizar e executar os testes automatizados
- Esforço para desenvolver um novo teste automatizado
- Esforço para analisar as falhas
- Tempo para executar os testes automatizados x testes manuais
- Não medir tudo!
- Escolher três ou quatro métricas
- Coletar e monitoras as métricas por alguns meses
- Trocar a métrica se ela não fazer mais sentido
Sempre que quisermos aplicar a Automação de Testes pela primeira vez, devemos escolher um Projeto Piloto. Devemos lembrar que esse projeto deve:
- Ser pequeno: de 3 a 6 meses e possuir de 3 a 6 pessoas (não é mandatório)
- Não crítico: que não ponha em risco a entrega do projeto
- Conhecer os seus reais objetivos para a Automação de Teste
- Medir o que é importante pra você e sua empresa
- Utilizar de Projetos Pilotos para iniciar com sucesso a Automação de Teste
- Atribuir responsabilidades para a Automação
Técnicas de Desenvolvimento (Scripting Techniques)
As Técnicas de Desenvolvimento de Testes Automatizado tem como objetivos:
- Reduzir custos
- Ter um bom ROI (Retorno de Investimento)
- Aumentar a capacidade dos testes
- Evitar os custos excessivos de manutenção
Linear
O famoso "Record and Playback" (gravar e executar). Ele é rápido de criar mais difícil de manter.
Pode trazer diversas ações duplicadas, que poderiam ser reaproveitadas
O famoso "Record and Playback" (gravar e executar). Ele é rápido de criar mais difícil de manter.
Pode trazer diversas ações duplicadas, que poderiam ser reaproveitadas
Estruturada
Utiliza-se da reutilização de scripts, criando assim uma biblioteca com as ações mais comuns automatizadas e executadas no sistema-alvo (SUT). Reduz custos de manutenção e geração de testes.
Utiliza-se da reutilização de scripts, criando assim uma biblioteca com as ações mais comuns automatizadas e executadas no sistema-alvo (SUT). Reduz custos de manutenção e geração de testes.
Data Driven (Orientada a dados)
São scripts voltado para a massa de dados do teste onde os dados de testes são extraídos dos scripts e colocados em algum local (data source). O controle do script (execução) é feita pela leitura destes arquivos e esta técnica reduz custos de desenvolvimento do scripts, uma vez que os testadores podem criar os data sources.
São scripts voltado para a massa de dados do teste onde os dados de testes são extraídos dos scripts e colocados em algum local (data source). O controle do script (execução) é feita pela leitura destes arquivos e esta técnica reduz custos de desenvolvimento do scripts, uma vez que os testadores podem criar os data sources.
Keywords (Palavras Chave)
São scripts de controle de onde extraímos as instruções mais comuns em alto nível onde colocamos a definição destes scripts em uma linguagem de usuário (requisitos), podendo ser utilizadas em todos os níveis de teste (unitário, teste e aceitação)
São scripts de controle de onde extraímos as instruções mais comuns em alto nível onde colocamos a definição destes scripts em uma linguagem de usuário (requisitos), podendo ser utilizadas em todos os níveis de teste (unitário, teste e aceitação)
Como resumo deste item temos:
- Uma boa técnica aplicada a nossa realizada reduz custos de manutenção
- A técnica de keyword é a mais sofisticada atualmente
Arquitetura de Testes Automatizados
A arquitetura é um fator crítico de sucesso para a automação que deve ser separado da visualização que os testadores tem e que devemos separar os testes da ferramenta.
Na arquitetura devemos pensar nos itens de Testware, como:
- Dados do teste
- Resultados esperados
- Resultados obtidos
- Logs
- Scritps
- Documentos
- Utilitários
- etc... (existe uma série de outros itens de testware)
- As ferramentas podem assumir o conhecimento
- Podemos automatizar mais atividades/tarefas
- Portabilidade dos testes
- Baixa curva de aprendizado
- Precisamos de padrões de configuração para tornar a automação mais eficiente
- Testware
- Criar um boa arquitetura a fim de reutilizar ao máximo os testes
Pré e Pós Processamento
O pré-processamento são todas as atividades iniciais antes de iniciar efetivamente a automação, como a criação dos diretórios, carregamento de dados, etc...
O pós-processamento são todas as atividades quando o script termina sua execução, como a remoção dos arquivos temporários que não serão mais utilizados, remoção dos dados, etc..
Durante o processamento dos testes e sua execução devemos fornecer o status do teste.
A ferramenta não pode ter a certeza que os testes realmente passaram, a ferramenta apenas faz uma suposição se os resultados estiverem dentro do esperado.
O que nós devemos fazer é sempre analisar o resultado obtido da ferramenta e comparar com os resultados esperados.
Comparação da Automação (resultados)
Existem diversos tipos de comparação de resultados da Automação de Teste e diferente forma de faze-los. Padrões para a comparação de resultados nos dá ganhos de eficiência e efetividade.
Existem dois tipos de comparações: as dinâmicas e as de pós-execução.
Comparações dinâmicas:
- Executadas durante a execução dos testes
- Executadas pela ferramenta de teste
- Informações de falha são geralmente gravadas em log.
- Executadas depois que a execução de teste termina
- Muito bom para comparar arquivos ou bases de dados
- Pode ser separado da execução de teste
- Pode ter diferentes níveis de comparação
Recomendações e Direções
Basicamente foi uma resumo de toda a apresentação, onde podemos citar os seguintes pontos:
- Criar scritps usáveis e reutilizáveis
- Selecionar bons candidatos para a automação
- que podem ser executados diversas vezes
- demorados para executar manualmente
- difíceis de executar manualmente
- Começar o Projeto Piloto com poucos testes automatizados (10 a 20 testes)
- Executar a automação em uma versão estável do software
- Executar a automação em uma versão não estável do software, a fim de estudar seu comportamento e impacto
- Medir sempre e criar estratégias para reportar os resultados (ROI)
- Criar padrões para a automação
- Separar a Arquitetura de Automação de Teste em níveis de abstração
A Dorothy tem uma excelente didática, além de dar diversos exemplos de estudo de casos. O interessante é que ela apresentou estudos de casos reais que não deram certo e o porquê de eles não terem dado certo.
Tivemos exercícios de fixação do conteúdo, como responder quais eram objetivos aceitáveis para a automação de teste e quais não eram e no final do dia tivemos um joginho para descontrair e aprender um pouco mais sobre automação.
Links
Site do CInTeQ 2010: http://www.cinteq.com.br/
Site da Dorothy Graham: http://www.dorothygraham.co.uk/
Para ver a cobertura completa do CInTeQ 2010, acesse o blog QualidadeBR do Fabrício Ferrari
- Cobertura CInTeQ 2010 – Dia 1 (parte 1)
- Cobertura CInTeQ 2010 – Dia 1 (parte 2)
- Cobertura CInTeQ 2010 – Dia 2 (parte 1)
- Cobertura CInTeQ 2010 - Dia 2 (parte 2)
- Conclusão do Evento
Abraços!
Legal Elias, participei das palestras do CInTeq e após presenciar a palestra da Dorothy no final do evento fiquei mais interessado ainda em saber como havia sido o treinamento que ela apresentou. Agora com seu post deu pra ter uma idéia.
ResponderExcluirAbração
Olá Antônio!
ResponderExcluirO treinamento foi muito show! Recomendadíssimo!
Pela que ela quase não vem pra cá.