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.