Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)

A discussão da sexta Mesa Redonda DFTestes foi sobre a “Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD…)”, discussão que gerou13 respostas, e teve 8 participantes: eu, Renata Eliza, Marcelo Andrade. Juliana Kryszczun, Felipe Silva, Ronaldo Cruz, Jorge Diz e o Vitor Machel.

Abaixo, segue um “resumo” do que foi discutido na mesa redonda, lembrando que é altamente recomendável, a leitura de toda a discussão caso você tenha interesse pelo assunto.

Metodologias Ágeis e Teste de Software, tudo a ver ou não?

Para o Marcelo Andrade, “não há como se seguir qualquer técnica dita “ágil” se não se tiver uma forte disciplina em teste de software” e ainda complementou dizendo:

Escrevi um post sobre isso há algum tempo no Blog do TaSAFO – http://tasafo.wordpress.com/2009/05/14/se-voce-nao-testa-voce-nao-e-agil/

Para simplificar, ao falar de testes, me refiro especificamente a testes de aceitação, uma vez que testes de unidade, a rigor, são parte do desenvolvimento de software. Assim, é importante levar a etapa de testes a sério, automatizar os testes, reforçar seu uso, etc. Um pensamento interessante que por acaso li hoje num post do InfoQ é que “automatização de testes de software É software”.

Enfatizo, entretanto, que se você não tem disciplina para conduzir seus testes adequadamente, de nada adiantará tentar “implantar agilidade”, com muito se diz. Isso me remete a outro tema proposto para a mesa redonda sobre como evitar o “Testa aí”, bem como também reforça uma opinião pessoal que tenho de que a palavra “ágil” é ruim, pois pode descambar muito facilmente para ser um mero termo mercadológico ou como marketing para empresas.

A respeito do que o Marcelo disse sobre a palavra “ágil”, acredito que o problema aqui é a interpretação das pessoas, e não a palavra em si. Quanto a ser um “mero termo mercadológico ou como marketing para empresas”, é fato mesmo, infelizmente, muitas empresas que antes diziam que utilizavam uma metodologia própria, agora dizem que usam metodologia ágil, pelo simples fato, de que está na moda ser ágil.

E outro ponto interessante, é que empresas que se dedicaram e se dedicam ainda, no estudo e no uso de metodologias ágeis, acabam sempre utilizando uma mescla das metodologias ágeis, e até alterando algumas coisas. Exemplo, a globo.com … ou seja, não existe a melhor metodologia, principalmente numa área tão volátil como a nossa.

A Juliana Kryszczun lembrou sobre o maior problema ao tentar implantar uma metodologia ágil:

O primeiro problema, na minha opinião, é a quebra de cultura. Estamos tão acostumados ao processo tradicional que ficaria um pouco complexo implantar um novo modelo de teste em uma equipe ‘velha’ e já definida.

O Felipe Silva ressaltou que o importante é o resultado a ser obtido com a mudança, se for melhorar vale a pena lutar:

O fato à ser considerado é, melhorar, melhorar e melhorar. Se existe algo, independente do nome, seja SCRUM, XP, LEAN, KAN BAN, e por aí vai, se isso for te acrescentar Benefício então vamos à “guerra”, mas não um contra o outro, porque senão “a casa cai”, mas vamos à guerra em equipe como um exercito, traça-se as estratégias, as táticas (ler A Arta de Guerra por Sun Tzu), analisa-se o terreno e o tempo, as fraquezas e as forças, conscientiza, motiva e integra os soldados no “problema”, o “problema” tem que ser de todos, uma vez o benefício também será de todos. Levantados os dados e os riscos é hora de marchar, repetindo e analisando a palavra “Marchar”, uma marcha é o exército todo em formação e alinhado cada um na sua posição dado passo à passo em sincronia, levantando e abaixando o pé ao mesmo tempo, seguidos pelas direções do general e pelo ritmo dos tambores, passo a passo (Não de uma vez, como tentam fazer alguns, que pensam que um processo novo cai de sem pára-quedas e irá funcionar), o general atento é quem observa se muda a direção ou o ritmo da marcha, ainda que esteja chovendo se o general diz “Marchem” assim deve ser feito para que se alcance o objetivo da estratégia traçada.

Para o Ronaldo Cruz para ser veloz, os testes são mais necessários ainda:

Claro que sim, uma vez que a elaboração de um produto tem de ser feita de forma mais rápida, os teste são ainda mais necessários, o risco de em meio a extrema velocidade se perder ou esquecer de alguma coisa é bem alto.

Segundo o Jorge Diz:

Sim: há uma grande sinergia. De fato, grande parte do (re?)nascimento do interesse em teste de software se deve à adoção de práticas de teste integradas ao desenvolvimento ágil. A comunidade ágil introduziu novos formalismos (ex: BDD, ATDD com planilhas, DSLs), novos mecanismos de isolamento de unidades  para teste (ex: test doubles/mocks), novas ferramentas (ex: JUnit) e, principalmente, novas formas de olhar  para os testes não apenas como mecanismos de controle da qualidade mas também como uma forma de especificação verificável mecanicamente, como forma de comunicação e como instrumento de gestão.

A automação cresceu em importância (inicialmente, talvez exagerada) e puxou avanços na tecnologia de testes  como nunca antes na história da nossa área.

Para o Vitor Machel é necessário que o Teste de Software se adapte a nova metodologia:

Sim tem tudo a ver, como qualquer processo de desenvolvimento de sistemas, mas não se pode ficar com o mesmo pensamento com metodologias tradicionais, tem que se enquadrar também.

Na minha opinião, boa parte das metodologias ágeis (para não falar todas), nasceram da prática, da tentativa de fazer coisas diferentes para tentar obter resultados diferentes, E dentre essas “coisas” diferentes, os profissionais perceberam que Teste de Software é essencial, pois ajuda a garantir a qualidade do produto, e perceberam também, o quanto é importante executar o Teste de Software o mais cedo possível, seja por meio da revisão, proporcionada pela programação em par, seja pela própria criação de testes unitários pelos desenvolvedores.

Scrum e Teste de Software combinam?

A Renata Eliza acredita que sim:

Acredito sim, que as “Metodologias Ágeis” e o Teste de Software têm tudo a ver.

Falando especificamente do SCRUM, não há quem diga que ele pode ser utilizado em qualquer área da vida?!
Por quê não no Teste de Software?

Um projeto que utiliza Scrum terá uma maior facilidade para responder às mudanças que podem ocorrer.

Focando nos princípios dos processos ágeis aplicados pelo Scrum, é possível enumerar centenas de motivos para implantá-lo.

O maior objetivo continuará sendo a garantia da qualidade dos sistemas, porém, através o Scrum será possível gerenciar de forma rápida os testes.

Os objetivos são melhores definidos e as tarefas demandadas de forma mais direta, com prazos que são cumpridos quase em sua maioria. O foco, que geralmente se perde em alguns projetos, é levado a sério.

A Renata ainda citou alguns dos benefícios da implantação do Scrum:

Verificar o andamento de cada projeto como um todo;

Permitir a detecção e remoção de riscos e impedimentos;

Oferecer uma estimativa mais apurada;

Controlar conflitos de interesses e necessidades;

Compartilhar o conhecimento entre a equipe.

O Ronaldo Cruz lembrou que é de extrema importância a atitude dos envolvidos com o projeto:

Sim. Na verdade, todo modelo de desenvolvimento combina com teste. A questão é o quanto as pessoas e empresas estão dedicadas em fazer as coisas acontecerem. De nada vale dizer que usa SCRUM, XP, RUP, abobrinha, chuchu ou cenoura, se a empresa e os envolvidos não estão realmente engajados em implementar o modelo e fazê-lo acontecer.

O Jorge Diz acredita que sim e complementa:

O conceito de pronto-pronto, aplicado às user stories, tem que incluir testes. Apesar de Scrum ser um framework de práticas de gestão, ele acaba puxando a necessidade da adoção de práticas técnicas que permitam  entregas com qualidade, o que puxa a necessidade de investir na garantia e controle da qualidade: as práticas técnicas de XP casam bem nesse contexto.

Um anti-pattern comum é ficar só nas práticas de gestão, ignorando os sinais evidenciados pelo choque de transparência proporcionado pelo Scrum (radiadores de informação, reuniões diárias, retrospectivas). A necessidade de melhoria de processo envolve necessariamente as técnicas que usamos para entregar software.

Assim, é impossível melhorar o produto de software sem mudar as técnicas de requisitos, de desenvolvimento,  de integração e de teste. Se não houver mudanças, a equipe não consegue dar vazão às entregas. Como disse Einstein, é loucura continuar fazendo as mesmas coisas e esperar resultados diferentes: os post-its na parede não possuem  superpoderes.

O Vitor Machel acredita que não:

Se pensar à risca, não porque teste de software por equipe de teste, não entra no conceito de SCRUM

Eu acredito que Scrum combina com qualquer tipo de projeto, desde para organizar uma faxina na casa com a família, até a construção de um foguete.
E para nós, um dos pontos mais importantes do Scrum, é trazer o cliente para próximo do time, seja esse cliente, ou melhor PO (Product Owner), interno ou externo.

Preciso seguir a risca a metodologia ágil ao implantá-la?

Segundo o Ronaldo Cruz:

Não. Como o próprio nome diz, é um modelo, um meio estruturado de executar o trabalho. Cada empresa tem sua particularidade, seja do projeto, dos funcionários, do cliente, da cultura em si. Você pega as praticas do modelo e as adapta ao seu ambiente.

O Jorge Diz compartilhou a sua opinião dizendo:

Não creio que exista “a” metodologia ágil. Aliás, uma das premissas embutidas no conceito de agilidade é a crítica contínua ao processo. De alguma forma, a agilidade é uma reação ao “the one right way¨ de Taylor, imposta por decreto, que sobrevive neste início do século XXI como o eufemismo “melhores práticas”.

Reformulando a pergunta, dada uma metodologia documentada (Scrum, FDD, XP, …) identificada com os princípios da agilidade, é necessário implementar de acordo com o livrinho?

Alguns (o Kent Beck do XP, por exemplo), dizem que sim, por causa da sinergia entre as práticas. Minha posição é que precisamos ter jogo de cintura, mas sem descaracterizar as práticas que fazem a dinâmica funcionar. Sempre existem limitações e precisamos contorná-las.

O problema é que, quando somos iniciantes, ainda não temos incorporados os conceitos de uma metodologia: só aprendemos de verdade fazendo, descobrindo o que é importante e o que é acessório, onde precisamos bater o pé e onde podemos ceder, o que funciona bem num certo contexto e o que precisamos evitar. Por este motivo é importante também, se possível, ter um acompanhamento de pessoas mais experientes durante o início de uma transição para a agilidade (sou suspeito para falar, porque faço esse tipo de serviço)

É bastante comum que as organizações que adotam uma nova metodologia façam adaptações não por restrições externas, e sim para evitar as práticas que mais mudam a forma de trabalho à qual estão acostumadas, por acomodação ou por medo da mudança. Isto é tão comum no Scrum que já ganhou um nome: “Scrum, but …”.

“Estamos fazendo Scrum, mas dispensamos as reuniões diárias”. “Estamos usando XP, mas não temos testes unitários”. Neste anti-pattern, muda-se o processo muito precocemente, descaracterizando-o. O resultado é que a chance de sucesso diminui drasticamente, e a metodologia em questão aparece mal na foto.

Para mim o by the book está LONGE de ser a melhor maneira de implantar algo, principalmente na nossa área. Adaptação é a palavra chave, e adaptação não é feita uma única vez, temos que está sempre evoluindo e melhorando, e para isso a adaptação é essencial. 🙂

O que o XP tem a ver com o Teste de Software?

O Jorge Diz fez uma bela explanação respondendo a questão, deixando bem clara a relação entre o XP e o Teste de Software:

Muita coisa. XP representou no início uma visão bastante peculiar em relação a teste de software. Simplificando:

Há os “testes do programador”, de um teor mais técnico, e que funcionam como apoio ao desenvolvimento: o desenvolvedor é o responsável. Precisam passar integralmente o tempo todo, e ser muito rápidos para não quebrar o fluxo de trabalho do desenvolvedor (na ordem de alguns segundos).

Há os “testes do cliente”, mais próximos do negócio, que ajudam a detalhar os requisitos funcionais, e que são de responsabilidade do “cliente presente”, representante dos solicitantes. Funcionam como testes de aceitação e precisam passar para que a user story seja declarada pronta.

As atividades de inspeção se fundem dentro da prática de trabalho em pares (“pair programming”). Esta  inspeção contínua “dentro do fluxo” é em geral mais eficaz que as inspeções tradicionais “fora do fluxo”  (estilos Fagan e Gibbs). Está ai um exemplo de prática que faz sentido dentro da dinâmica, mas que é  resistida por problemas culturais e políticos: não podemos simplesmente ignorar a necessidade de inspeções. Se não podemos implementar inspeções no fluxo, precisamos substituir por outras formas de revisão ou inspeção fora do fluxo.

É grande a ênfase na automação dos testes. Isto puxou uma série de inovações técnicas para tornar o teste possível no ritmo necessário para apoiar o desenvolvedor. Na cultura de XP, inicialmente não era dada tanta importância aos  testes manuais.

Mais recentemente, têm sido dada importância aos testes manuais, principalmente pela contribuição da escola de “context-driven testing” para testes exploratórios gerenciados.

Uma ressalva: TDD = “test driven development” é considerada uma prática de apoio ao desenvolvimento (design de API, principalmente) e não uma prática de teste. TDD é a junção de duas práticas: “test-first” (escrever o teste automatizado logo antes que o código sob teste) e “refactoring” (limpeza do código sem alterar o comportamento funcional, tal como validado pelos testes). Brian Marick propõe substituir a frase “TDD” por “example-driven development” para esclarecer este fato.

Como foram as experiências de vocês ao utilizarem processos ágeis?

O Ronaldo Cruz compartilhou a sua experiência dizendo:

Para mim foi muito boa. Tornou o trabalho mais fácil por ter uma interação maior com todos os envolvidos. Mas também exigiu uma mudança maior na postura. Qualquer membro da equipe, seja desenvolvedor, banco ou teste, tem de se tornar ágil. Sair da cadeira e correr atrás, seja para desenvolver a atividade de outro membro ou tirar duvidas de teste ou negócio, não importa, cada um da equipe precisa deixar de ser acomodado e se tornar pró-ativo, buscar a solução e ajudar os demais a concluírem as suas atividades. Na equipe em que trabalho, me tornei analista de teste, negócioe dou suporte ao pessoal do desenvolvimento.

O Jorge Diz compartilhou um pouco da sua experiência como consultor, citando os problemas da disciplina de testes neste contexto:

É comum as pessoas empacarem justamente por dificuldades na automação de testes no nível necessário para  suportar a agilidade. Alguns pontos de atenção:

• Código legado difícil de testar;
• Falta de disciplina de test-first por parte dos desenvolvedores;
• Não domínio das técnicas de isolamento para testes unitários;
• Investimento excessivo em testes frágeis (GUI), que pode diminuir a velocidade das atividades de teste;
• Indisponibilidade de ambiente próprio para teste, onde a aplicação possa ser testada sob controle total da equipe de desenvolvimento/testes;
• Testadores ainda perdidos numa nova forma de organizar as equipes (testador residente em vez de operário de uma fábrica de testes);
• Dificuldade para satisfazer o pronto-pronto;
• Resistência à programação em pares.

O Vitor Machel contou um pouco da sua experiência:

Totalmente satisfatórias, os documentos (NÃO SÃO TODOS) que só serviram para ir para o lixo, nem existe mais. O conceito que estamos usando é “faça somente documentos para usar e entregue o software funcionando”, dificilmente estamos trabalhando (tanto teste quanto desenvolvimento) depois das 18 e sábados e domingo, o que eu mais gostei. Em resumo aqui, todos estão aprovando, cliente satisfeito é tudo, o resto é resto.

Eu tive ótimas experiências e também experiências ruins. 🙂

Abaixo, algumas conclusões tiradas dessas experiências:

• A cultura das pessoas e da organização é o que mais influencia a implantação de uma metodologia ágil;
• A maturidade das pessoas também é um fator bastante influenciador, principalmente, em relação ao tempo que a implantação vai levar e como ela ocorrerá;
• A comunicação é essencial, tanto interna quanto externa;
• O PO é o cara (no bom sentido é claro), a sua participação é essencial para o sucesso do projeto;
• As pessoas são o diferencial de qualquer projeto. As pessoas certas com domínio da tecnologia, conhecimento do projeto e determinação são capazes de resultados incríveis, e a adoção de metodologias ágeis potencializa esses resultados;
• A metodologia utilizada pode ter dado certo em um projeto, mas isso não garante que ela também irá funcionar em outro;
• Busque ter uma pessoa da área de Teste de Software, no seu time Scrum;
• Antes de implantar uma nova metodologia, der treinamentos a respeito dela para todos;
• Se algo deu errado, com certeza não é culpa da metodologia, e sim sua! 🙂

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