Automação de testes paraequipes AgileAlini Gottardi
Apresentação Alini Gottardi Ciência da Computação, Unicsul, 2004 MBA em Teste de Software, Unieuro, 2012 Certificação ...
Papéis na Área de TesteSegundo o livro Base de Conhecimento emTestes de SoftwareAnalista de TestesArquiteto de TestesTe...
Analista de TestesPlaneja, analisa riscos, estabeleceprioridades de testes, cria os casos deteste
Arquiteto de TestesLevanta e instala ferramentas, disponibilizae configura ambientes, garante infra-estrutura
TestadorExecuta os casos de teste, documenta aexecução, elabora relatórios, investiga osistema em tempo de execução
AutomatizadorCria sistemas que testam sistemas...
Imagine o cenário atualEquipe metodologia cascata
Vamos modernizar! Vamos ser Ágeis!
Novo cenário Agile/Scrum/Kanban...
Novo cenário Agile/Scrum/Kanban...3 desenvolvedores1 Tester multitarefaO start da equipe é ao mesmo tempoNo primeiro d...
Gargalo no testador!!!
Então vamos automatizar os testes!Cria-se o teste uma só vez e pode serreexecutado N vezesA cada novo build, podemos exe...
Então vamos automatizar os testes!Cria-se o teste uma só vez e pode serreexecutado N vezesA cada novo build, podemos exe...
BDD - Futuro da Automação?Três princípios para BDD1.Negócio e Tecnologia deveriam “falar”sobre um sistema da mesma forma...
Por que BDD funciona?BDD se apóia no uso de um vocabuláriopequeno e bem específico, o queminimiza “ruídos” na comunicação...
Automação VivaBDD associa os benefícios de umadocumentação formal, escrita e mantidapelo “negócio”, com testes de unidade...
Exemplo – Teste Executável
Exemplo - Background
Todos os problemas resolvidos!Será?????
Todos os problemas resolvidosNão é bem assim!
Não é bem assim!Se mal tem tempo de testar, quanto maisautomatizarEscolha da ferramenta (web, desktop,webservice)Know-h...
1) Se mal tem tempo de testar, quantomais automatizarTime ágil: todos os membros em busca daqualidade e da entregaTeste ...
2) Não automatizar todos os casos detesteManutenção constanteFragilidade do script GUI (Grafic UserInterface)Relevância...
3) Não automatizar incertezasMetodologia ágil é instável, os requisitosmudam todos os diasEvitar:Módulos com funções ai...
4) Quando o sistema não é testávelTestes unitários x Sistema em linguagemproceduralElementos HTML Inacessíveis (problema...
5) Separar os ambientesTestar no ambientes dos desenvolvedoresnão dá certo!Suja a baseEstraga pré-condiçõesSolução:Fe...
6) Realizar estudo das ferramentasQuem vai usar a ferramenta, qual o seupropósito e quais problemas essaferramenta irá aj...
6) Realizar estudo das ferramentasQuem deve ter acesso à ferramenta e quenível de controle de acesso e administraçãoé nec...
7) Manutenção sempreO script fica obsoleto muito rapidamentecom as mudanças do sistemaSe não for sempre executado, acaba...
8) Automação não é somente GUIGUI = Grafic User InterfaceÉ a primeira que os testers usam e aprimeira que dá dor de cabe...
Pirâmide da AutomaçãoAgile Testing (Janet Gregory e Lisa Crispin)
9) Não criar sprints cascataNão esperar dev codificar tudoNão passar apenas automatizando etestar só no fim
10) Testadores nem sempre sãoprogramadoresÓtimos testadores podem não saberprogramarProgramadores não possuem técnicas d...
O que automatizar?
Ferramentas de Automação deTestes FuncionaisFerramentas que permitem reproduzir aexecução manualPossui comandos como cli...
Técnicas GUI - Scripts LinearesSem laços, ciclos ou condições ifCriada por sistemas Record & Play
Scripts LinearesBom para testes que serão poucoreaproveitados. Ex: teste de aceitação, pré-condiçõesFácil aprendizadoMassa...
Scripts EstruturadosCódigo gerado pelo Record & PlayManipulado para conter if, métodos eoutra vantagens da linguagem uti...
Scripts Estruturados
Scripts EstruturadosUso livre da linguagem de programação,podendo criar laços, condições, repetiçõesSeparar scripts em mód...
Scripts CompartilhadosAbordagem dos scripts estruturadosporém os scripts comuns a vários casosde teste
Scripts CompartilhadosMesmas vantagens do estruturadoMelhor reaproveitamento de scriptsMesmas desvantagens do estruturadoM...
Scripts Data-DrivenA massa de dados fica fora do script,armazenada em tabelas HTML, XML ouCSVScript acessa o arquivo de ...
Scripts Data-DrivenA massa pode ser criada por um testadornão desenvolvedorManutenção não envolve os dadosFacilita a reuti...
Scripts Keyword-DrivenAbstrai a automação de casos de teste daprogramação de testesScripts são chamados por keywords
Scripts Keyword-DrivenA suite de testes pode ser criada por umtestador não desenvolvedorDesenvolvedor não precisa ser expe...
Combinação Keyword-Data-DrivenReune as duas abordagens, tornando aautomação de testes totalmenteindependente de desenvolv...
Scripts Keyword-DrivenPossibilidade de criar ferramentasdesktop para automaçãoCurva de aprendizado um pouco maiorpara os t...
Perguntas?
Obrigada!Contato: alini.gottardi@gmail.com
Próximos SlideShares
Carregando em…5
×

Automação de testes para equipes agile

688 visualizações

Publicada em

0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
688
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
12
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Automação de testes para equipes agile

  1. 1. Automação de testes paraequipes AgileAlini Gottardi
  2. 2. 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
  3. 3. Papéis na Área de TesteSegundo o livro Base de Conhecimento emTestes de SoftwareAnalista de TestesArquiteto de TestesTestadorAutomatizador
  4. 4. Analista de TestesPlaneja, analisa riscos, estabeleceprioridades de testes, cria os casos deteste
  5. 5. Arquiteto de TestesLevanta e instala ferramentas, disponibilizae configura ambientes, garante infra-estrutura
  6. 6. TestadorExecuta os casos de teste, documenta aexecução, elabora relatórios, investiga osistema em tempo de execução
  7. 7. AutomatizadorCria sistemas que testam sistemas...
  8. 8. Imagine o cenário atualEquipe metodologia cascata
  9. 9. Vamos modernizar! Vamos ser Ágeis!
  10. 10. Novo cenário Agile/Scrum/Kanban...
  11. 11. Novo cenário Agile/Scrum/Kanban...3 desenvolvedores1 Tester multitarefaO start da equipe é ao mesmo tempoNo primeiro dia de desenvolvimento,tester já precisa estar trabalhando juntoMas nem há o que testar, o que fazer???No segundo sprint é preciso garantir que osprint anterior continua funcionando
  12. 12. Gargalo no testador!!!
  13. 13. Então vamos automatizar os testes!Cria-se o teste uma só vez e pode serreexecutado N vezesA cada novo build, podemos executar aregressão e verificar se não quebrou nadaUm script de teste bem escrito pode seruma documentação executável,diminuindo tempo de escritaBDD
  14. 14. Então vamos automatizar os testes!Cria-se o teste uma só vez e pode serreexecutado N vezesA cada novo build, podemos executar aregressão e verificar se não quebrou nadaUm script de teste bem escrito pode seruma documentação executável,diminuindo tempo de escritaBDD
  15. 15. BDD - Futuro da Automação?Três princípios para BDD1.Negócio e Tecnologia deveriam “falar”sobre um sistema da mesma forma;2.Qualquer sistema deveria ter um valoridentificável e verificável para o“negócio”;3.Análise, design e planejamentoprecoce tem, sempre, retornoquestionável.
  16. 16. Por que BDD funciona?BDD se apóia no uso de um vocabuláriopequeno e bem específico, o queminimiza “ruídos” na comunicação deforma que tanto TI quanto do negócioestejam alinhados.A “venda da ideia” para BDD costuma sermais fácil do que para TDD. Embora, porenvolver mais gente, seja mais“trabalhoso” de implantar.
  17. 17. Automação VivaBDD associa os benefícios de umadocumentação formal, escrita e mantidapelo “negócio”, com testes de unidade que“demonstram” que essa documentação éefetivamente válida.Isso garante que a documentação deixa deser um registro estático, que se converteem algo gradualmente ultrapassado, em umartefato “vivo” que reflete constantemente oestado atual de um projeto.
  18. 18. Exemplo – Teste Executável
  19. 19. Exemplo - Background
  20. 20. Todos os problemas resolvidos!Será?????
  21. 21. Todos os problemas resolvidosNão é bem assim!
  22. 22. Não é bem assim!Se mal tem tempo de testar, quanto maisautomatizarEscolha da ferramenta (web, desktop,webservice)Know-how da equipeComplexidade e testabilidade do sistemaPapéis dentro da equipeNão se perder desenvolvendo um sistemaversus criar testes
  23. 23. 1) Se mal tem tempo de testar, quantomais automatizarTime ágil: todos os membros em busca daqualidade e da entregaTeste unitário dos desenvolvedorestambém é testware!Testador ajuda o desenvolvedor com amassa de testeSe a automação for complexa, ter umresponsável fora da equipe (arquiteto)
  24. 24. 2) Não automatizar todos os casos detesteManutenção constanteFragilidade do script GUI (Grafic UserInterface)Relevância/prioridade do caso de testeFalsa sensação de que está tudo coberto
  25. 25. 3) Não automatizar incertezasMetodologia ágil é instável, os requisitosmudam todos os diasEvitar:Módulos com funções ainda a seremdefinidasTestes que não serão reutilizadosAutomação leva 3x mais tempo
  26. 26. 4) Quando o sistema não é testávelTestes unitários x Sistema em linguagemproceduralElementos HTML Inacessíveis (problemaGUI)Janelas javascript/popupFuncionalidades transparentes ao usuárioAntes de sair codificando, testador devedefinir seus requisitos de testabilidade
  27. 27. 5) Separar os ambientesTestar no ambientes dos desenvolvedoresnão dá certo!Suja a baseEstraga pré-condiçõesSolução:Fechar builds periódicos do dev paratesteSe houver integração contínua melhorainda!
  28. 28. 6) Realizar estudo das ferramentasQuem vai usar a ferramenta, qual o seupropósito e quais problemas essaferramenta irá ajudar a resolverQue tipo de processo ela irá suportar eem caso de mudanças no processo, aferramenta pode ou não ser adequadafacilmenteQue funcionalidades a ferramenta precisater (e.g. quais relatórios devem serextraídos);
  29. 29. 6) Realizar estudo das ferramentasQuem deve ter acesso à ferramenta e quení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 ferramentaprecisa ser compatível;Qual o orçamento e tempo disponíveis paraaquisição e manutenção;
  30. 30. 7) Manutenção sempreO script fica obsoleto muito rapidamentecom as mudanças do sistemaSe não for sempre executado, acaba noesquecimentoDentro do planejamento do sprint preveras manutenções
  31. 31. 8) Automação não é somente GUIGUI = Grafic User InterfaceÉ a primeira que os testers usam e aprimeira que dá dor de cabeçaTestes GUI devem ser usados pra testarGUI, Smoke Tests, Tarefas sujeitas a erro(fórmulas, partes difíceis, bugsintoleráveis)
  32. 32. Pirâmide da AutomaçãoAgile Testing (Janet Gregory e Lisa Crispin)
  33. 33. 9) Não criar sprints cascataNão esperar dev codificar tudoNão passar apenas automatizando etestar só no fim
  34. 34. 10) Testadores nem sempre sãoprogramadoresÓtimos testadores podem não saberprogramarProgramadores não possuem técnicas detesteUtilizar maneiras onde o testador sepreocupe apenas com testes
  35. 35. O que automatizar?
  36. 36. Ferramentas de Automação deTestes FuncionaisFerramentas que permitem reproduzir aexecução manualPossui comandos como clicar, abrir URL,mover mouse, preencher camposPara encontrar os objetos utilizaposicionamento do mouse, identificadorHTML, Xpath, entre outrosPodem ser utilizadas por meio de interfacegráfica ou linha de códigoNossos exemplos utilizam Selenium
  37. 37. Técnicas GUI - Scripts LinearesSem laços, ciclos ou condições ifCriada por sistemas Record & Play
  38. 38. Scripts LinearesBom para testes que serão poucoreaproveitados. Ex: teste de aceitação, pré-condiçõesFácil aprendizadoMassa de dados hard-codedScript não pode ser compartilhado comoutrosManutenção difícilExecução frágil
  39. 39. Scripts EstruturadosCódigo gerado pelo Record & PlayManipulado para conter if, métodos eoutra vantagens da linguagem utilizada
  40. 40. Scripts Estruturados
  41. 41. Scripts EstruturadosUso livre da linguagem de programação,podendo criar laços, condições, repetiçõesSeparar scripts em módulos para seremreaproveitadosMassa de dados hard-codedDesenvolvimento extensoDependência entre os scripts
  42. 42. Scripts CompartilhadosAbordagem dos scripts estruturadosporém os scripts comuns a vários casosde teste
  43. 43. Scripts CompartilhadosMesmas vantagens do estruturadoMelhor reaproveitamento de scriptsMesmas desvantagens do estruturadoMais scripts para manutenção edocumentação
  44. 44. Scripts Data-DrivenA massa de dados fica fora do script,armazenada em tabelas HTML, XML ouCSVScript acessa o arquivo de massa erealiza o teste
  45. 45. Scripts Data-DrivenA massa pode ser criada por um testadornão desenvolvedorManutenção não envolve os dadosFacilita a reutilização de scriptsArquitetura inicial demora para serconstruídaExige conhecimentos sólidos deprogramação
  46. 46. Scripts Keyword-DrivenAbstrai a automação de casos de teste daprogramação de testesScripts são chamados por keywords
  47. 47. Scripts Keyword-DrivenA suite de testes pode ser criada por umtestador não desenvolvedorDesenvolvedor não precisa ser expert emtestesO caso de teste pode ser entendido porleigosMesmas desvantagens do Data-Driven
  48. 48. Combinação Keyword-Data-DrivenReune as duas abordagens, tornando aautomação de testes totalmenteindependente de desenvolvimento eprogramação
  49. 49. Scripts Keyword-DrivenPossibilidade de criar ferramentasdesktop para automaçãoCurva de aprendizado um pouco maiorpara os testadores
  50. 50. Perguntas?
  51. 51. Obrigada!Contato: alini.gottardi@gmail.com

×