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.

Teste Ágil, como implementar?

A segunda Mesa Redonda DFTestes teve 10 participantes: eu, Wagner Duarte Júnior, Felipe Silva, Cibele, Elias Nogueira, Ralph Montelo, Marcelo Andrade, Aderson Bastos (um dos autores do livro Base de Conhecimento em Teste de Software), Robson Agapito e o José Correia.

Como puderam notar, grandes nomes da comunidade brasileira de Teste e Qualidade de Software participaram da Mesa Redonda, e todos com o mesmo objetivo, discutir sobre “Teste Ágil, como implementar?”. 😀

Vamos então para o resumo dessa discussão que teve 17 respostas.

A discussão teve um desafio a mais dessa vez, pois o tema é bem recente, tanto que há apenas um livro focado nele, o Agile Testing da Lisa Crispin e Janet Gregory. E o no Brasil há pouquíssimo material sobre o assunto. Então, acredito que o grande objetivo da discussão foi tentar desmitificar um pouco o que é Teste Ágil e como podemos implementá-lo na nossa empresa, não trazendo fórmulas mágicas ou receitas de bolo (até porque isso não existe em projetos de software), e sim experiências vivenciadas pela comunidade e conhecimentos adquiridos, que possam orientar como dar os primeiros para a agilidade no Teste de Software.

Afinal o que é Teste Ágil?

Como de praxe em uma discussão sobre agilidade, é bom apresentar os princípios ágeis do Manifesto Ágil, que também norteiam o Teste Ágil:

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Lembrando que os itens da esquerda são mais valorizados do que os da direita, mas isso não que dizer que os da direita sejam ignorados.

O Wagner apresentou de forma muito clara o que se espera quando dizemos que algo é ágil:

Sou um grande apreciador da qualidade. Por isso, acredito que tenhamos realmente que tornar o nosso trabalho cada vez mais ágil, porém, não podemos nos esquecer da qualidade, que é o forte da nossa área.  Vejo então, que devemos unir com sabedoria, essas duas vertentes. Um processo relativamente simples, que possa ser executado com grande facilidade e agilidade, cobrindo o maior número de riscos, com uma qualidade que seja apreciada e valorizada pelo usuário final. Um processo sem muitas “firulas” e com a qualidade esperada pelo cliente ou ainda, superando as expectativas do mesmo.

Na minha opinião, Teste Ágil é um conjunto de práticas que proporcionam a diminuição do tempo entre o erro e a sua descoberta, baseada no contexto ágil e nos princípios do manifesto ágil.

Para o Elias Nogueira Teste Ágil:

É uma abordagem de teste que está aderente ás práticas de agilidade descritas no manifesto ágil;

É a área de teste sendo mais pró-ativa do que reativa;

É integrar/relacionar os testes as metodologias de desenvolvimento ágil (TDD, XP, FDD, BDD, etc…).

O que muda do Teste Tradicional para o Teste Ágil?

As considerações feitas pelo Elias Nogueira deixaram claro que o Testador passa a ser um profissional muito mais dinâmico:

• Testadores serão mais pró-ativos, tendo participação direta com o cliente;
• Testadores terão um foco mais técnico, pois estarão trabalhando como par de desenvolvedores;
• Testadores precisam saber automatizar, para poder manter o ciclo de entrega dos testes sempre no mesmo tempo/sprint.

Para mim as mudanças são as seguintes:

• Acredito que a principal mudança é em como você exerce o seu papel, as técnicas a serem utilizadas para a criação dos testes e todas as outras teorias provenientes, podem te auxiliar a entender e exercer melhor as suas tarefas de uma forma mais ágil e efetiva;
• O que vejo que muda muito, é que os desenvolvedores também testam, e testam pra valer, tanto que devem haver mais testes de unidade e integração do que testes de sistema e aceitação;
• O Teste de Software se torna mais preventivo, práticas como o TDD e a Programação em Par, contribuem para melhorar a qualidade do software que está sendo desenvolvido, e evitar a inserção de erros;
• O time de teste não precisará focar nos testes que validam se o sistema está sendo de acordo com o cliente solicitou, e não se preocupam em cobrir verificações básicas, como cobertura de desvios;
• A automação é essencial para o Teste Ágil, é o ingrediente que fará o teste ser realmente ágil;
• Os testes manuais existem, mas são mais para os tipos de testes que realmente não tem como automatizar, como por exemplo: usabilidade;
• O time de teste passa a participar de forma mais efetiva e integrada com o time de desenvolvimento, não espaço para rivalidade, pois ambos trabalham focando o mesmo objetivo, entregar um produto com qualidade;
• Os testes tornam-se rotina, não é mais uma tarefa feita só no final do desenvolvimento do software.

Como podemos implementar o Teste Ágil no nosso dia-a-dia?

O Aderson Bastos vez uma interessante consideração sobre Teste Ágil em metodologias não ágeis:

É possível testar de forma ágil com qualquer tipo de metodologia de desenvolvimento, obviamente algumas metodologias privilegiam este tipo de abordagem. RUP, XP, Scrum, FDD, etc, são ótimas referências para elaborarmos uma boa metodologia, mas nenhuma delas garantirá agilidade. Não somos ágeis porque utilizamos Scrum e/ou XP, por exemplo, – lembrem-se do manifesto ágil: “indivíduos e interações mais que processos e ferramentas”!!! – somos ágeis porque pensamos e agimos assim; porque quando somos eficazes no uso de todo o conhecimento (técnicas, boas práticas…) que temos.

A Cibele listou importantes fatores que nos ajudam a saber se a implementação de uma metodologia ágil será uma boa ou não:

Onde será aplicada;

Tipo da empresa;

Maturidade de processos e dos profissionais;

Cliente;

Time;

Tipo de sistema a ser desenvolvido e várias outras coisas.

E a Cibele ainda fez importantes considerações, sobre a implementação de metodologias ágeis e Teste Ágil, com base em experiências vivenciadas:

Não basta só implantar o processo ágil, é preciso checar se há ambiente propício para isso. E mais importante, começar devagar, pegar um projeto pequeno como piloto e ter pessoas na equipe que conheçam o processo muito bem. Fica mais fácil de analisar a evolução e corrigir erros.

Não há uma receita de bolo a seguir. É preciso conhecer o processo ágil muito bem, assim como a cultura da empresa e a maturidade dos seus colaboradores e em cima disso, montar uma estratégia de implantação do processo ágil. Pelo que presenciei nesta empresa, o teste ágil está dentro do processo ágil. Mas é possível adotar práticas ágeis em testes em qualquer tipo de processo ou metodologia.

O Elias Nogueira fez as seguintes sugestões para a implementação do Teste Ágil:

• Trazendo o cliente para perto e fazendo com que ele entenda as atividades de teste e que ele entenda que ele mesmo é o principal fator de sucesso;
• Alterar nossa Cultura Organizacional (todos devem ser ágeis, da tia do café ao presidente da empresa);
• Manter a equipe atualiza e ter feedbacks constantes para todos os stakeholders;
• Estudar e implantar mais testes caixa-branca junto aos desenvolvedores;
• Prover formas automatizadas para a execução de testes em todos os níveis.

O Robson Agapito relatou como ele está começando a implantar Teste Ágil:

O primeiro passo que estamos trabalhando é treinar a equipe de desenvolvimento para estar aptos a realizar testes unitários, após isso implantado e assimilado por toda a equipe creio que será mais fácil de mudar a metodologia para alguns projetos.

Para o José Correia:

O ideal é convencer sua organização a fazer um piloto e a partir dessa experiência ir aperfeiçoando. A primeira vez não vai ser incrível. Não existem metodologias mágicas, é necessário aprender com erros e acertos, acreditar, medir, ajustar e comprovar progressivamente os ganhos.

Na minha opinião, precisamos implementá-lo de uma forma incremental, e de preferência iniciando com os testes no desenvolvimento do software:

• Antes de tudo, é preciso estudar e entender o motivo pelo qual o Teste Ágil existe;
• Implantar de forma gradativa;
• Antes de criar um teste, pensar se ele pode ser automatizado, e se vale a pena automatizá-lo;
• Lembre-se que o Teste Ágil, causa uma inversão na pirâmide dos testes, ou seja, ao invés de temos muitos testes de sistema e aceitação, teremos mais testes de unidade e integração. Então, e a responsabilidade da criação de tais testes é em primária instância do desenvolvedor;
• Atue perto do cliente, afinal você deverá ter pleno conhecimento sobre o que ele está esperando do sistema;
• Querer criar testes de unidade e integração para sistemas legados, é quase impraticável, porém para as novas funcionalidades e manutenções, por que não criar?

Quais são as maiores dificuldades para implementar-lo?

Segundo o José Correia o mercado ainda tem resistência em experimentar as metodologias ágeis:

Nos projetos  que acompanho, o uso de práticas ágeis é elegível apenas quando o número de horas totais do projeto é inferior a 1000 horas. Alguns clientes são mais conservadores e estabelecem um teto de 640 à 800 horas. Projetos acima são tocados dentro das práticas do RUP, modelos CMMI/MPS.br e os testes complementados com base no Syllabus/ISTQB, CBOK/QAI, normas ISO e IEEE.

Algumas empresas que antigamente diziam usar “metodologia própria” para disfarçar a falta de um forma de trabalho estruturada, agora passaram a dizer que são “Ágeis” o que é péssimo para as empresas que realmente utilizam as práticas e fazem um trabalho sério. Ou seja, muitas empresas de grande porte, como diversos Bancos têm grandes restrições por experiências ruins com alguns desses fornecedores.

Para o Elias Nogueira podemos enfrentar as seguintes dificuldades:

• Cultura organizacional resistente;
• Equipe não multidisciplinar;
• Cliente não é ou não gosta de ser ágil;
• Conhecer agilidade e os conceitos no Manifesto Ágil;
• Participar reativamente como área de teste (esperar todos os documentos na mão).

Eu vejo que as maiores dificuldades, tem relação as pessoas, até porque Teste Ágil antes de tudo, é uma questão de atitude:

• É uma mudança de cultura, então costuma haver uma grande resistência;
• O time de teste é forçado cada vez mais a está pesquisando sobre novas ferramentas e saber programar, pois como disse antes, a automação é essencial;
• A mudança também afeta o cliente, ele também deverá ser tornar mais participativo e comprometido com o sucesso do sistema, e passar para o time de desenvolvimento as suas reais necessidades e opiniões do sistema.

Quais as vantagens de sua implementação?

Podemos obter diversas melhorias com a implementação do Teste Ágil, não apenas no processo, mas como também na motivação das pessoas:

• O número de bugs a ser encontrados pelo time de teste tende a ser bem menor, principalmente devido ao fato do grande foco na prevenção dos mesmos;
• O desenvolvimento do software torna-se sustentável, se for necessário fazer alguma mudança, os desenvolvedores não terão receio, pois poderão executar uma bateria de testes unitários para verificar se a mudança não quebrou nada;
• As entregas passam a ser mais rápidas;
• A participação do cliente de forma mais efetiva, faz com que o software tenha aquilo que realmente o cliente deseja;
• A automação torna a execução do testes mais rápida, ou seja, passar a ser mais econômica;
• O retrabalho e manutenção será muito menor, fazendo com o que o custo e o tempo para o desenvolvimento seja menor.

O Elias Nogueira levantou as seguintes vantagens:

• Maior velocidade na execução do projeto
• Maior rapidez no conhecimento do projeto
• Entregas mais focadas na necessidade do cliente
• Cliente se sentirá feliz e realizado em ver como estão as atividades e saber realmente o que será entregue
• Maior disseminação de conhecimento técnico e de negócio para a equipe

Durante a Mesa Redonda surgiu uma boa discussão, iniciada após o Ralph Montelo compartilhar as seguintes opiniões:

Sinceramente? “Teste Ágil” são duas palavras que (infelizmente!) não combinam. Mesma coisa que dizer “Inteligência Militar”. (!)

Métodos ágeis são ótimos quando o assunto é economia e agilidade na entrega. Quanto à qualidade, prefiro não comentar. Não consigo confiar 100% em uma metodologia que preza a “não-documentação”, pois continuo seguindo minha carreira utilizando a Regra 10 de Myers à risca. E não me arrependi em momento algum.

Em resposta o Wagner disse:

Vejo que o tempo tem se tornado cada vez mais curto, por isso põem-se interessante a idéia de agilidade com qualidade. Pois a partir do momento em que o foco se torna apenas a “agilidade”, não estamos mais falando de “Teste e Qualidade de Software”.

Temos que realmente unir o “útil (qualidade) ao necessário (agilidade)”.

E o Marcelo Andrade lembrou que ser ágil é buscar fazer direito na primeira vez e produzir documentação efetiva e útil:

Ágil combina menos com “pressa” e mais para fazer direito. (Da fábula da
lebre e a tartaruga, sem dúvida, o animal que melhor representa técnicas ágeis
é… a tartaruga). Se alguém acha que desenvolver de forma ágil é fazer com
pressa, com certeza não está fazendo ágil da forma correta.

É falso dizer que métodos ágeis prezam a “não-documentação”. O mito da
documentação é algo que incrivelmente as pessoas não entendem no manifesto
ágil. Ao contrário, se preza muito toda a documentação que seja efetiva e útil.
A propósito, artefatos de testes estão entre os melhores tipos de documentação
que existem. Sugiro a leitura deste artigo:

http://www.infoq.com/br/news/2009/08/agile-documentation

Pra fechar o resumo com chave de ouro, nada melhor, do que apresentar as 7 práticas para tornar o Teste de Software ágil, que nada mais são do que soluções de um profissional que buscou a melhoria contínua e agilidade, não porque está na moda, e sim porque tornaria o seu trabalho mais efetivo, todos os créditos ao Felipe Silva, que compartilhou as seguintes práticas:

1. Planejar uma sequência de testes a serem executados de forma que em um único fluxo se consiga validar o máximo de cenários possíveis, chamamos isto de “Overlap”, pois unimos o que seria mais de um Test Case em apenas um Test Case contendo os steps de todos;
2. Automatizar ou simplificar rotinas, por exemplo criando não apenas scripts para testes, mas também scripts, macros e programas que façam coisas que você faria manualmente;
3. Ter Casos de Testes claros e diretos, se sua equipe de testes não é formada por “um monte de mães” (como na discussão passada) pode-se pensar em escrever Casos de Testes que vão direto ao ponto, o step de validação e nada mais,;
4. Gerenciar manobras de riscos, para caso o test A pare, então o B já esteja na lista para ser executado, assim não tendo impacto no prazo do delivery e enquanto estiver testando B já estar providenciando a solução para que o A volte a ser testado;
5. Trabalhar em equipe e tirar uns 20 a 30 minutos para discutir um requisito entre os envolvidos do testes economiza horas de pessoas que tem medo ou vergonha de se expor dizendo que não entenderam ou não sabem e assim sendo sem perceber atrasam a entrega e correm o risco de não fazer um teste com qualidade;
6. Suporte do cliente é fundamental, na nossa equipe hoje temos uma pessoa alocada no cliente que faz o papel de gerente de testes e revisor de requisitos ao mesmo tempo, esta pessoa é a ponte inicial para todas as dúvidas e quase sempre tem todas as respostas que teriam que sair direto do cliente, é um profissional de testes (modelo indiano de gerencia);
7. Tornar os profissionais especialistas em partes do projeto, de modo que todo mundo saiba um pouco do projeto como um todo e você sempre terá 1 especialista em qualquer assunto do projeto, tendo assim na soma dos profissionais uma equipe especialista, as vezes sabendo mais que o próprio cliente do assunto, entendimento rápido do negócio gera processos ágeis para o teste, seja na criação ou na execução dos testes.

Se interessou pelo assunto, então confira a discussão na íntegra, acessando o DFTestes. E se quiser participar das próximas Mesas Redondas, é só fazer a sua inscrição no grupo.

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

Impressões do 6º Encontro Mensal da ALATS São Paulo – parte 2

Ontem, às 19:00 teve início a segunda parte da palestra “Agile e Scrum – O Tsunami da Agilidade na Praia dos Testes: Novos Modelos, Novas Ferramentas”, feita pelo Jorge Diz, no 6º Encontro Mensal da ALATS. A primeira parte da palestra ocorreu no final do mês setembro (30/09/09), porém teve que ser encerrada, antes do seu término, por ter ultrapassado o tempo disponível.

Abaixo, compartilho as minhas impressões sobre o encontro.

Sprint 1

Como de costume (aliás, um mal costume) cheguei em cima da hora. Ao entrar no auditório percebi que público presente era menor do que da última palestra, totalizando 9 pessoas. E dentro do auditório tinha uma mesinha, com o coffee, o que me fez pensar que não haveria o break, fato que acabou se concretizando. Ou seja, o Jorge planejou passar todo conteúdo numa sprint única.

O início da palestra se deu com o palestrante falando sobre o novo modelo de testes, necessário ao se utilizar metodologias ágeis. Utilizando a excelente explicação do fluxo ponta-a-ponta (erro -> defeito -> falha -> diagnóstico -> correção), influenciado pela metodologias ágeis, onde:

• O erro pode ser evitado utilizando o conceito de Poka-yoke, como por exemplo, usando linguagens de tipagem forte (ex. Ruby);
• Outra maneira de utilizar uma ferramenta que execute automaticamente os testes, a cada mudança nos arquivos do projeto relacionados com a mudança, ou seja, uma ferramenta que faça um teste de regressão de acordo com a mudança realizada, para verificar se a mesma não quebrou nada. Exemplo de tal ferramenta é o Autotest (que faz parte do pacote ZenTest);
• Para encontrar defeitos é necessário… testes :);
• É possível facilitar a identificação do motivo da falha, analisando a pilha de execução, exceções, logs e utilizando predicados fluentes (uma maneira de torna mais legível o método);
• Para realizar o diagnostico é necessário ter uma gestão de configuração e depois reportar utilizando uma ferramenta de gestão de incidentes, famoso bugtracking;
• Após a correção, se faz necessário a realização dos testes de regressão.

Agora você pode está pensando: mas boa parte das coisas que foram citadas eu já realizo no meu dia-a-dia?

Porém, utilizando agile muita dessas tarefas são realizadas de forma automatizada, realizando integração contínua, que acaba minimizando a quantidade de defeitos que seriam encontrados pela pessoa que fosse realizar o teste. E o mais importante é que o foco das metodologias ágeis é que o feedback  possa ser o mais rápido possível (lembra do manifesto ágil: “Indivíduos e interação entre eles mais que processos e ferramentas”. Trazendo isso para a realidade de Teste de Software, significa que o fluxo ponta-a-ponta será mais ágil;) o desenvolvedor pode receber o feedback da existência do defeito em “tempo de programação”, utilizando uma ferramenta do tipo Autotest.

Um ponto interessante que o Jorge Diz levantou, foi a carência de fontes falando sobre Teste de Software em metodologias ágeis, porém há uma excelente fonte, o livro da Lisa Crispin e Janet Gregory chamado Agile Testing (eu tenho ele, e recomendo fortemente aos interessados, é sem dúvida, a melhor bibliografia sobre o assunto até o momento).

Em seguida, o palestrante apresentou novamente a pirâmide frágil, na qual a maioria dos testes executados são testes de interface e poucos testes de unidade e integração são realizados. E o modelo ágil propõe uma inversão dessa pirâmide, como pode ser visto na figura abaixo.

Uma boa metáfora existente para explicar a diferença entre os três níveis de teste apresentados na pirâmide, feita pelo Patrick Wilson-Welsh, citado no livro Agile Testing, é a do três porquinhos. A camada de baixo é feita de tijolos, os testes são sólidos, e não vulneráveis ao sopro do lobo mau. Já a camada do meio é feita de madeira, precisa ser modificada com uma frequência maior do que a camada de tijolos, para permanecer resistente ao sopro do lobo mau. Por fim, a camada do topo é feita de palha, é difícil ela ser mantida no seu lugar e o lobo pode facilmente derrubá-la. Ou seja, se temos muitos testes feitos de palha, iremos precisar gastar muito tempo colocando-os no lugar.

Logo após, a explicação sobre a pirâmide dos testes, Jorge Diz falou sobre as escolas de teste, e os consensos que existem em comum entre elas:

• Não é possível testar tudo;
• Quem testa deve ter atitude crítica;
• Testes tem custo;
• Testes informam sobre risco;
• Áreas concentram defeitos (bug clusters).

Encerrada a parte dos consensos, chegou a hora de falar sobre automação de testes no contexto ágil. Parte na qual foi apresentada uma série de ferramentas, de acordo com cada nível de teste e também uma explicação de alguns conceitos.

Para iniciar o assunto, o Jorge Diz logo apresentou as vantagens e desvantagens da automação:

Vantagens

• Menos sujeita a falhas humanas, desatenção;
• Menos sujeita a interpretações;
• Executar testes automatizados é muito mais barato que manualmente, quando repetidos;
• Regressão torna-se mais abrangente.

Desvantagens/Dificuldades

• Dependência de sistemas externos;
• Dependência internas do sistemas;
• Controle sobre o ambiente;
• Lentidão em alguns tipos de teste;
• Fragilidade da API/interface usuário;
• Custo da automação pode ser alto;
• Necessidades de pessoas especializadas, o que geralmente, gera um maior custo.

O Jorge explicou um paradoxo bem interessante, o do campo minado,  no qual ficou bem claro a necessidade de realizar variações de cenários/caminhos de teste. Afinal, o intuito testes é que as minas explodam. 😉

Continuando a explicação sobre automação de testes, foi a vez de falar sobre as ferramentas existentes para realizar testes de sistemas Web:

• Simular o browser – htmlUnit, Webrat;
• Executar in browser em javascript – Selenium;
• Adicionar browser a partir de um programa em Java – Selenium RC;
• Acionar browser a partir de um plugin do browser – Selenium IDE;
• Acionar browser a partir de um wiki – StoryTest IQ (Selenium + FitNesse);
• Acionar browser a partir de um editor de workflow – CubicTest (Selenium + plugin Eclipse).

E necessário ter conhecimento sobre o que estamos testando, com determinada ferramenta, e para explicar isso, o Jorge citou as seguintes ferramentas:

• Xunit – Módulos, classes isoladamente;
• FIT – regras de negócio;
• Cactus – funcionalidades de componentes web;
• Selenium– Interface usuário;
• JMeter – Estresse/desempenho.

Depois foi a vez de falar sobre as ferramentas XUnit, onde o Jorge começou falando que o programador gosta de programa e não gosta de tarefas manuais e repetitivas e por isso devem investir na utilização de tais ferramentas, para realizar os testes de forma automática e aumentar a qualidade do código.

Com testes automatizados,  os programadores conseguem gostar de testes, e testar torna-se uma tarefa central do desenvolvimento.

Em um time focado em automação de testes, há algumas mudanças:

• Testes passam a ser ferramentas de desenvolvimento;
• Teste unitário ocorre paralelo à codificação;
• Rede de segurança para refatoramento;
• Exemplos de uso do código sendo desenvolvido;
• Complementos à compilação passam a existir (testes unitários, por exemplo);
• Especificação de comportamento;
• Validação para a integração contínua;
• Adoção de um ambiente comum;
• Infraestrutura para outros tipos de teste.

É importante também salientar as premissas para os testes unitários:

• Teste unitário centrado no desenvolvedor;
• Resultado independente da ordem de execução;
• Independência entre métodos de teste;
• A suíte de testes deve ser executada em alguns segundos;
• Todo recurso está sob controle do programador (não pode depender do link de internet, banco de dados, sistema legado, etc);
• Não é testada a integração;
• Testes na mesma linguagem que o código sob teste;
• Resultado não sujeito a interpretação (ou passou ou não passou);
• Não colocar if no método de teste, se tiver ele é suspeito.

O Jorge Diz falou que o grande problema de realizar testes unitários é lidar com dependências. Levantando os seguintes pontos:

• Se não consigo instanciar facilmente, não consigo testar;
• Dependências podem se manifestar apenas em tempo de execução;
• Dependências problemáticas precisam ser eliminadas ou substituídas.

Então a dúvida que surgiu foi: como lidar com dependências?

E a resposta: é preciso eliminar ou substituir.

Eliminar

• Mudança no design para melhorar a testabilidade (exemplo da “vareta” para verificar o nível de óleo do motor);
• Código-alvo precisa mudar para poder ser testado.

Substituir

• Colaboradores substitutos em tempo de testes;
• Dependências configuráveis(injeção de dependência, instrumentação).

E o importante: Se não conseguir eliminar ou substituir, não é teste unitário!

Em seguida o Jorge fez uma bela explicação sobre os colaboradores:

• Dummy (sub objeto) – esta aí apenas para cumprir tabela;
• Stub (método) – retorna uma resposta pré-definida;
• Mock (objeto)- define previamente o comportamento esperado das interações da classe-alvo com o colaborador (proativo se ver algo errado ele já avisa, pois ele já tem incorporado o que tem que ser feito no Play[quando executa o teste]);
• Fake (serviço/objeto) – substitui um serviço por uma implementação mais apropriada para o testes;
• Spy (método/objeto)- registra comportamento para verificação posterior.

E há duas maneiras de testar de forma unitária:

• Teste de estado – Verifica o estado da classe-alvo depois de exercitar uma funcionalidade;
• Teste de interação- Verifica a comunicação da classe alvo com seus colaboradores.

Logo após a explicação sobre testes unitários e o uso de Xunit, o Jorge começou a explicação sobre o Selenium, e suas variações, que é voltado para testes de interface Web. E na sequência o Jorge falou sobre o FitNesse, voltado para testes de aceite.

O FitNesse tem as seguintes características:

• Ferramenta wiki, que pode ser utilizada por Analista de Teste e de negócios;
• Especificação de requisitos em planilhas;
• É possível utilizar o FitNess usando DSL (Domain specific language), que serve para que seja criada uma linguagem mais próxima do usuário, você cria um conjunto de frases que podem ser utilizados depois;
• Codificação de fixtures pode ser feita por programadores.

Também é possível importar um arquivo do excel para html, que é interpretado pelo FIT (FiTNess = Fit + Wiki).

Depois o tema foi BDD (Behavior-driven development), no qual há um formalismo para escrita de testes de cenários de negócio, geralmente da seguinte maneira:

• Parte explicativa: Sendo um <Papel>, eu quero <funcionalidade>, porque <motivação>;
• Parte executável: Dado que <pré-condições>, quando <ação>, então <verificações>.

Por fim, o Jorge citou as ferramentas que podemos usar com BDD:

• FiTNEss+DoFixture;
• JBehave (Java);
• Easyb (Groovy);
• Cucumber (Ruby).

Após, o término da palestra começou uma sessão de perguntas, que logo se tornou numa “mesa” de discussão (muito boa por sinal), onde variados temas foram discutidos: CMMI e metodologias ágeis, RUP é ágil ou não, dificuldades de implantar agile, as mudanças que ocorrem na área de Teste de Software e a maneira que ser realiza os  testes e vários outros assuntos relacionados a palestra.

Conclusão

A segunda parte da palestra do Jorge Diz, foi muito boa. Ele começou já falando sobre metodologias ágeis, e a palestra fluiu muito bem, sobrando até um bom tempo para as perguntas, que acabaram gerando uma excelente discussão (não é todo dia que você consegue discutir sobre agile e Teste de Software). 🙂

Com a palestra do Jorge Diz, acredito que ficou claro para todos os presentes, que o tsunami da agilidade pode melhorar muito a maneira como realizamos os testes, tornando o processo muito mais efetivo, além disso, as metodologias ágeis já tem na sua essência a preocupação com a qualidade do software, e ela não é uma preocupação/responsabilidade de apenas uma área, e sim de todos comprometidos com o projeto. 😀

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