Universidade Federal de Gois Instituto de Informtica Teste de Software

Automao de Teste: Desafio para Empresas

Bruno dos Reis Calado Dannyel Cardoso da Fonseca Fabrcio Vieira Pessoni Jackeline Neves de Almeida Savio Salvarino Teles de Oliveira Vinicius Vieira Pessoni

Automao de Teste: Desafio para Empresas

Introduo Software Test Automation in Practice: Empirical Observations Estudo de caso: Google Estudo de caso: Omicron Estudo de caso: Microsoft Common mistakes in test automation Concluso Espao para Dvidas

Introduo
Vinicius Pessoni

Automao de Teste: Introduo

Automao de Teste configura na utilizao de ferramentas especficas para:

controlar a execuo dos testes; gerar e inserir dados; comparar os resultados obtidos com os esperados;
gerar relatrios baseados em mtricas definidas; gerar scripts que simulem o comportamento do usurio.

Automao de Teste: Introduo

Motivao: atender presso de mercado por entregas mais rpidas; maiores taxas de cobertura; software como fator estratgico para sucesso das empresas; recursos escassos, variantes;

Automao de Teste: Introduo

Motivao: pequenas modificaes geram grandes taxas de reteste; grandes gastos com bugs; maiores exigncias quanto a qualidade;

Automao de Teste: Introduo

Nveis de teste: teste unidade; integrao; sistema; regresso;

Tcnicas de teste abrangidas: caixa branca; caixa preta; baseado em defeitos;

Automao de Teste: Introduo

Objetivos: ampliar: informaes sobre o software; velocidade de liberao de verso; cobertura acumulativa na deteco de erros e reduo de custos de uma falha; repetibilidade e economia de tempo; facilidade do teste de regresso;

Automao de Teste: Introduo

Objetivos: reduzir: erro humano; variao de qualidade por expertise do testador; risco de falhas e impactos financeiros; tarefas repetitivas e massantes; quantidade de casos de teste manuais;

Automao de Teste: Introduo

Objetivos: OBS: o intuito no extinguir o teste manual! antes do teste ser automatizado, ele precisa ser criado e verificado manualmente.

Automao de Teste: Introduo

Objetivos: melhoria de produtividade: aps escrito o teste automatizado, sua execuo mais rpida e perdura por mais tempo que o teste manual; possibilita imensas variaes nas entradas aumentando a quantidade de testes; entrega mais rpida e barata;

Automao de Teste: Introduo

Cronograma X oramento = automao?

Automao de Teste: Introduo

Cronograma X oramento = automao? se o software no funciona, no importa velocidade e baixo custo; Quando no automatizar: design instvel; testadores inexperientes; tempo e recursos insuficientes; processo de teste no implantado;

Automao de Teste: Introduo

Quando automatizar: esforo de teste maduro o suficiente: processo; testadores; teste manual; cultura de teste;

aplicao estvel; grandes variaes de dados;

Automao de Teste: Introduo

Abordagens de automao: as estratgias de automao variam de acordo com: requisitos de teste; arquitetura do produto; expertise da equipe de teste;

Automao de Teste: Introduo

Abordagens de automao: capture/playback (replay); data-driven test; keyword-driven ou table-driven test; domain specific language automating; model based testing; API-Based automation (programing interfaces); CLI (Command Line Interface) based automation;

Automao de Teste: Introduo

O que automatizar: criar os testes antes de decidir quais automatizar: seno, muita atividade para poucos defeitos encontrados; desenvolver testes automatizados diferentes dos manuais: explorar variaes que a automatizao pode oferecer;

Automao de Teste: Introduo

O que automatizar: revenue tasks X excise tasks; revenue, contribui diretamente para soluo do problema: ex: definio de mtodos, tipos de dados, algoritmos. excise: no contribui diretamente, mas necessria: ex: compilao, reexecuo, comparao de resultados. excise tasks so candidatas a automatizao;

Automao de Teste: Introduo

O que automatizar: smoke tests; teste de unidade; testes de carga; teste de desempenho (performance benchmarks); teste de configurao; teste de resistncia/durao; condies de corrida; teste de combinaes complexas;

Automao de Teste: Introduo

O que automatizar: nesses testes a automao usada para criar novos ou expandir a cobertura; no de fcil implementao; necessrio realizar por partes e at desenvolver ferramentas para auxiliar; alguns pontos antes vistos como no automatizveis esto mudando, como a gerao de casos de teste;

Automao de Teste: Introduo

Caractersticas esperadas do ambiente de automao: automao de teste um processo de desenvolvimento de software; sujeito a: planejamento; requisitos; entregveis; necessrio disciplina e gerenciamento para no falhar;

Automao de Teste: Introduo

Caractersticas esperadas do ambiente de automao: manutenibilidade: os testes automatizados devem ser manutenveis; documentao: devem ser documentados; otimizao: nem sempre ter mais sinnimo de melhor; independncia: grau de acoplamento dos testes; modularidade dos scripts: ligados s partes da aplicao; sincronizao: aplicao e testware em mesmo nvel.

Automao de Teste: Introduo

Pontos chave de automao: o que deve ser automatizado e o que no deve; escolha das ferramentas corretas; apoio gerencial; retorno sobre investimento; habilidades dos testadores e treinamentos para ferramentas; planejamento, escopo e objetivos bem definidos; respostas de teste bem definidas; timming; framework de teste;

Automao de Teste: Introduo

Algumas ferramentas para automao: JMeter; Selenium HQ; TestComplete; HP LoadRunner; Sikuli; Rational Robot (IBM);

Automao de Teste: Introduo

Tpicos seguintes da apresentao: observaes sobre automao de teste na prtica; estudo de caso em teste automatizado na google; estudo de caso em automao de testes baseados em modelos; estudo de caso de teste automatizado na microsoft; erros comuns em automao.

Software Test Automation in Practice: Empirical Observations

Fonte: Kasurinen, Taipale, Smolander - 2009 Software Test Automation in Practice Empirical Observations
Savio Oliveira

Introduo
Problema: Testes so uma das tarefas mais caras no projeto de software; Motivao: Testes automticos podem reduzir os custos de execuo de testes repetitivos; Objetivos: Expor o estado atual da automao de testes nas empresas; Identificar melhorias no desenvolvimento de testes de software na prtica.

Processo de Pesquisa
Entrevistas realizadas em uma unidade da empresa. Para empresas pequenas pode ser a prpria empresa; Primeira Etapa: 12 grandes empresas entrevistadas; Conhecer os fatores que impactam nos testes automatizados de software; Segunda Etapa: 31 empresas entrevistadas; Entrevistados: Designers, programadores, testadores, projetistas e gerentes de testes.

Processo de Pesquisa

Processo de Pesquisa

Processo de Pesquisa
Mtodo de Anlise Os dados de cada entrevista foram agrupados e classificados em 12 categorias A categoria de Automao de teste foi definida como categoria principal Todas as outras categorias estavam relacionadas a ela.

Processo de Pesquisa
Mtodo de coleta de dados Coletar informaes das pessoas sobre o que elas pensam sobre Automao de testes. Estudo exploratrio para entender melhor pesquisadores e desenvolvedores. Questionrio http://www2.it.lut.fi/project/MASTO/

Resultados
Empresas entrevistadas

Resultados
Empresas entrevistadas

Resultados
Quantidade de recursos disponibilizados para testes

Resultados
Nvel de teste de acordo com a ISO/IEC 29119

Fases de testes no processo de software

Resultados
Nvel de teste de acordo com a ISO/IEC 29119

Fases de testes no processo de software

Resultados
Nvel de teste de acordo com a ISO/IEC 29119

Fases de testes no processo de software

Resultados
Efeitos do processo de teste

Resultados
Efeitos do processo de teste

Resultados
Efeitos do processo de teste

Resultados
As reas mais importantes de aplicao de testes automticos

Popularidade das ferramentas de teste

Resultados
As reas mais importantes de aplicao de testes automticos

Popularidade das ferramentas de teste

Resultados
As reas mais importantes de aplicao de testes automticos

Popularidade das ferramentas de teste

Qualidade do estudo
Foram conceitualizadas as principais categorias Automao de testes Descreve as reas de desenvolvimento de software em que a automao foi aplicada com sucesso Papis no processo de desenvolvimento de software Objetivos para os quais a automao foi aplicada Estratgias para automao de testes Como a automao foi aplicada no processo de software

Qualidade do estudo
Foram conceitualizadas as principais categorias Desenvolvimento automtico de testes Recursos alocados para a infraestrutura Ferramentas de automao Ferramentas utilizadas pelas empresas Impedimentos para automao Principais impedimentos para automao dos testes nas empresas.

Hipoteses de aplicabilidade e utilidade

Hiptese 1
Automao de testes deveria ser considerado como ferramenta de controle de qualidade Confirmar algumas propriedades funcionais Suporte para gerenciamento de mudanas Diminuir problemas de compatibilidades Projetos curtos tendem a no implementar testes automticos Parece ser til em projetos grandes Compatibilidade de mdulos e suporte a sistemas legados

Hipoteses de aplicabilidade e utilidade

Hiptese 2
Custos com desenvolvimento e manuteno de testes automticos so problemas comuns em todas as empresas Muitas empresas acabam optando pelos testes manuais Hiptese 3 Automao de teste requer esforo considervel da empresa A empresa deve decidir se o controle de qualidade com a automao vale a pena.

Hipoteses de aplicabilidade e utilidade

Hiptese 4
Nmero limitado de ferramentas de automao de testes Empresas so obrigadas a desenvolver ferramentas Mesmo utilizando ferramentas do mercado, o custo de manuteno continua alto

Concluso
Esforo em testes menor que o esperado (25%) Literatura menciona entre 50% e 60% Em mdia apenas 26% dos testes so automticos Vrias empresas evitaram investir em testes automticos devido ao custo/benefcio Preferem testes manuais Muitas empresas apresentam objetivos e estratgias erradas na implementao de testes automticos. 61% das empresas seguem algum processo de teste 13% possuem mtodos para medir a eficincia deste processo

Estudo de Caso: Google

Fonte: James A. Whittaker, Jason Arbon and Jeff Carollo - How Google Tests Software, 2012

Dannyel Cardoso da Fonseca

Agenda
Papis dos engenheiros Estrutura organizacional Tipos de teste Planejamento da automao de teste Exemplo - Webmaster Tools

Papis dos engenheiros

Software Engineer (SWE)

Responsvel pelo cdigo; Cdigo funcional; Reviso de cdigo; Documentao de projeto; Estrutura de dados; Arquitetura em geral; Cdigo de teste; TDD; Testes unitrios; 100% do tempo codificando;

Software Engineer in Test (SET)

Foco na testabilidade e infraestrutura de teste; Reviso os projetos; Acompanham a qualidade dos cdigos e riscos; Compartilha com os SWEs a mesma base de cdigo; Refatoram cdigos; Escrevem frameworks de testes unitrios e de automao; 100% do tempo codificando;

Test Engineer (TE)

Testes com foco no usurio; Testes de automao fim-afim; Gerenciam a coordenao entre TEs; Contratam testers; Gernciam crowd sourced testers, dogfooters, usurios betas,

Estrutura organizacional
Estrutura hierquica divida em reas Focos; Baixo nmero de Testers;

rea foco (Client) Diretor

rea foco (Geo)

Diretor

SWEs

SWEs

STEs

STEs

TEs rea foco (Engenharia de Produtividade)

Tipos de testes
Small Medium Large

Grande ao dos SWEs ; Quase sempre automatizado; Testa cdigo funcional, dados corrompidos, condies de erros, enganos comuns;

Grande ao dos STEs no incio do ciclo do produto; Geralmente automatizado; Testa cdigo funcional, dados corrompidos, condies de erros, enganos comuns;

Cobre cenrios reais; Todos os trs papis esto envolvios; Automao de testes exploratrios;

Infraestrutura de testes compartilhada; A diviso em grupos permite melhor escalonamento dos testes;

Tipos de testes

Planejamento da automao
Se o teste pode ser automatizado e o problema no requer inteligncia ou intuio humana ento ele deve ser automatizado; A automatizao deve ser feita passo-a-passo mas o mais cedo possvel; O plano de automao deve ser: sensato; impactante; de propsito especfico; til;

Planejamento da automao
Passo a Passo: 1. Isolar as interfaces propensas a erros e criar mocks e fakes para controlar as interaes nas interfaces e garantir uma boa cobertura de teste; 2. Construir uma estrutura de automao simples que permite que o sistema mockado ser construdo e executado; 3. Alm da automao o plano deve incluir: Informaes de como fazer construo de qualidade; Mecanismos de comunicao entre os envolvidos; Dashboards;

Exemplo - Webmaster Tools

Contexto
Time: 15 SWEs (C++/Java) 2 SETs Releases: 6 semanas: 3 de desenvolvimento; 2 a 3 de garantia da qualidade: testar a UI em todos os browsers e idiomas; Ferramenta de automao: eggPlant.

eggPlant

Problemas
Desenvolver testes em SenseTalk; pouco conhecimento do time; difcil organizao dos scripts em projetos grandes; Todo teste usando eggPlant somente executado na ferramenta eggPlant; Teste baseado em comparao de imagens; comparao de strings so pixel-a-pixel; tolerncia de imagens; Difcil integrao com a infraestrutra de testes j existente;

Diferentes renderizaes

Soluo
Uso do WebDriver: examina o HTML retornado pelo servidor; teste de funcionalidades e no de aparncia; a checagem manual da aparncia; verdadeira comparao de strings; reduo do tempo de execuo; testes ecritos em Java; fcil integrao com a infraestrutra de testes j existente;

Concluses
Uma boa estratgia de automao incide sobre os objetivos mais importantes para os testes automatizados; Dependendo de como a automao de teste estruturada, grandes quantidades de esforos podem ser jogados fora quando grandes mudanas ocorrem no sistema em teste; Caractersticas da ferramenta que so timas quando voc v pode no ser to bom quando voc tentar us-las a srio; Comece pequeno. Tom Gilb diz: "Se voc vai ter um desastre, tenha um pequeno."

Estudo de Caso: Omicron

Fonte: Entin, Winder, Zhang, Christmann - 2012 Introducing Model-Based Testing in an Industrial Scrum Project

Fabrcio Pessoni

Agenda
A empresa Introduo MBT - Foco de Aplicao Benefcios do MBT Abordagem MultiScrum Processo sugerido Terminologia Gerao de modelos no contexto MultiScrum Desafios Resultados Concluses

A empresa

Companhia com sede na ustria; Presente em mais de 140 pases; Atua no ramo de eletricidade de potncia; Prov ferramentas para teste e monitoramento de sistemas de eletricidade de potncia: hardware e software;

Introduo

Contexto:
GUIs de sistemas so testadas para regresso via processo Capture & Replay; A empresa utiliza processo de desenvolvimento gil;

Objetivo:
Encontrar alternativa para gerao de casos de testes automatizados para propsitos de regresso que se adaptem aos processos geis;

Model Based Testing - MBT - Foco de aplicao

Gerao automtica de Casos de Teste: Testes tipo caixa preta: simulam interaes dos usurios com a GUI dos sistemas; Testes de regresso : para funcionalidades aparentes da GUI dos sistemas, aps atualizao; Apoiada por Abordagem Risk Based Testing: descobrir quais bugs so mais crticos; Reduzir tempo e esforo das rotinas dos testes outrora mencionados;

Benefcios do MBT
Separao entre a descrio lgica do caso de teste e sua implementao tcnica; Independncia de plataforma e consequente reusabilidade de modelos; Identificao de inconsistncias nas especificaes antes da implementao; Mudana no paradigma de TS: de qualidade analtica (cdigo pronto); para qualidade construtiva (cdigo em desenvolvimento);

Abordagem MultiScrum para desenvolvimento SW

Processo sugerido

Processo sugerido -Terminologia

System Aspects (SA) Derivados dos Use Cases e User Stories; rea visvel da GUI do sistema que contm funcionalidade a ser testada via processo automatizado MBT; Ex. Navegao e/ou interao do usurio com algum menu da GUI do sistema;

Processo sugerido -Terminologia II

Usage Model (UM) Materializao dos System aspects; Grficos UML de mquina de estados Podem ser decompostos em sub-mquinas de estado;

Exemplo de System Aspect Terminologia III

Gerao de modelos no contexto MultiScrum -Terminologia IV

Desafios da implementao de MBT

Para testes de regresso de GUI: Quantos modelos(usage models) devem ser gerados? Um modelo para todo o SW? No necessita versionamento; A cada Sprint o modelo sofre muitas alteraes, o que demanda redesenho; Ou um modelo para cada funcionalidade? Modelos podem ser reusados em outros projetos; necessrio versionar modelos;

Desafios da implementao de MBTII

Qual o nvel correto de abstrao dos modelos? razovel criar modelos para cada click de mouse em uma GUI? Como administrar o ciclo de vida os modelos de maneira integrada? H escassez de ferramentas integradas no mercado;

Desafios da implementao de MBTIII

Desafios Humanos - convencer as partes interessadas: Donos de produto, desenvolvedores e Gerentes; Mudanas em processos so vistas com certo receio; Necessidade de treinamento dos envolvidos no processo;

Alguns Resultados

Concluses
MBT automatizado superior a C&R para testes de regresso de GUIs; O processo reduz o tempo das rotinas de teste, aumenta a abrangncia de cdigo e diminui o time-to-market do produto final; O processo adaptou-se bem s rotinas de desenvolvimento gil; H dificuldades de comprenso dos modelos por: Dono do produto; Gestores; H necessidade de ferramentas de cdigo aberto para gerenciamento do ciclo de vida dos modelos;

Estudo de Caso: Microsoft

Fonte: Williams, Kudrjavets, Nagappan - 2009 On the Effectiveness of Unit Test Automation at Microsoft

Bruno Calado

Introduo
Observaes Empricas Automated Unit Testing Aumenta a qualidade do Cdigo? Relatos apresentados: Teste de Unidade aplicado na Microsoft A pesquisa na empresa - minerao de informaes: Entrevistas Aplicao de Surveys (desenvolvedores e testadores) outros

Estudo de caso - Microsoft

Introduo - Contexto
Contexto da aplicao da pesquisa: Time composto por 32 desenvolvedores Linguagem predominante: C# Durao dos testes: 1 ano Verses do software testadas: Verso 1 (v1) - Teste manual Verso 2 (v2) - Teste automatizado Resultado: Queda de 20.9% de defeitos (durante o desenvolvimento) Queda de defeitos aps 2 anos de utilizao Custo de aproximadamente 30% mais tempo de desenvolvimento em relao v1

Anlise - Equipe
Verso 1 (v1) 28 desenvolvedores 22 testadores Verso 2 (v2) 32 desenvolvedores 28 testadores

50% da equipe estava engajada em ambas as verses

As prticas desenvolvidas
v1: prticas ad hoc, BVTs e execues manuais v2: uso de framework (NUnit) e de tcnicas automatizadas (TDD - TestDriven Development)

Anlise - plano
Verso 1 (v1) Prticas ad hoc de teste de unidade Prticas de Teste individualizadas de Verso 2 (v2) Prticas ad hoc de teste de unidade de Unidade Unidade Prticas de Teste individualizadas Automoo Processo de Unidade de Teste: unificado e sistemtico

Teste de Caixa Branca Fases analisadas: Cdigo Teste Erros Outros repositrios

Anlise - prticas desenvolvidas

v1
Anlise do cdigo Reviso individual de cdigo Analisador esttico Testes funcionais (BVTs):aceitao e regresso

v2
Reviso individual de cdigo Analisador esttico Testes funcionais (BVTs):aceitao e regresso

Teste automatizado

Raramente ou nunca. Exceo: teste ad hoc - Desenvolvedor poderia executar o teste na sua prpria mquina se quisesse Diriamente a partir da primeira tentativa

NUnit tests: comportando-se como teste de regresso (DRTs)

Frequncia de Execuo

Prprios Testes de Unidade: Pelo menos uma vez por dia Testes de outros desenvolvedores: uma vez por semana

Preocupao:

Especificao User cenrios Segurana Desempenho

Especificao User cenrios Segurana Desempenho

Tcnicas adicionais

Seriam adicionadas caso o Revisor sugerisse

As prticas desenvolvidas
Uso de ferramentas que implementam Automoo de Testes

As prticas desenvolvidas
Uso de ferramentas que implementam Automoo de Testes

As prticas desenvolvidas
Uso de ferramentas que implementam Automoo de Testes

As prticas desenvolvidas
Uso de ferramentas que implementam Automoo de Testes

Resultados - Defeitos
Gravidade dos Defeitos Gravidade 1 Gravidade 2 Gravidade 3 v1 (%) 65,3% 28,7% 6.0% v2 (%) 56,9% 18, 8% 3,4%

A quantidade de defeitos encontrados durante 2 anos amentou em um fator de 2,9%. O nmero de clientes aumentou em um fator de 10 Mais clientes, possivelmente mais defeitos encontrados Usando TDD reduziu-se o nmero de defeitos entre 62 e 91% Qualidade

Defeitos

Resultados
Automao de teste: Vantagem: ferramentas e tcnicas que garantem uma maior cobertura de anlise (NUnit, Test-Driven Development) Maior quantidade de defeitos encontrados Desvantagem: Aumento na quantidade de linhas de cdigo Aumento do tempo de desenvolvimento

Aprendizado

O aprendizado

A Automoo de Testes a melhor maneira de aumentar a eficcia?

O aprendizado

A Automoo de Testes a melhor maneira de aumentar a eficcia?

No somente a Eficcia, mas tambm Eficincia e Cobertura do Teste de Software

O aprendizado
Principais observaes: Liderana: gerenciar Testes de Unidade importante Equipe de teste e de desenvolvimento trabalhando juntas Deixar claro no esquema do projeto o fator tempo. A equipe deve entender que pode ser demorado A testabilidade precisaria ser considerada como parte da arquitetura e modelagem. Entender como impactar os testes, esforo que vir e a eficcia do processo de teste A execuo do conjunto de testes deve ser fcil (exemplo, os testes do caso Microsoft levavam em torno de 10min)

Common mistakes in test automation

Fewster, Mark, 2011. Common Mistakes in Test Automation

Jackeline Neves

Common mistakes in test automation

Confundir automao e teste; Acreditar que capturar/ reproduzir automatizao; Verificar apenas as informaes da tela; Usar apenas comparaes na tela; Deixar a infraestrutura de teste evoluir naturalmente; Tentar automatizar muito.

Confundir automao e teste

Teste habilidade; Seleo aleatria no eficaz; Atributos que dizem se um teste bom: Eficcia: Encontrar erros; Exemplar: Testar mais de uma coisa; Econmico: Para executar, analisar e depurar; Evoluvel: Quo econmico nas manutenes; Os atributos devem ser equilibrados. "caso de teste que testa um monte de coisas provvel que custa muito para executar, analisar e depurar" Testes devem ser desenvolvidos para encontrar bugs e evitar custos excessivos;

Confudir automao e teste

Automao tambm uma habilidade; Exige grande esforo; Caro: Automatizar x realizar manualmente; Se o teste necessrio de ser executado vrias vezes ao longo do ciclo de vida; Se o teste no afeta a eficcia ou se no exemplar: Tanto faz automatizar ou no; Atigir nada mais rpido. Automatizao afeta no atributo econmico e evoluvel; Custo: criar e manter; Econmico: executar; Manuteno pode ser mais caro que desenvolver tudo;

Confudir automao e teste

Eficincia e eficcia da automatizao: conjunto de testes bons; desenhado para testar o mais importante; automatizar de forma que possam ser criados e mantidos com custo razovel

Confudir automao e teste

Quanto maior a medida de cada atributo maior a rea delimitada pelas linhas que unem e melhor o caso de teste.

Acreditar que capturar/ reproduzir automatizao

Parte muito pequena da automatizao; Repetir a entrada capturada no equivale na execuo de teste como um todo; No possvel comparar resultados de testes; Necessrio assistir = custo de fazer; Difcil manuteno nos Scripts; Inserir sadas no script pode falhar bons software e deixar bugs passarem; Scripts gerados por ferramentas no so muito legveis; Projetar para evitar custos de manuteno e no de implementao

Verificar apenas as informaes da tela

Nem sempre a sada na tela significa que est tudo ok; no garante que foi gravado corretamente; Necessrio verificar arquivos e registros criados, modificados, excludos; Testes sensveis a mudanas e maior chance de encontrar bugs; Necessrio bom mecanismo de comparao; Uma soluo comum ter as informaes apresentadas na tela aps o teste foi concludo. (Engano)

Usar apenas comparaes na tela

Grande volume de informaes no banco de dados e arquivos; Visualizar tudo para fazer alguma comparao impraticvel; Trabalho longo e duro para garantir que a informao importante verificada; Pode acontecer do tamanho de registro mximos que a ferramenta suporta ser menor que o tamanho do arquivo; Pode ser solucionado com um processo de comparao no mainframe (em questo de segundos).

Deixar a infraestrutura de teste evoluir naturalmente

Questes-chaves: escala, reutilizao e mltiplas verses; Escala tudo que compe a infraestrutura de teste; Reutilizao reduz o esforo necessrio para construir novos testes, e o esforo necessrio para a manuteno; Mltiplas verses podem ser um problema real; Mudar testes para apoiar uma correo em produo; Vrias verses do sistema em produo. Quanto maior o volume de teste mais difcil gerenciar as verses

Tentar automatizar muito

Muitos testes automatizados no incio so difcieis de manter e suceptveis a mudana do software; Comear com poucos, bons e diversos; Automatizar em verses estveis e mais antigas; Depois em verso instvel do software para saber o que est envolvido na anlise de falhas e explorar novas melhorias de implementao para tornar esta tarefa mais fcil e, portanto, reduzir o esforo de analisar. Quanto mais testes automatizados, maior a possibilidade de duplicao, redundncia e custo de manuteno;

Concluses

Dvidas?

Universidade Federal de Gois Instituto de Informtica Teste de Software

FIM Automao de Teste: Desafio para Empresas

Bruno dos Reis Calado Dannyel Cardoso da Fonseca Fabrcio Vieira Pessoni Jackeline Neves de Almeida Savio Salvarino Teles de Oliveira Vinicius Vieira Pessoni

Referncias
Linda G. Hayes - The Automated Testing Handbook; Graham, Fewster - 2012 - Experiences of Test Automation; Williams, Kudrjavets, Nagappan - 2009 - On the Effectiveness of Unit Test Automation at Microsoft; Ammann, Offutt - 2008 - Introduction to Software Testing; Naresh Jain - 2010 - Test Automation Strategies For Agile; Cem Kaner, James Bach, Bret Pettichord - 2001 - Lessons Learned in Software Testing: A Context-Driven Approach; Fewster, Mark, 2011. Common Mistakes in Test Automation; James A. Whittaker, Jason Arbon and Jeff Carollo, 2012. How Google Tests Software; Entin, Winder, Zhang, Christmann - 2012 - Introducing Model-Based Testing in an Industrial Scrum Project ; http://jmeter.apache.org/ http://www.seleniumhq.org/