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, sendo eles: eu, Juraci Vieira, Felipe Silva, Shmuel Gershon, Elias Nogueira, Rodrigo Almeida, Ueslei Aquino, Luiz Gustavo, Fermiano de Queiroz e Roberto Passani.
Segue abaixo, o resumo desta mesa redonda, quem quiser conferir a discussão na íntegra, só acessar esse link.
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 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 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 cliente para a automatização.
Buscando entender o motivo, fizemos uma busca pelo sistema de chamados da empresa. E um grande número de chamados de cliente eram de relamação de defeitos nestes pontos.
O Ambiente 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:
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 dedicado
Mais 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.
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. 😉
QualidadeBR 