Automação de testes funcionais
Autor: Adelino P. Mazuti | Publicado: 2010-10-25T14:25:00-02:00

                           A 30ª Mesa Redonda DFTestes, que ocorreu na primeira quinzena de  agosto, foi sobre “Automação de testes funcionais”. A mesa redonda gerou  bastante discussão, totalizando 29 respostas e tendo 10 participantes.
Vocês acham a automação dos testes funcionais necessária? Se sim, você sempre tenta automatizar os testes funcionais, como?Segundo o Juraci Vieira:
Certamente é necessária uma vez que os ciclos do  desenvolvimento de software estão cada vez mais ágeis e os softwares  cada vez mais complexos, para cobrir a complexidade crescente é  necessário grande quantidade de casos de teste, e para se adequar ao  curto prazo de tempo é necessário executar essa grande quantidade de  testes de maneira mais eficiente porém, mantendo a acurácia. Isso é  possível com a automação de testes funcionais.
Outra razão para se utilizar automação de testes funcionais seria  para investir mais tempo no trabalho de análise do software e  desenvolvimento dos casos de testes (para que os mesmos sejam mais  eficazes em encontrar defeitos) do que na execução propriamente dita.  Digo isso em casos de equipes pequenas de teste como é o meu caso em que  sou o analista de testes e o executor dos testes. Isso me poupa tempo  pra planejar melhor o que fazer.O Juraci automatiza os testes funcionais da seguinte maneira:
Eu sempre tento automatizar aqueles casos de testes  repetitivos e que exigem bastante atenção, nem sempre você está com a  atenção 100% para executar o mesmo teste manual passo a passo,  esquecer-se de um detalhe é normal para seres humanos. Prefiro investir  um tempo até dez vezes maior para automatizar um caso de teste assim do  que executa-lo sempre manualmente com o risco de errar algum passo e  mascarar o resultado do teste.
Automatizo utilizando 2 softwares livres AutoIt e QAliber. Tenho um  certo domínio sobre o AutoIt e o mesmo satisfaz minhas necessidades. O  QAliber tenho estudado a cerca de um mês e logo utilizarei em um projeto  “vivo”.O Felipe Silva também acredita que a automação dos testes funcionais é  necessária, e segundo ele é importante para manter a competitividade e  consenguir atender as demandas:
Sim, é necessário principalmente para que se possa ser  competitivo o suficiente para conseguir manter os atuais e clientes e  ganhar novos, a automação também ajuda na qualidade dos testes, uma vez  que pode-se concentrar o foco dos testes mais na análise de futuros  novos erros do que em regressões, em certos casos é possível automatizar  aquilo que ainda está apenas nos requisitos, ganhando agilidade também  desde os primeiros ciclos de testes (deixando a “malhar grossa” na  automação e a “malha fina” nos testes manuais).O Felipe Silva compartilhou como ele faz a automação dos testes funcionais, dizendo:
Sim, sempre que possível e viável tentamos planejar a  automação, não só de testes funcionais, mas todo tipo de automação que  traga bons resultados, nem que só possamos começar a trabalhar nisso só  daqui alguns meses, como ferramentas temos QTP (Quick Test  Professional), Selenium, o próprio Java, tem coisas que acabam sendo  automatizadas com Macros.Segundo o Shmuel&nbsp; a automação nem sempre é necessária:
A automação dos testes não é necessária. Ela pode ser  vantajosa às vezes, ou prática, ou até mesmo agradável. Mas nem sempre  ela é necessária.
Por outro lado, eu tento automatizar testes funcionais, claro. Existem testes que trazem beneficio quando automatizados.
Eu uso batch files, VBScript ou C# quando escrevo minhas automações. Já usei AutoHotKey (“irmão” do AutoIT mencionado pelo Juraci), VB, Ruby e Perl também, mas menos.O Elias Nogueira destacou a importância de uma análise de viabilidade:
A automação nem sempre é viável, eu mesmo já  recebi  diversas demandas de clientes internos querendo “firulas” para   “melhorar o seu trabalho”, mas de nada traz ganho como um todo para a   organização.
Sempre, mas sempre que pensarmos em automação  é necessário uma  análise de viabilidade. Ela não precisa ser um  documento mega extenso e  difícil de ler, mas um tempo em que  necessitamos avaliar se realmente a  automação faz sentido ou traz ganhos em potencial.
Hoje mesmo tive um caso em que a automação  solicitada, depois de  fazer uma PoC (Prova de Conceito), só iria trazer  benefícios após o 42°  ciclo de execução, para um sistema que executa 1  ciclo mensal. O  Analista de Teste que solicitou isso vê um ganho pra  ele, mas eu nao  vejo ganho em alocar minha equipe num trabalho que não  trará um retorno  esperado.E o Elias, ainda complementou dizendo:
A automação é uma das ferramentas para o Teste, e não  deve sempre ser tomado como lei nas empresas. Mas isso, como sempre  depende…
Como o próprio Shamuel relatou em suas experiências em automação,  podemos utilizar qualquer artifício para automatizar: shell script, AWK,  programação pura, ferramentas de automação, etc…
A automação de teste, às vezes, mas atrapalha do que ajuda. Isso se  deve a diversos fatores, como o próprio entendimento da automação por  parte dos stakeholders (lembrem do gerente sem noção, que acha  que a automação  é como um “testa aí”, basta dar record-and-play e tudo  se resolve),  senioridade/conhecimento técnico da equipe e conhecimento  de negócio por  parte dos Analistas de Teste (sim, se estes não souberem  especificar  bons testes, estaremos fazendo uma má automação).O Rodrigo Almeida resumiu bem a sua opinião sobre o assunto, dizendo:
Eu tenho certeza que ela é necessária. Para ter  produtividade alta é preciso ter automação. O segredo é saber quais  casos de teste escrever e automatizar!Saber quais são os testes que são necessários ser automatizados é importante segundo o Rodrigo:
Sempre. Desde que o seu ROI seja positivo, ou seja,  precisamos  automatizar os casos de teste corretos. Casos de teste para  telas CRUD  de sistemas não precisam ser automatizadas. E eu acho que  precisa fazer  teste uma vez só na vida para estas telas. O que precisa  ter teste  automatizado são as funcionalidades do núcleo do sistema, que  contém as  regras de negócio do sistema que o cliente usa. Se estas  regras sofreram  algum impacto em alguma mudança realizada no  sistema/ERP, só saberemos  na execução dos testes funcionais  automatizados.Sobre a necessidade de automatizar testes de CRUD  (Create-Read-Update-Delete), o Elias Nogueira acredita que tudo depende  da situação, em determinados casos a automação de tais testes pode sim  ser fazer necessária:
Em alguns tipos de sistemas o CRUD é o que é mais utilizado (e mail alterado) pelo cliente.
O importante é ter foco no que o cliente realmente usa e também no  que  ele realmente quer… Se precisar automatizar uma parte ínfima de uma   tela ou regra que nunca é utilizada para agradar o cliente, temos que   automatizá-la.
Isso é meio “ruim” pra nos, não gostamos, mas é o valor que o cliente vê   nisso que nos faz ser vistos com bons olhos e como uma equipe que   agraga valor.O Ueslei Aquino, concorda com o Elias, e expôs uma experiência, falando:
Em uma experiência que tive, o&nbsp;cliente afirmava que “garantindo   que, em cada tela do sistema eu consiga Cadastrar, Consultar, Alterar e   Deletar, já posso garantir que alguma coisa funciona”. Essa foi a   primeira meta colocada pelo&nbsp;cliente para a automatização.Buscando entender&nbsp;o motivo, fizemos uma busca pelo sistema de   chamados da empresa. E&nbsp;um grande número de chamados de cliente eram&nbsp;de   relamação&nbsp;de defeitos nestes pontos.O Ambiente&nbsp;era um ERP com mais de 20 módulos integrados.Sobre o assunto, o que acho estranho, é que sempre que falamos  sobre automação, alguém vem defender os testes manuais. Automação  não  exclui os testes manuais, aliás, um dos objetivos de automatizar os   testes funcionais, é justamente para poder ter tempo para fazer outros   testes, afinal não testamos apenas para garantir a “funcionabilidade”   dele, há outras cinco características que poderão ser bem importantes para o sistema.O Luiz Gustavo acredita que a necessidade de automação dos testes funcionais depende de vários fatores:&nbsp; 
De maneira geral:- Da rotina dos testadores- Do conhecimento sobre automação da equipe de testes- Da tecnologia do sistema- Da ferramenta de automação a ser  utilizada (por isso é aconselhável estudar os benefícios de cada  ferramenta antes de aplicá-la, sendo assim, não existe ferramenta  “ideal” ou “melhor”)- Do orçamento do projeto- Se os prazos estão apertados (se não, é melhor fazer os testes manualmente, por motivos óbvios)- Se possui um ambiente de testes dedicadoMais especificamente:- Se as funcionalidades a ser testadas se repetem (Regression Testing)- Do esforço necessário para preparação do  ambiente de testes (a massa de dados pode ser toda amarrada via Regras  de Negócio, e isso dá um trabalhão…)- entre outros.Para o Fermiano talvez ela não seja necessária, mas pode ser uma possibilidade a ser considerada:
Eu não diria que a automatização de testes funcionais é necessária, mas a atenção para essa possibilidade sim.
Estamos sempre atentos para essa possibilidade, mas os fatores já   citados aqui indicam que os testes manuais são mais eficazes e   eficientes para a maioria dos casos. Automatizamos sim, mas é uma   pequena fração da totalidade dos testes.
Exemplo: Numa etapa da fase de validação usamos  um roteiro de  testes para os testes de regressão. Esse roteiro possui  aproximadamente  200 situações complexas de testes a serem executados,  necessitando  aproximadamente de 5 dias para ser completado (execução e  verificação  dos resultados). Não é raro alguém perguntar quando teremos  100% desse  roteiro automatizado. A realidade é que apenas 30%, no  máximo, desse  roteiro poderá ser automatizado.O Felipe Silva deu a sua contribuição dizendo:A  necessidade automatizar ou não vai do jeito em que as coisas são   conduzidas em cada projeto, por exemplo no meu projeto trabalhamos tão   corrido que enquanto estamos testando a release atual já estamos  estimando e criado cenários e casos de testes para a próxima release, se  alguém fosse parar para automatizar regression a próxima release iria  atrasar, e as regras mudando toda release, em outras palavras o que  chamamos de regression “hoje” tá mais pra “coisas que restaram da  release passada”, não conseguimos nem manter os TCs que são super  pequenos e nada detalhados, quem dera manter atualizados scripts, aqui  vale mais a pena automatizar alguns procedimentos  genéricos do que  automatizar validações.Mas tem empresas também em que as pessoas ficam focadas em uma  release só, e acompanham o projeto desde a fase de requisitos até a  homologação, enquanto os devs nem escreveram os códigos eles tem tempo  para fazer um monte de coisa, quando é assim é, se o FW  é conhecido é  possível até automatizar desde o ciclo 1 paralelamente a  implementação  (aqui sim vejo ganho na automatização), então assim que a  primeira  build é gerada deixa-se uma maquina dedicada rodando os scripts dia e  noite (se possível em integração contínua), e os testers seguem suas  vidas normalmente em suas 8hs diárias executando os testes “pente fino”  manuais. Pensando nisso, na release 2 os scripts das funcionalidades da  release 1 já estariam lá, então novamente paralelamente a criação do  código da release 2 iriam criar os scripts da release 2, se alguma coisa  da release 2 quebrar alguma coisa da release 1 espera-se que os scripts  da release 1 achem isso enquanto os testers estão focados na release  2.&nbsp; Não tenho como ser genérico em tirar uma conclusão geral que  automação  de testes funcionais em ciclos de regressão sempre são  viáveis.Testes sustentáveis, o que raios é isso?No início da discussão coloquei que a automação dos testes funcionais  é muito importante para se testar de forma sustentável, pois é muito  difícil garantir a qualidade de um sistema apenas com testes manuais.
O Shmuel fez considerações pertinentes sobre essa minha colocação,  que me fizeram explicar melhor o que seria testar de forma sustentável.
Primeiramente, testes sustentáveis são importantes para podermos  garantir a qualidade do sistema a longo prazo. Pois pode ocorrer de  precisarmos de esforço X para testar o sistema, no início do  desenvolvimento, e 2X para testar o sistema nas etapas finais de  desenvolvimento, cenário esse que revela que algo pode estar errado.
Testar de forma sustentável serial algo como testar de forma  eficiente,  ou seja, com o mínimo de esforço e o máximo de eficiência.
Ou melhor, testar de uma forma que fosse possível garantir um bom  nível  de qualidade, ao longo de todo o projeto, buscando investir um  esforço  sempre parecido. Ou seja, garantir a qualidade tanto quando o  sistema  tem apenas 2 funcionalidades, como quando ele tem 50.
Para tentar explicar o “conceito”: imagine que estamos no ano de   2006 e você trabalha no Google, mais precisamente na célula de   desenvolvimento do Google Docs. Como todos sabem, o Google Docs é uma   ferramenta que teve o seu desenvolvimento de forma incremental, e você   como incubido de testar ele. Você precisará fazer vários testes a cada   nova versão, sendo que boa parte destes testes, já foram feitos antes.
Se você fosse testar sempre de forma manual, acabaria entrando numa   rotina, que sempre teria mais e mais testes para executar e isto com   certeza iria impactar no projeto, uma vez que ou você necessitará de   mais pessoas para te ajudar ou o prazo para a entrega será sempre maior,   afinal a cada lançamento você terá mais testes para fazer.
Mas você é o Shmuel, uma pessoa consciente e que sabe da importância   da sustentabilidade para o Teste de Software, por isso já em 2006   percebe que boa parte dos testes podem ser automatizados, e isso iria   aliviar bastante o seu trabalho e você teria tempo para fazer outros   testes mais complexos, que poderiam obter novas informações e que   necessitariam de análises que um computador não consegue fazer (por   exemplo, testes de usabilidade).
A ideia de sustentável seria essa. Meio viajante eu sei, e muito bonita na teória.
Você estuda a viabilidade de automação e planeja, ou simplemente ‘põe a mão na massa’?O Juraci respondeu dizendo:
Eu estudo sim a viabilidade para cada caso de teste, em  um projeto eu tenho casos de teste candidatos a automação.  São aqueles  repetitivos que serão utilizados em uma futura regressão,  testes  massantes tais como o mencionado anteriormente, testes que  revelaram  falhas no software também são candidatos pois mostram o seu  valor  durante o teste de regressão. Vale destacar que o caso de teste é a   base para a automação, é o requisito do “sotftware/aplicativo/script”  que será o produto da automação,  não adianta ‘colocar a mão na massa’  sem ter os casos de teste bem  definidos, pois isto equivale a ter um  requisito fraco e que irá  acarretar em muito mais transtorno como foi  comentado.O Ferminiano também fazer um estudo antes:
Sim, fazemos um estudo de viabilidade de automatização.  Sempre aparece  alguém querendo automatizar alguma coisa, pensando que  basta apertar um  uma tecla e pronto, como já disseram aqui na lista. Um  breve estudo de  viabilidade mostra que apenas algumas poucas vezes  isso é possível.Bem pessoal é isso, espero que tenham gostado do resumo, que mesmo  atrasado não poderia faltar, pois essa discussão foi excelente, aliás,  se você quiser saber mais, acesse o link para a página do DFTestes com a discussão na íntegra.


Fonte: http://qualidadebr.wordpress.com/2010/10/09/automacao-de-testes-funcionais/