automação de testes para equipes agile

Post on 27-Jun-2015

367 Views

Category:

Documents

3 Downloads

Preview:

Click to see full reader

TRANSCRIPT

Automação de testes para equipes Agile

Alini Gottardi

Apresentação

Alini Gottardi Ciência da Computação, Unicsul, 2004 MBA em Teste de Software, Unieuro, 2012 Certificação CBTS, 2013

Desenvolvedora PHP, Tray Sistemas Coordenadora de Qualidade, Buscapé Analista de Automação, BM&FBovespa Analista de Testes Pleno, Clearsale

Papéis na Área de Teste

Segundo o livro Base de Conhecimento em Testes de Software

Analista de TestesArquiteto de TestesTestadorAutomatizador

Analista de Testes

Planeja, analisa riscos, estabelece prioridades de testes, cria os casos de teste

Arquiteto de Testes

Levanta e instala ferramentas, disponibiliza e configura ambientes, garante infra-estrutura

Testador

Executa os casos de teste, documenta a execução, elabora relatórios, investiga o sistema em tempo de execução

Automatizador

Cria sistemas que testam sistemas...

Imagine o cenário atual

Equipe metodologia cascata

Vamos modernizar! Vamos ser Ágeis!

Novo cenário Agile/Scrum/Kanban...

Novo cenário Agile/Scrum/Kanban...

3 desenvolvedores1 Tester multitarefaO start da equipe é ao mesmo tempoNo primeiro dia de desenvolvimento,

tester já precisa estar trabalhando juntoMas nem há o que testar, o que fazer???No segundo sprint é preciso garantir que o

sprint anterior continua funcionando

Gargalo no testador!!!

Então vamos automatizar os testes!

Cria-se o teste uma só vez e pode ser reexecutado N vezes

A cada novo build, podemos executar a regressão e verificar se não quebrou nada

Um script de teste bem escrito pode ser uma documentação executável, diminuindo tempo de escrita

BDD

Então vamos automatizar os testes!

Cria-se o teste uma só vez e pode ser reexecutado N vezes

A cada novo build, podemos executar a regressão e verificar se não quebrou nada

Um script de teste bem escrito pode ser uma documentação executável, diminuindo tempo de escrita

BDD

BDD - Futuro da Automação?

Três princípios para BDD1.Negócio e Tecnologia deveriam “falar”

sobre um sistema da mesma forma;2.Qualquer sistema deveria ter um valor

identificável e verificável para o “negócio”;

3.Análise, design e planejamento precoce tem, sempre, retorno questionável.

Por que BDD funciona?

BDD se apóia no uso de um vocabulário pequeno e bem específico, o que minimiza “ruídos” na comunicação de forma que tanto TI quanto do negócio estejam alinhados.

A “venda da ideia” para BDD costuma ser mais fácil do que para TDD. Embora, por envolver mais gente, seja mais “trabalhoso” de implantar.

Automação Viva

BDD associa os benefícios de uma documentação formal, escrita e mantida pelo “negócio”, com testes de unidade que “demonstram” que essa documentação é efetivamente válida.

Isso garante que a documentação deixa de ser um registro estático, que se converte em algo gradualmente ultrapassado, em um artefato “vivo” que reflete constantemente o estado atual de um projeto.

Exemplo – Teste Executável

Exemplo - Background

Todos os problemas resolvidos!

Será?????

Todos os problemas resolvidos

Não é bem assim!

Não é bem assim!

Se mal tem tempo de testar, quanto mais automatizar

Escolha da ferramenta (web, desktop, webservice)

Know-how da equipeComplexidade e testabilidade do sistemaPapéis dentro da equipeNão se perder desenvolvendo um sistema

versus criar testes

1) Se mal tem tempo de testar, quanto mais automatizar

Time ágil: todos os membros em busca da qualidade e da entrega

Teste unitário dos desenvolvedores também é testware!

Testador ajuda o desenvolvedor com a massa de teste

Se a automação for complexa, ter um responsável fora da equipe (arquiteto)

2) Não automatizar todos os casos de teste

Manutenção constanteFragilidade do script GUI (Grafic User

Interface)Relevância/prioridade do caso de testeFalsa sensação de que está tudo coberto

3) Não automatizar incertezas

Metodologia ágil é instável, os requisitos mudam todos os dias

Evitar:Módulos com funções ainda a serem

definidasTestes que não serão reutilizadosAutomação leva 3x mais tempo

4) Quando o sistema não é testável

Testes unitários x Sistema em linguagem procedural

Elementos HTML Inacessíveis (problema GUI)

Janelas javascript/popupFuncionalidades transparentes ao usuárioAntes de sair codificando, testador deve

definir seus requisitos de testabilidade

5) Separar os ambientes

Testar no ambientes dos desenvolvedores não dá certo!

Suja a baseEstraga pré-condiçõesSolução:

Fechar builds periódicos do dev para teste

Se houver integração contínua melhor ainda!

6) Realizar estudo das ferramentas

Quem vai usar a ferramenta, qual o seu propósito e quais problemas essa ferramenta irá ajudar a resolver

Que tipo de processo ela irá suportar e em caso de mudanças no processo, a ferramenta pode ou não ser adequada facilmente

Que funcionalidades a ferramenta precisa ter (e.g. quais relatórios devem ser extraídos);

6) Realizar estudo das ferramentas

Quem deve ter acesso à ferramenta e que nível de controle de acesso e administração é necessário

Que tipo de interface com o usuário é necessária (e.g. GUI ou linha de comando);

Com quais plataformas a ferramenta precisa ser compatível;

Qual o orçamento e tempo disponíveis para aquisição e manutenção;

7) Manutenção sempre

O script fica obsoleto muito rapidamente com as mudanças do sistema

Se não for sempre executado, acaba no esquecimento

Dentro do planejamento do sprint prever as manutenções

8) Automação não é somente GUI

GUI = Grafic User InterfaceÉ a primeira que os testers usam e a

primeira que dá dor de cabeçaTestes GUI devem ser usados pra testar

GUI, Smoke Tests, Tarefas sujeitas a erro (fórmulas, partes difíceis, bugs intoleráveis)

Pirâmide da Automação

Agile Testing (Janet Gregory e Lisa Crispin)

9) Não criar sprints cascata

Não esperar dev codificar tudoNão passar apenas automatizando e

testar só no fim

10) Testadores nem sempre são programadoresÓtimos testadores podem não saber

programarProgramadores não possuem técnicas de

testeUtilizar maneiras onde o testador se

preocupe apenas com testes

O que automatizar?

Ferramentas de Automação de Testes FuncionaisFerramentas que permitem reproduzir a

execução manualPossui comandos como clicar, abrir URL,

mover mouse, preencher camposPara encontrar os objetos utiliza

posicionamento do mouse, identificador HTML, Xpath, entre outros

Podem ser utilizadas por meio de interface gráfica ou linha de código

Nossos exemplos utilizam Selenium

Técnicas GUI - Scripts Lineares

Sem laços, ciclos ou condições ifCriada por sistemas Record & Play

Scripts Lineares

Bom para testes que serão pouco reaproveitados. Ex: teste de aceitação, pré-condições

Fácil aprendizado

Massa de dados hard-coded

Script não pode ser compartilhado com outros

Manutenção difícil

Execução frágil

Scripts Estruturados

Código gerado pelo Record & PlayManipulado para conter if, métodos e

outra vantagens da linguagem utilizada

Scripts Estruturados

Scripts Estruturados

Uso livre da linguagem de programação, podendo criar laços, condições, repetições

Separar scripts em módulos para serem reaproveitados

Massa de dados hard-coded

Desenvolvimento extenso

Dependência entre os scripts

Scripts Compartilhados

Abordagem dos scripts estruturados porém os scripts comuns a vários casos de teste

Scripts Compartilhados

Mesmas vantagens do estruturado

Melhor reaproveitamento de scripts

Mesmas desvantagens do estruturado

Mais scripts para manutenção e documentação

Scripts Data-Driven

A massa de dados fica fora do script, armazenada em tabelas HTML, XML ou CSV

Script acessa o arquivo de massa e realiza o teste

Scripts Data-Driven

A massa pode ser criada por um testador não desenvolvedor

Manutenção não envolve os dados

Facilita a reutilização de scripts

Arquitetura inicial demora para ser construída

Exige conhecimentos sólidos de programação

Scripts Keyword-Driven

Abstrai a automação de casos de teste da programação de testes

Scripts são chamados por keywords

Scripts Keyword-Driven

A suite de testes pode ser criada por um testador não desenvolvedor

Desenvolvedor não precisa ser expert em testes

O caso de teste pode ser entendido por leigos

Mesmas desvantagens do Data-Driven

Combinação Keyword-Data-Driven

Reune as duas abordagens, tornando a automação de testes totalmente independente de desenvolvimento e programação

Scripts Keyword-Driven

Possibilidade de criar ferramentas desktop para automação

Curva de aprendizado um pouco maior para os testadores

Perguntas?

Obrigada!

Contato: alini.gottardi@gmail.com

top related