Quando automatizar?

A décima Mesa Redonda DFTestes teve como tema “Quando automatizar?”, e foi uma mesa redonda bem agitada, com 32 respostas (até o momento desse post) e a participação de 12 pessoas, sendo elas: eu, Elias Nogueira, Jonathan Rodrigo, Felipe Silva, Ueslei Aquino, Rodrigo Almeida, Milton Vopato, Marcelo Andrade, Shmuel Gershon, Rafael Porfirio, Sarah Pimentel e Jorge Diz.

Segue abaixo, o “resumo” da décima Mesa Redonda DFTestes, mais uma vez lembrando, que se você se interessa pelo assunto, é altamente recomendável a leitura da discussão na íntegra. 😉

Quando automatizar?

Segundo o Elias Nogueira:

Quando automatizar no sentido que não seja testes funcionais:

=> Qualquer tarefa repetitiva que gaste muito tempo no processo de teste
– Quando gastamos muito tempo criando/formatando Casos de Teste
– Quando gastamos muito tempo colhendo e gerando métricas dos testes

Quando automatizar no sentido de testes funcionais:

=> Testes de regressão
=> Smoke Tests
=> Tarefas repetitivas
=> Funcionalidades críticas do software
=> Testes com cálculos matemáticos

O interessante é que existe pelo menos um tipo de teste que somente pode ser feito automatizado (excluindo-se Portugal): o teste de performance. A base do teste de performance não é somente executar um teste e capturar o tempo de resposta, mas medir diversas outras variáveis que vão compor uma série de informações que juntas poderão dar uma visão de performance da aplicação. (Para maiores informações, consultar o Fabio Martinho) 🙂

Se falarmos em linhas ágeis (Jorge, por favor complemente), basicamente 90% dos testes são automatizados, em virtude da agilidade na entrega, conhecimento de negócio da equipe e conhecimento da equipe em ferramentas.

A respeito do comentário do Elias  sobre automação em linhas ágeis, eu penso que ela ocorre não em virtude da agilidade na entrega, e sim para garantir a qualidade na entrega, e principalmente, para garantir um desenvolvimento sustentável.

Na minha opinião os testes em nível unitário e integração também, que devem ser feitos pelos desenvolvedores, também são testes que devem ser executados de forma automática.

É bom lembrar que automação dos testes é um sonho de muitos profissionais da nossa área, porém ele pode passar a ser um pesadelo, se não for tratado de forma séria e madura (uma boa literatura sobre isso é o paper do Bret Pettichord – Seven Steps to Test Automation Success).

Pensando em uma equipe de Teste de Software, que realiza testes de sistemas, a automação é muito bem-vinda, quando há um grande volume de re-trabalho/testes de regressão.

Já pensando em uma equipe de Desenvolvimento de Software, os testes automatizados são de extrema necessidade, pois como costumam dizer, se você não escreveu testes para o seu código, você já está produzindo código legado.

Agora falando na linha ágil, a automação dos testes é essencial, olhando para o quadrante, percebemos que apenas os testes do terceiro quadrante são feitos de forma manual.

Dentre as razões citadas no livro Agile Testing, da Lisa Crispin e da Janet Gregory, estão:

• Teste manual é demorado;
• Reduzir a probabilidade de erros das tarefas de teste; (a tradução tá bem ruim, o original é assim: Reduce Error-Prone Testing Tasks)
• Liberar tempo para fazer o trabalho o seu trabalho da melhor forma;
• Prover uma rede de segurança, se eu fizer uma mudança no código eu terei os testes, que irão me avisar se eu quebrei algo;
• Prover feedback cedo e frequente; (para mim está é a melhor razão) 😀
• Os testes que direcionaram a codificação (ex.: TDD e BDD) podem fazer mais do que isso (ex.: se tornam testes de regressão);
• Os testes provem documentação, aliás, são uma excelente documentação;
• ROI, com o passar do tempo o esforço gasto na automação dos testes se paga.

A respeito do quadrante de Marick o Jorge Diz tem uma opinião diferente:

Não é bem isso, os quadrantes de Marick têm a ver com a ênfase na automação. Mesmo para os testes do quadrante superior direito (crítica do produto / voltados ao negócio) é possível ser auxiliado por ferramentas de automação. Em outros quadrantes, não se descarta o teste manual. Na prática, apenas os testes de unidade (quadrante inferior esquerdo) são inviáveis sem automação.

É bom lembrar que no modelo de teste ágil, testes são pensados não apenas como mecanismo de detecção de defeitos, mas que também é analisado seu papel de especificação do comportamento do sistema e suporte à equipe de desenvolvimento. Requisitos, testes e exemplos são aspectos diferentes das mesmas especificações. De fato, esta semana bloguei sobre isso.

A respeito sobre a automação no contexto ágil , o Jorge Diz falou que:

Você não consegue ciclos curtos de entrega se tiver que orçar um ciclo de teste manual. Você não consegue qualidade se não tiver testes que podem ser rodados à vontade. Você precisa escrever e executar os testes junto com o sistema sendo desenvolvido para encurtar o ciclo de comunicação

com o cliente e não perder tempo e esforço com mal-entendidos.

No entanto, a ênfase em automação chegou a ser exagerada. Hoje, a comunidade ágil começa a valorizar os conceitos da escola context-driven,

que dá mais importância a testes manuais e exploratórios

Para o Jonathan Rodrigo precisamos ter maturidade e precisamos levar em consideração a quantidade de ciclos de testes que teremos, para que a automação possa ocorrer:

E em uma fábrica de teste se automatizarmos um caso de teste ou uma funcionalidade de forma incorreta (com dúvidas referente aos requisitos) iremos produzir evidências erradas com muito mais velocidade gerando assim um grande prejuízos, como por exemplo a desconfiança do trabalho da fábrica pelo cliente causando assim a perca do mesmo.

Porém se for bem planejada a automação e for executada conforme o planejamento o projeto será um sucesso, pois realmente automatizar diminui os custos e aumenta a velocidade da produção, claro se tudo estiver bem definido e sem sobras de dúvidas, pois se não estiver bem definido os custos podem aumentar e trazer grandes prejuízos.

Termino respondendo a pergunta:

Automatizar quando? Quando tiver maturidade, processo para suportar a automação e quando for identificado que iremos executar o teste mais de 4 ciclos, pois em meu ponto de vista não vale o investimento da automação  em caso de teste que será executado menos de 4 ciclos.

O Felipe Silva acredita que devemos automatizar os testes quando:

1. Quando autorizado pelo cliente
2. Quando viável (ganhar tempo ou redução de custos/recursos)
3. Quando tiver ferramenta e gente capaz de usá-la (“um tolo com uma ferramenta continua sendo um tolo”)

Creio que essas 3 respostas são a base de todas as outras.

1. Pode parecer estranho, mas no meu caso estamos proibidos pelo cliente de automatizar testes funcionais.

2. O fato ganhar tempo OU reduzir custos é a alma de qualquer automação, pois ganhar tempo significa ganhar dinheiro (“tempo é dinheiro”), reduzir custos e recursos é bom também, nem sempre andam juntos, as vezes vale a pena gastar um pouco mais para ter uma entrega mais rápida. Poder alocar recursos em outras atividades que envolvam qualidade (quando se pensa em automação industrial não tiveram tantas vagas na área de qualidade para o número de operários trabalhando o que gerou desemprego), é aqui que cabe a maturidade.

Automação não substitui teste manual e não encontra um percentual de defeitos maior do que o manual, pelo contrário, gráficos mostram que testes manuais encontram mais defeitos que automatizados, pois quando se está lidando e interagindo diretamente com o sistema você consegue pensar (ver) uma situação que até então não tinha pensado apenas lendo um requisito.

Sabendo disso, diria que automatizar com sabedoria é fazê-lo pensando em um teste que tenha como alvo testar parte do sistema, pois pensar que você irá automatizar 100% dos testes é ilusão (assim como é ilusão dizer que você tem certeza que 100% dos defeitos foram encontrados em qualquer tipo de testes), fazendo assim, após ter o script fazendo uma rotina de testes “óbvios” pode-se então focar em testes melhor elaborados no qual tenha que pensar com malícia para imaginar um caminho que consiga quebrar o sistema, pensar em uma situação ainda não prevista por ninguém. Salvo alguns casos como já citado pelo Elias em que manual não é viável (testes de performance, que envolvam cálculos, etc)

3. Ter ferramenta não significa comprar a mais cara no mercado, significa ter uma ferramenta que te gere resultados. A ferramenta “abc” usada pela maior empresa do mundo “fgh” não faz dela a melhor para você, e a melhor para você neste projeto pode não ser a melhor no outro projeto, não ser a melhor também não significa que não serve, se o resultado final gerado é pósito então vale a pena, o único fato é que se outra ferramenta daria um resultado positivo maior pode-se rever/calcular/viabilizar ou não uma mudança de ferramenta.

Tendo a ferramenta vem o mais o importante – antes de comprar a ferramenta é lógico – que é saber utilizá-la, e sabendo usar! Também não adianta nada ter um time expert no assunto e uma ferramenta excelente para ficar na “prateleira”, infeliz é o “chefe” que pensa que vai comprar uma ferramenta e você vai se virar para colocar ela para funcionar, treinamentos e capacitação são necessários.

Saber fazer um script bom não significa que a pessoa está fazendo da melhor maneira possível, quanta gente já não disse “era só isso? quer dizer que você só colocou essa linha de código e já faz tudo isso? nossa antes eu fazia…..”

Automação é um projeto, não parte de um projeto e deve ser tratada como tal, com líder de projeto, desenvolvedor, pessoas responsáveis pela qualidade do que está sendo criado/mantido, cronograma e orçamento.

Na minha opinião além de analisar se será viável (ganhar tempo ou redução de custos/recursos) automatizar o teste X eu também preciso analisar se o teste X será mais eficaz se automatizado ou não, pois executar ele de forma automatizada precisa, pelo menos, garantir a mesma qualidade da execução manual.

Ou seja automação deve pelo menos, garantir a mesma qualidade que os testes manuais, afinal de nada adianta ter um monte de suítes de testes automatizadas se elas não testam nada. 😉

A respeito da viabilidade da automação dos testes (citada pelo Felipe), é preciso também levar em consideração o sistema sob teste, pois se eu automatizar hoje, o teste X, que testa a funcionalidade Y, e amanhã a funcionalidade Y mudar, essa mudança poderá quebrar o meu teste X.

O Ueslei Aquino compartilhou um pouco da sua experiência, relacionado ao assunto da mesa redonda:

Imaginem o que é assumir um departamento de “testes” com missão de torná-lo um departamento de “Qualidade” (Garantia e Controle de qualidade) com 9 profissionais que nunca tiveram um treinamento em testes. A visão do cliente em relação ao setor era… “este setor não me gera resultados financeiros positivos e eu tenho aqui a ferramenta X que 2 pessoas que passaram por aqui não conseguiram implantar, fique com ela 2 meses estudando e depois me apresente o cadastro Y sendo testado por ela.”

Diante do conhecimento, procurei mostrar que sem ter pessoas treinadas, processo e metodologia de teste definidos, documentação de teste… iniciar automação poderia não ser a solução, mas um tiro no pé. Mas, sem sucesso para minhas colocações… a intenção era automatizar os testes e assim poder vender serviço de teste, ou seja, vender para os clientes do próprio sistema poderem utilizar e testar as aplicações e assim gerar resultados financeiros positivos ao setor.

Parece loucura né… mas é a mais pura verdade. Ou seja, eu estava construindo um legado de teste, com uma aplicação que tive que me virar para colocar para funcionar. O Cliente ficou ciente dos riscos, mas quis arriscar…

Diante disso, o que posso dizer do resultado foi… recebi uma proposta irrecusável…saí da empresa e eles continuaram com o processo e inclusive iam começar a aplicar em um cliente que estava implantando o sistema.

O Rodrigo Almeida também compartilhou uma experiência com automação:

Temos uma ferramenta de automação de testes desde 2000. E só em 2008 é que aprendemos como usá-la corretamente.

Tivemos que trocar toda a equipe, contratar pessoas com perfil técnico e conhecimento de lógica de programação.

Mudamos o nosso processo de testes, para podermos automatizar aquilo que era necessário, crítico e kernel dos nossos produtos. Antes a gente automatizava somente as partes periféricas dos produtos, sem impacto efetivo na detecção de defeitos. E os scripts eram criados por pessoas que não conheciam de programação/lógica. Os resultados eram terríveis.

Então, a decisão de quando automatizar foi baseada nas seguintes premissas: É parte do núcleo do sistema? É usado por vários clientes? Faz parte do processo funcional do cliente? Se sim para  uma ou mais de uma pergunta, então automatiza.

Com a mudança radical feita em 2008, saímos de uma média de erros mensal na ordem de 140 erros para uma média de 50 erros/mês em 2009. Não alteramos nada no processo de desenvolvimento. Somente criamos um processo novo de automação de testes funcionais. Não fazemos testes de performance, somente automatizamos testes funcionais e executamos os testes já gravados (teste de regressão).

Com uma equipe correta, ou seja, com conhecimento em programação, conseguimos diminuir nosso ciclo de testes que eram de dois meses, isto mesmo, dois meses, para 12 horas! Somente otimizando os scripts já gravados.

Para o Milton Vopato devemos automatizar quando:

Na minha opinião, a automatização é positiva e é uma tendência para ganho de eficiência. Quando automatizar? acredito que quando você processos mapeáveis, tipo execução em batch, performance, lista de informações padrões, etc. Este tipo de validação economiza tempo para regressões, mas quero chamar atenção a outro ponto de quando automatizar. quando pensamos em quando automatizar, pensamos para que e no processo como um todo, mas acho válido, com uma análise de benefício, criar automatizações parcial do processo de teste funcional também, ex: Hoje validados requisitos funcionais em um XML, então automatizamos a criação do request e agora estamos trabalhando na automatização da leitura de algumas tags na saídas, com isso ganhamos performance e qualidade na execução

O Shmuel lembrou de uma automação que é muito bem-vinda em uma área de Teste de Software:

Me parece que nenhuma resposta comentou em um tipo de automação muito útil: A automação do ambiente.

Em sistemas aonde é necessário configurar a rede o produto e os periféricos de forma específica antes de começar a testar, automatizar o processo de configuração é muito útil.

E além do mais, essa automatização acaba sendo muito apreciada e utilizada por toda a organização, incluindo programadores, pessoal de suporte etc.

Essa automação é legal também porque ela não atrapalha ou influência os testes funcionais.

Já a automação de testes funcionais me da certo medo… 🙂

É muito fácil exagerar na quantidade te testes automatizados, e é mais fácil ainda exagerar na confiança dada a automação.

Com isso, devo colocar que aonde trabalho temos um sistema de automação bem extenso, e tentamos automatizar todos os testes importantes para serem rodados como regressão.

Para o Rafael Porfirio:

A automação também (ao meu ver) é uma opção quando temos uma certa estabilidade na aplicação em que estamos testando assim como o ambiente em que testamos, por isso em muitos casos a primeira coisa a se automatizar são os ciclos de regressão, visto que já foram testados manualmente e de certa forma atingiu uma certa estabilidade por já ter passado por outros ciclos de teste manual.

Outra coisa que devemos levar em consideração, também é o tempo que se leva para criar (scripts de alto, média ou baixa complexidade) e também para se dar manutenção….se você tem uma aplicação onde a cada release seu script deve ser recriado….talvez não seja viável a automação…

Ainda assim, muito é importante ressaltar que um teste automatizado jamais substitui teste manual. Pois assim como desenvolvedores não conseguem fazer todo o codigo 100% correto, como testers podem confiar em sua própria programação para um script?

A Sarah Pimentel fez considerações bem interessantes sobre o tema:

Eu sou bem adepta a processos, não como forma de burocratizar, mas como forma de organizar.

Então pra mim a primeira coisa é ter um processo para decidir isso. E essa decisão se dá em cima de viabilidade de automação.

Trabalhei em uma empresa que tinha uma equipe de automação separada da dos testes funcionais (eles também fazem testes funcionais, mas são especialistas em automação). Quando uma equipe solicitava a automação dos seus testes tinha que responder um questionário inicial para que a equipe de automação avaliasse a viabilidade desse projeto. Por que isso? Porque ao contrário do que muitos pensam nas empresas automatizar ao invés de ser a solução dos seus problemas pode ser mais um gerador de problemas.

Algumas considerações:

Você está automatizando porque você acha que vai encontrar mais erros?

Não vai. O processo automatizado tende a encontrar cada vez menos erros e até mesmo em determinado ponto, não encontrá-los. De tanto rodar os mesmos testes a aplicação fica estável naquele ponto e dificilmente aparecem erros ali.

Você acha que pode automatizar a sua aplicação a qualquer momento e que essa investida é suficiente?

Há dependências de interface gráfica. Se o desenvolvedor mudar “só um negocinho”, pode ser que o teste tenha que sofrer manutenção.
Também vale ressaltar a excelente comunicação do negócio com os desenvolvedores e os testers porque se mudanças no negócio forem discutidas no café e implementadas sem que os testers saibam, o teste também não vai funcionar.

Testes automatizados precisam ser testados?

Obviamente que sim. São programas. Se foram escritos por testers ou desenvolvedores não quer dizer que não possam ter erros. Automatizar precisa passar (rapidamente, claro) pelos mesmos estágios que o desenvolvimento de qualquer outro software. Com base na especificação ele será construído e alguém precisa validá-lo.

Amanhã tá pronto?

😀 Não! 😛

Automatizar requer tempo. Você está disposto a esperar? Quando estiver pronto, você vai ter tempo de utilizar? Por quanto tempo? Compensa?

Dá pra automatizar qualquer coisa?

Bom, não sou expert em automação para dizer que não. Tem um monte de gente na lista que sabe mais que eu pra falar isso, mas sei que tem coisa que é tão complexa que não vale a pena “perder” esse tempo (da forma como foi colocado na observação acima)

O desenvolvedor participa da automação?

Pode ser que seja necessário envolver o time de desenvolvimento para fazer algum ajuste (testability). A equipe de dev dispõe dessa alocação para ajudar?

Enfim. Depois de tudo isso, eu queria dizer que automatizar é legal sim! 😀 Só que é uma coisa que tem que ser planejada com tanto carinho quanto qualquer outro software.

Para o Jorge Diz:

A implantação de testes automatizados cria uma dinâmica diferente, para bem ou para mal. Se dependermos exclusivamente de testes manuais, a cada mudança necessária do sistema há o dilema de incorrer em um custos e prazos significativos para cada ciclo de teste: é extremamente difícil para um gestor avaliar o risco de não testar. A gestão tende a ser mais conservadora em melhorias do sistema (por conta do custo das mudanças), e a manter ciclos longos de entrega de funcionalidades.

Com testes automatizados, o gestor consegue ter informações mais confiáveis. para decidir, e diminuir muito o investimento a cada ciclo. Testes automatizados são uma forma de seguro contra diversos riscos, e ajuda a que as mudanças necessárias ao negócio possam ser implementadas. Oportunidades de negócio deixam de ser perdidas.

Bem pessoal é isso. Continuem de olho na lista do DFTestes, pois sempre há assuntos bem interessantes lá, e poderão haver novas respostas nessa mesa redonda.

Saiba mais

Segue abaixo, algumas publicações que foram referenciadas sobre o assunto, durante a mesa redonda:

Apresentação: 4° Encontro Mensal ALATS: Automação de Testes, Mitos e Verdades

Livro: Implementing Automated Software Testing: How to Save Time and Lower Costs While Raising Quality

Livro: Automated Software Testing: Introduction, Management, and Performance

Livro: Agile Testing

Fórum: SQA Forums – Automated Testing

Artigo: Seven Steps to Test Automation Success – Bret Pettichord

Fique por dentro das novidades, assine o feed do QualidadeBR.

6º Encontro do Guru-SP – Eu fui!

Em pleno sabadão, num dia lindo acordo antes das 07:00, e não é para ir para a praia ou coisa do tipo, e sim para ir ao 6º Encontro do Guru-SP. 😀

Mas que “diacho” de encontro é esse Fabrício? Você foi consultar um guru espiritual?

Não, não (rsrs). O Guru-SP é esse daqui:

Hmmm… agora entendi. Mas o que você foi fazer num encontro de usuários de Ruby? Você programa em Ruby?

Não (mas depois de hoje fiquei com mais vontade ainda de aprender).

Um dos motivos para ter ido ao encontro foi o tema “Testes Automatizados” dele. Não tem jeito, colocar a palavra “teste” no tema de um evento, é mais efetivo do que falar que vai ter coffee break, para me fazer participar.

rsrs… que atitude nerd, perder um dia lindo desse, para ir num evento só por causa que vai falar sobre testes.

Que isso, olha o preconceito. Não é todo dia que você tem a oportunidade de participar de um evento sobre testes, onde que ia falar não atua na área de Teste de Software ou QA, e sim o pessoal do “lado negro da força” (“brincadeira minha, não é falando mal!”).

Interessante mesmo! Quem organizou o evento?

O 6º Encontro do Guro-SP foi organizado pelo Rafael Rosa, com o apoio da GoNow (local do encontro), Voice Technology (empresa na qual trabalho), O’Reilly e Ruby Inside Brasil, além é claro do Grupo de Usuário Ruby de SP.

E como foi o formato do encontro?

Foi no formato de mesa redonda (muito bom!), o pessoal da mesa ia falando sobre vários temas, que foram votados antes pelo pessoal que participou do encontro. Os debatedores foram:

• Anderson Leite
• Cássio Marques
• Diego Carrion (não pode comparecer)
• Fabio Kung (não pode comparecer)
• Jorge Diz (o Jorge será o palestrante do 6º Encontro Mensal da ALATS-SP, a ser realizado nessa quarta-feira)
• Ricardo Yasuda
• Thiago Scalone

E o encontro foi dividido em duas partes, a primeira estimado das 10:00 ao 12:00 e a segunda das 12:30 às 15:00.

Da hora, a primeira parte como foi?

Ela começou com quase uma hora de atraso, com o Rafael Rosa falando sobre o encontro e como seria feito esse. Logo após, o pessoal já começou a “descer a lenha” falando sobre “Por que testar”, e pude perceber que a galera é bem comprometida como a realização dos testes, eles levam a sério mesmo e entendem as razões de porque testar.

Os debatedores também contaram experiências que tiveram fazendo BDD com o Cucumber e realizando testes de interface com o Selenium, por exemplo. Esse foi um ponto muito positivo do evento, ficou claro que os debatedores fazem o que eles falam, e puderam compartilhar experiências bem interessantes com o público. E a interação do público foi muito boa também, várias pessoas contaram os cenários que vivem, e também algumas dificuldades que tem em realizar os testes:

• Tempo: projetos com prazos para ontem. Na minha opinião, realizar testes, principalmente na fase de desenvolvimento é uma prática que gera efeitos não tão bons a curto prazo, mas que a médio e longo prazo, se mostra essencial! Porém, como vivemos numa geração imediatista, muitas vezes as pessoas tem dificuldade em entender isso.
• Complexidade: a criação de testes em sistemas complexos é um desafio maior ainda, às vezes pode ser mais difícil do que a própria implementação.
• Sistemas legados: se dá uma manutenção em um sistema legado já é uma missão de embrulhar o estômago, imagine só criar testes para ele. Uma solução legal, comentada pelo pessoal e colocada em prática é realizar testes em nível de sistema, utilizando o Selenium por exemplo.

O Jorge Diz lembrou que a área de Teste de Software, costuma vir no reboque quando se usa metodologias frágeis (tradicionais). Mas usando metodologias ágeis o Teste de Software é incentivado, as novas técnicas já trazem na sua essência o pensamento de testar. Aliás, um exemplo disso é o uso de programação em par, onde uma pessoa já está revisando o código (lembrando que revisar é uma forma de testar).

Sobre o uso de BDD e TDD, o Anderson Leite disse que antes de partir para o uso delas, as pessoas precisam primeiro adquirir o hábito e prática de testar, só depois que já tiverem maduras podem começar a usar o BDD e TDD.

O Cássio Marques contou um pouco da sua experiência com linguagens de comparação, comparando no quesito de facilidade de testar. E disse que escrever testes em C e C++ é bem difícil, em Java também é meio enrolado. Já em Ruby é bem mais fácil. Podemos dizer que Ruby tem uma melhor “testabilidade”, que as outras, ou seja, se você é desenvolvedor Ruby e não testa, então você tem uma desculpa a menos para usar. 🙂

Um ponto importante discutido foi que se você testa, você não pode se dar ao luxo de deixar de testar uma funcionalidade, pois poderá resultar na velha história da janela quebrada.

Para terminar a primeira parte, houve uma demonstração do uso do Cucumber pelo Anderson. A minha primeira impressão foi que pareceu mágica o que ele fez (rsrs), ele escreveu os testes usando TDD e gerou o código usando o Scaffold de um cadastro de participante que tinha os campos nome e e-mail. Achei bem legal a demonstração, o Cucumber é uma ferramenta muito legal, nela você cria o teste como se estivesse criando uma caso de teste, segue abaixo um exemplo:

O Cucumber utiliza por default o Webrat, porém também é possível realizar o teste usando o Selenium RC, basta passar como parâmetro. O interessante do uso do Webrat é que diferente do Selenium, ele simula o navegador, rodando em background, ou seja, é muito mais rápido que o Selenium RC, porém tem a limitação de não conseguir testar javascript.

E depois do “rango”,  a segunda parte foi no mesmo nível que a primeira?

Depois do excelente coffee break, o Jorge Diz passou vários slides explicando a teoria de testes, abordando desde as escolas de teste até sobre os tipos de dublês. Essa parte fugiu um pouco do formato de debate, mas logo o Rafael Rosa retomou o formato, estimulando uma discussão sobre mocks e o perigo de “engessar muito” utilizando eles.

Do debate sobre mocks, o pessoal chegou a seguintes conclusões:

• Se você está “mockando” muito, pode ser um sinal que a sua classe está fazendo mais do que ela deveria fazer. Então REFATORE;
• Sempre tente modularizar ao máximo a sua aplicação, nada de ter uma classe “sistema”;
• Os dublês em geral, devem ser usados sempre para resolver uma dependência.

Um assunto interessante abordado na apresentação do Jorge, foi como deve ser a pirâmide dos testes, de acordo com o nível:

Mas o que ocorre, geralmente, sem essa cultura de que desenvolvedor também testar, é uma inversão dessa pirâmide, ou seja, não há quase nenhum teste de unidade e integrado realizado, e muitos testes de sistema feitos pelo pessoal de Teste de Software.

E ainda houve mais duas práticas, uma com o Thiago Scalone mostrando o Selenium IDE e o RC. E depois mais uma com o Anderson apresentando o RSpec (o JUnit do Ruby)

E o que você achou? Pelo jeito deve ter sido ótimo, afinal além de falar de testes deve coffee break na faixa.

Excelente encontro! Comprovou que é mito essa história que desenvolvedor não testa, eles testam sim, e até melhor do que muito testador que tem por aí. E Ruby é uma linguagem que oferece uma “testabilidade” incrível, as ferramentas que existem são muito boas, e ajudam desde o teste de nível unitário até o teste de nível de aceite. E essa brincadeira que faço sobre “lado negro da força”, em breve ficará sem sentido, pois os testes estão se tornando cada vez mais uma tarefa inerente ao desenvolvimento.

Para encerrar o post, parabéns a todos que participaram, e principalmente, ao Rafael Rosa, pela excelente organização!

Para saber mais sobre o 6ºEncontro acesse a wiki do Guru-SP:

http://guru-sp.com/index.php/Sexto_Encontro

E para saber sobre os próximos encontros acompanhe o Ruby Inside Brasil:

http://www.rubyinside.com.br/

Fique por dentro das novidades, assine o feed do QualidadeBR.

guru espiritual

Para que testar?

Antes de trabalhar com Teste de Software, eu nem sabia que existia essa área, e acredito que mesmo com o crescimento que a nossa área teve nos últimos anos, ainda há muitas pessoas que não devem ter conhecimento que uma das áreas necessária para o desenvolvimento de um software é a de Teste de Software. E falo isso, principalmente pensando nos jovens que estão se formando nas faculdades, pois eu mesmo não tive uma matéria sobre Teste de Software na faculdade e muito menos praticava TDD nas muitas aulas que tive de programação, passando desde Pascal até Java. E olha que não faz tanto assim que me formei, para ser mais preciso irá completar 1 ano no final de dezembro desse ano.

Vários outros amigos meus, que estudaram em outras faculdades não tiveram tal matéria na grade do curso. Costumo até brincar com o pessoal falando que na faculdade eu só aprendi o que é teste de caixa branca e caixa preta, e foi isso mesmo. Não me disseram que existia uma área que poderia ser responsável pelos testes, quando é necessário testar, como testar, como escrever um caso de teste, como realizar o planejamento, quais técnicas posso usar, e tantas outras dúvidas que tive quando iniciei na área.

E com certeza, essa pergunta “Para que testar?” pode gerar muitas respostas diferentes, dependendo do ponto de vista e do conhecimento da pessoa. E uma das formas de responder essa pergunta, eu usei aqui nesta apresentação. Mas desta vez vou usar uma outra abordagem para falar sobre o assunto, trazendo algumas questões que ajudam a explicar a razão pela qual é necessário testar um software.

Se o software compilou ele está funcionando, então pronto!?

Esse pode ser o pensamento de muitas pessoas, principalmente, daqueles estudantes que nunca ouviram falar em Teste de Software. A compilação de um programa até pode ser vista como a realização de um teste de caixa branca, afinal o compilador irá verificar se não há nenhum erro no código, por exemplo sintaxe, que impeça dele ser compilado.

Mas a compilação por si só não garante que o software esteja funcionando.

Como assim?

No mundo dos projetos de desenvolvimento de software há o famoso escopo, que especifica o que o sistema deverá fazer e o que o mesmo não deverá. E é esse documento que será o referencial do cliente quanto ao seu sistema, se ao entregar o software, algum item do escopo não tiver sido implementado, “coisas horríveis irão acontecer”.

E um dos objetivos do Teste de Software é justamente verificar se tudo que está especificado no escopo foi implementado. Tanto que ele é um dos documentos usados pelo Analista de Teste para poder originar os casos de testes, que serão executados pelos testadores.

O que aconteceria se um software não fosse testado?

Como diria um professor meu “coisas horríveis irão acontecer”. Afinal, a primeira pessoa que irá testar o seu sistema serão os clientes e usuários, e caso eles encontrem alguma inconformidade no seu sistema, o que é bem provável pensando num software que não foi testado, eles não ficaram nem um pouco satisfeitos e o preço pela inconformidade poderá ser muito alto, principalmente nos casos em que há multas contratuais.

Além disso, sistemas que não são testados em fase de desenvolvimento, costumam passar uma boa parte da sua vida pela equipe de manutenção e de suporte. Ou seja, o retrabalho gerado por um software não testado é muito alto!

Todos os softwares são testados?

Todos os softwares deveriam ser testados, mas na realidade poucos são os softwares que são testados de forma efetiva. E um dos motivos principais para que haja necessidade de ser testar algo (em qualquer realidade) é o fato que somos seres humanos, ou seja, estamos sujeito ao erro. Afinal errar é humano!

Há muitas desculpas que fazem com que um software não seja testado, dentre as principais estão:

• Excesso de confiança dos desenvolvedores;
• Falta de tempo para o Teste de Software;
• Não há a cultura de realizar testes;
• Não há pessoas capacitadas para executar os testes;
• Desconhecimento da importância do Teste de Software;
• Os custos com os testes não foram colocados no custo do projeto;
• Etc.

O que é esse tal de TDD?

Comentei no começo do post sobre TDD, uma tendência muito forte no desenvolvimento do software é que já realidade em várias empresas no Brasil e no mundo. TDD é o acrônimo para Test Driven Development, que em bom português é Desenvolvimento Orientado a Testes.

A idéia é bem simples: antes de partir para o desenvolvimento da funcionalidade você irá escrever testes para ela. Isso mesmo, antes de desenvolver a funcionalidade, você irá desenvolver testes que verifiquem e validem a funcionalidade que será desenvolvida.

Daí você pode está se perguntando, mas como eu farei isso? Há alguma ferramenta que facilite esse trabalho?

Há sim, os chamados frameworks/arcabouços xUnit. Eles permitem que você desenvolva testes, chamados de testes unitários, para as diferentes unidades do seu sistema, como por exemplo funções e classes. Além disso, uma grande vantagem desses frameworks é que eles permitem que você execute os testes de forma automática.

Lembra que eu falei que quando você compila você está apenas verificando se o código que você escreveu é compilável, pois então, usando por exemplo o JUnit, um framework para Java, é possível fazer com que ao compilar o seu código os testes que você criou também sejam executados. Ou seja, você também está testando o seu software e ainda de forma automatizada! 🙂

Muitos entusiastas no TDD dizem que os testes automatizados acabam tornando-se uma documentação viva do sistema, e eles estão corretos. Num cenário com testes automatizados, sempre que for necessário realizar uma mudança, ela ser feita com tranquilidade, pois você poderá verificar se a mudança implementada não quebra nada no seu código ou não está de acordo com a documentação, apenas tendo o trabalho de apertar o botão “play” para execução dos testes criados anteriormente.

Mas lógico que para que o TDD possa trazer bons resultados os testes tem que ser bem desenvolvidos, de nada adianta criar um teste que não testa nada. E não pense que usando TDD, você não precisará realizar mais nenhum teste, pois você só está executando os testes unitários, há ainda os testes de integração, sistema e aceitação. 🙂

Conclusão

Testar um software deve ser uma tarefa comum, durante o desenvolvimento do software. Pois é uma forma de aumentar a qualidade do software, a credibilidade da empresa com os seus clientes e maximizar o lucro da empresa. Além é claro, de ser uma das práticas de empresas profissionais, que objetivam entregar uma solução que resolva os problemas dos seus clientes e não uma solução que gere mais problemas para eles.

Além disso, testar não é uma tarefa que deve ser feita só no final do desenvolvimento, até porque, podemos testar antes mesmo de desenvolver. Portanto, devemos buscar usar e conhecer as melhores práticas no nosso trabalho, dentre as quais testar é uma prática essencial. 😉

Fique por dentro das novidades, assine o feed do QualidadeBR.

Automatização de testes em duas rodas

Ontem eu fiquei sabendo pelo twitter da Fernanda Thiesen a seguinte notícia: “Robô motoqueiro”

Particularmente achei muito legal a notícia! Pois ilustra vários fatos, que também ocorrem no mundo do Teste de Software:

• Teste é essencial! Ou você acharia que a Castrol iria investir (não gastar!) milhões de dólares para contratar mais de 120 cientistas e engenheiros para desenvolver o Flossie;
• Automatizar os testes não é uma tarefa fácil! E um dos grandes problemas é não ter a ferramenta certa para a sua aplicação;
• Há testes que somente podem ser feitos de forma automatizada;
• Os testes de performance são de grande importância, pense nisso!
• A coleta das informações e a análise é essencial para uma boa execução de um teste de performance!
• Diversos tipos de testes podem ser realizados de acordo com a aplicação. A Castrol faz até teste de portabilidade!
• Testes manuais ainda são necessários! Há cenários que somente o ser humano é capaz de realizar o teste de forma eficaz e satisfatória;
• Testar de forma efetiva é um diferencial competitivo!

Acredito que a Castrol é um excelente estudo de caso sobre testes automatizados. E um dos pontos que acho mais interessante é fazer a “engenharia-reversa” da situação deles, para saber qual problema originou a criação do robô. Eles devem ter percebido que somente com testes automatizados, seria possível realizar testes de performance de uma maneira mais eficaz, e como essa tarefa não teria como ser feita nem pelo Valentino Rossi, a solução para o problema seria construir o Flossie. Ou seja, para automatizar os testes eles tiveram que desenvolver a sua própria ferramenta.

Aproveitando o assunto, no Brateste desse ano pude conferir um braço mecânico que pode usado para testar software. Isso mesmo! Ele é capaz de interagir com um teclado, por exemplo. E conversando com o Marco Bassi, CEO-Grupo HDI, que investiu e incentivou o projeto, ele me disse que o braço mecânico pode automatizar uma série de testes, e abre novas possibilidades para a automatização dos testes. Um exemplo citado por ele foi de um teste com caixa-eletrônico, onde uma das ações necessárias era inserir o cartão, e que antes do braço mecânico só era possível com a ajuda de uma pessoa.

E a moral dessa história toda, é que às vezes ainda precisamos reinventar a roda, pensar em soluções criativas e inovadoras! 🙂

Fique por dentro das novidades, assine o feed do QualidadeBR.

Fonte:

http://www.castrolmoto.com/en/home.php