Capítulo 6: Utilização de Processos Ágeis no Teste de Software (SCRUM, XP, TDD...)

De Dftestes

Autoras: Maíra M. Dutra e Patrícia Silva Corrêa
Revisora: Patrícia Silva Corrêa

Tabela de conteúdo

Processos ágeis? Que isso mesmo?

Processo, ou metodologia de desenvolvimento de software pode ser enxergado como um conjunto de atividades que auxiliam a produção de software. Essas atividades culminam em um produto que reflete a forma como todo processo foi conduzido.

Muitas organizações desenvolvem software sem usar nenhum processo. Geralmente isso ocorre porque os processos tradicionais não são adequados as suas realidades. Em particular, as pequenas e médias organizações não possuem recursos suficientes para adotar o uso de metodologias “pesadas”, e, por essa razão, normalmente não utilizam nenhum processo. O resultado dessa falta de sistematização na produção de software é a baixa qualidade do produto final, além de dificultar a entrega do software nos prazos e cursos predefinidos e inviabilizar a futura evolução do software.

E na busca por soluções para esses problemas, atualmente existe um interesse cada vez maior nos métodos ágeis de desenvolvimento de software. “O termo metodologias ágeis tornou-se popular em 2001, quando 17 especialistas em processo de desenvolvimento de software, representando os métodos (XP), Scrum, DSMD, Crystal dentre outros, estabeleceram princípios comuns compartilhados por todos esses métodos. O resultado foi a criação da Aliança Ágil e o estabelecimento do Manifesto Ágil.”[4]

Uma das características dos processos ágeis é que eles não são centrados nos artefatos (documentação). “Valorizando mais software em funcionamento, do que uma documentação abrangente”, acaba-se incentivando a produção de documentação apenas em momentos que se faz necessário, ou seja, deixa-se em aberto a quantidade e artefatos que serão produzidos, para que a pessoa decida, de acordo com a sua realidade. E orientam, que deve-se valorizar mais o software em funcionamento, do que a produção de uma documentação extensa.

Outra forte característica dos processosságeis é que são adequadas para situações, em que a mudança de requisitos é frequente. Para ser realmente considerada ágil, a metodologia deve aceitar a mudança, ao invés de tentar prever o futuro no começo do projeto. Além disso, reconhecer que as pessoas são os principais condutores e responsáveis pelo sucesso do projeto.

Mas e o Teste de Software, se encaixou nesses novos processos?

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 oito participantes: Fabrício Ferrari, Renata Eliza, Marcelo Andrade. Juliana Kryszczun, Felipe Silva, Ronaldo Cruz, Jorge Diz e o Vitor Machel, e buscou responder as seguintes questões:

E também contou com as experiências dos participantes ao utilizarem processos ágeis.

Dito isso, refresquemos as ideias e vamos à leitura!

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

O Marcelo Andrade transmitiu a seguinte ideia "não há como se seguir qualquer técnica dita ‘ágil’ se não se tiver uma forte disciplina em teste de software. Teste é uma das essências do desenvolvimento ágil."

Boa parte das metodologias ágeis surgiu da necessidade de fazer coisas diferentes, para que resultados diferentes fossem obtidos. Uma das diferenças percebida é que Teste de Software é essencial, pois ajuda a garantir a qualidade do produto.

O renascimento do interesse em teste de software é causado pela adoção de práticas de teste integradas ao desenvolvimento ágil, como formalismos (BDD, ATDD com planilhas, DSLs), novos mecanismos de isolamento de unidades para teste (ex: test doubles/mocks) novas ferramentas (ex: JUnit) e principalmente uma nova forma de olhar para o teste, enxergando-o não apenas como uma forma de especificação verificável mecanicamente, mas como forma de comunicação e como instrumento de gestão, como nos mostrou o Jorge Diz, que também relembrou que a automação cresceu em importância e puxou avanços na tecnologia de testes como nunca antes na história da nossa área.

Como o termo ágil nos traz a idéia de velocidade, de rapidez, podemos nos apoiar na ideia do Ronaldo Cruz para enxergar a combinação entre Testes e Metodologias Ágeis: "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." Porém, como nos lembrou o Vitor Machel, existe a necessidade de que o Teste de Software se adapte aos valores da metodologia: "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."

Scrum e Teste de Software Combinam?

Existe uma ideia que o Scrum pode ser utilizado em qualquer contexto em que uma equipe precise trabalhar junta em prol de um objetivo comum. A partir essa ideia, a Renata Eliza nos guia "falando especificamente do Scrum, não há quem diga que ele pode ser utilizado em qualquer área da vida?! Por que não no Teste de Software?" E o Fabrício completou: "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”. Mas existe também que não concorde, o Vitor Machel, nos diz que: "Se pensar à risca, não porque teste de software por equipe de teste, não entra no conceito de Scrum". Examinemos as visões explicitadas pela mesa redonda.

Um projeto que utilize Scrum terá maior facilidade para responder as mudanças que vierem a ocorrer durante o decorrer do processo de Desenvolvimento. Buscando base nos princípios dos processos ágeis, torna-se possível enumerar uma série de motivos pra implementá-lo. O objetivo principal continuará sendo a garantia da qualidade dos sistemas.

O Scrum utiliza de meios e ferramentas bem claras para comunicação, como por exemplo, o quadro Kanban, que faz com que os objetivos e as tarefas estejam mais claras e para todos da equipe. Além disso, há um grande foco em reuniões de alinhamento, focadas em objetivos específicos, como por exemplo a daily meeting, onde o objetivo é alinhar como está o andamento do trabalho da equipe.

Essa dinâmica diferente, que acaba sendo mais simples e facilita a equipe ter foco no trabalho que é necessário ser feito, pode resultar num melhor gerenciamento dos testes e também num fluxo mais rápido das tarefas, em comparação, com metodologias tradicionais.

Com a implantação do Scrum é possível

Vale lembrar também que um dos pontos mais importante do Scrum é trazer o cliente para perto do time.

Focando o Scrum na atividade de Teste, o Jorge Diniz nos trouxe outra importante percepção: " O conceito de pronto, aplicado às user stories, tem que incluir testes."

Como o Scrum é um framework de práticas de gestão, é necessário que também se adote em conjunto práticas técnicas que irão permitir que as entregas atendam sempre aos padrões de qualidade. As práticas de XP vêm a se encaixar bem nesse contexto.

Para não se prender somente nas práticas de gestão e chegar a um anti-pattern, é necessário foca-se também nas técnicas usadas para entregar software. É impossível melhorar o produto 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 conseguirá dar vazão as entregas. Os post-its na parede não possuem superpoderes, por isso nada de esperar melhorias sem mudanças.

Para concluir, refletimos sobre as colocações do Ronaldo Cruz:

"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 que o XP tem a ver com o Teste de Software?

O XP - Extreme Programming, desenvolvido por Kent Back e Ward Cunningham, é conhecido como o mais popular dos métodos ágeis. É indicado para equipes pequenas e médias, que necessitam desenvolver softwares em que os requisitos não estão totalmente especificados e que também se modificam rapidamente. Os valores principais são: comunicação, simplicidade, feedback e coragem.[2]

Após essa breve visão, nos resta responder a questão: "O que o XP tem com o Teste de Software?"

Para o Jorge Diz, o "XP representou no início uma visão bastante peculiar em relação a teste de software".

De uma maneira bem sintetizada, pode-se dizer que o XP distribuiu o Teste de Software em dois: os Testes do Programador e os Testes do Cliente.

No Teste do Programador, o desenvolvedor se torna responsável por testar seu próprio código. Para cada user story, é escrito um teste que atenda a funcionalidade. Após a escrita do teste o desenvolvedor implementa o código. Dessa forma, o teste tem um teor altamente técnico e funciona como um apoio ao desenvolvimento do software.

A cada novo teste construído, é necessários que eles sejam integrados à bateria de testes existentes. A cada integração, os novos testes não podem causar falhar nos antigos e essa integração contínua precisa ser rápida para que o fluxo de trabalho de desenvolvedor não seja quebrado.

Já o Teste do Cliente, funciona como testes de aceitação. Os clientes validam cada user story e com essa validação, o requisito desta user story é declarada pronta.

Outra característica do teste cliente é o detalhamento dos requisitos funcionais do sistema. Uma vez que os clientes estão mais próximos do ambiente de operação do sistema, para eles é mais fácil levantar novas regras e requisitos sobre o software em desenvolvimento.

As atividades de inspeção também estão presentes no XP. Nesse processo, as práticas de inspeção se fundem dentro da prática de trabalho em pares ("pair programming"). Esta inspeção contínua, é mais eficaz que do que a inspeção tradicional, uma vez que as inspeções tradicionais são feitas após o fluxo de desenvolvimento.

Mas nem tudo são flores em relação a inspeção. Essa prática exige uma mudança na cultura do programador, e ela não costuma ser fácil.

Outra forte tendência no XP é a automação de testes. Essa automação provocou uma série de inovações tecnológicas, para que o tempo de teste fosse suficiente para que o tempo do projeto não fosse quebrado, apoiando o ritmo do desenvolvedor.

Na cultura do XP, inicialmente não era dada importância aos testes manuais. Atualmente, essa visão mudou devido as contribuições da escola "context-driven testing" para testes exploratórios gerenciados.

Vale ressaltar que TDD (Test Driven Development) não é considerada uma prática de teste, e sim uma prática de apoio ao desenvolvimento, uma vez que ela é uma junção de duas práticas: 'test-first' (escrever o teste automatizado, antes do código) e 'refactoring' (limpeza do código, sem alterar seu comportamento funcional que já fora validado pelos testes).

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

Essa é uma dúvida que pode surgir na cabeça dos responsáveis pelo desenvolvimento de um software. Surge um novo projeto e a oportunidade de colocar em prática os conhecimentos sobre os processos ágeis. De que forma utilizar a metodologia ágil em seu projeto? Vejamos as ideias dos participantes da mesa para sanar essa dúvida.

Como o próprio nome diz, é um modelo, uma forma estruturada de executar o trabalho. Cada empresa tem sua particularidade, seja do projeto, dos funcionários, do cliente, em fim, da cultura. O que o Ronaldo Cruz nos recomenda é "você pega as práticas do modelo e as adapta ao seu ambiente."

Outro cuidado com "seguir a risca" é a forma como a metodologia é ensinada,

O Vitor Maciel aponta: "...ninguém ensina a risca metodologia ágil, é incrível o que eu leio por aí." E prossegui alertando sobre cargos: "Imagina criar empregos específicos de Scrum como um cara especifico para ser Scrum Master".

Já alguns (o Kent Beck do XP, por exemplo), dizem que sim, que é necessário seguir a risca a metodologia, por causa da sinergia entre as práticas. Como citou o Jorge Diz. Mas, o próprio Jorge, acredita que é necessário manter um jogo de cintura, sem descaracterizar as práticas que fazem a dinâmica funcionar. Sempre irão existir limitações e será preciso contorná-las.

No início do processo de implantação de uma metodologia ágil, o problema é a que os conceitos da metodologia ainda não foram totalmente incorporados. Só se aprende realmente fazendo, descobrindo, que é importante e o que não é; onde será preciso bater o pé e onde será possível ceder; o que funcionará bem num certo contexto e o que será preciso evitar. Por isso, uma das soluções para esse problema, é ter o acompanhamento de profissionais mais experientes durante o início de uma transição para a agilidade.

Outra prática comum, adotada pelas organizações que adotam uma nova metodologia, são as adaptações 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. O tal "Scrum, but ...", como disse o Jorge Diz.

Muitas organizações saem com as máximas: "Estamos fazendo Scrum, mas dispensamos as reuniões diárias". "Estamos usando XP, mas não temos testes unitários". Em casos como esses, a chance de sucesso diminui drasticamente, e a metodologia em questão paga o pato e ainda aparece mal na foto.

Para concluir, O by the book está longe de ser a melhor maneira de implantar algo, principalmente na nossa área, como nos contou o Fabrício, e continuou dizendo: "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 Testador no Processo Ágil

"O testador é “o cara que aprova”.
Nada é considerado “pronto” em um sprint, até que ele diga que está." - Gustavo Quezada


Durante a Mesa Redonda surgiu um novo questionamento. A Juliana Kryszczun levantou a seguinte dúvida:

“Qual é a maior diferença para o analista de teste entre processos ágeis e processos tradicionais de teste?”

Para ajudar a sanar essa questão, o Marcelo Andrade citou o artigo do Professor José Papo, "O papel do analista de Testes dentro dos processos ágeis - Uma Introdução". Abaixo está uma compilação das principais colocações do artigo.

O professor inicia apresentando a ideia de que ainda existem muitas dúvidas no mercado, sobre qual é o papel do analista de teste dentro de uma equipe ágil. Pois a definição dos papeis pode levar a confusões e a crença, de que não existe lugar para o analista de teste em um time ágil.

Outro levantamento do professor é a diferença entre o processo tradicional e o processo ágil. Enquanto no processo tradicional, testes aparecem no fim do ciclo de desenvolvimento o analista de teste é mais reativo. Na prática a equipe de vive separada da equipe de desenvolvimento, e só se cruzam no momento da verdade da fase de teste do modelo cascata. Já nos processos ágeis, o analista de teste deixa de ser reativo para se tornar um papel fundamental na interação com os desenvolvedores, analistas de negócios e clientes.

Para fundamentar essa mudança, o professor apoiou-se no quadrante de testes ágil, do livro de Lisa Crispin e Janet Gregory, Agile Testing.

Figura 6.01 - Quadrante do Teste Ágil (Agile Vancouver, 7 de mar. 2010)

Em seguida, citou os grandes Grupos de Teste:

Q1 - Testes que focam na arquitetura e suportam o time: São os testes unitários e de componentes. Estes são realizados e são de responsabilidade dos próprios desenvolvedores. O papel do analista de testes nesse quadrante é o de apoiar, suportar e expandir conhecimentos entre os desenvolvedores sempre que necessário. De preferência isso é feito fazendo "pairing" com o desenvolvedor no momento de elaborar os testes unitários automatizados.

Q2 - Testes que focam no negócio e suportam o time: São testes funcionais diferenciados, que idealmente utilizam a técnica de Behaviour-Driven Development e Acceptance Test-Driven Development. Isto é, são testes e cenários de exemplo realizados pelos testadores em conjunto com os clientes, usuários e analistas de negócio. Com base nesses exemplos e cenários os desenvolvedores terão melhores condições de desenvolver e entender os requisitos. Além disso, utilizando-se ferramentas adequadas (como o Fitnesse ou o Concordion, por exemplo), uma parte desses testes será automatizada antes ou em paralelo com o desenvolvimento do cenário. Portanto, o foco desses testes não é encontrar o maior número de defeitos e sim ajudar clientes e desenvolvedores a se entender melhor.

Q3 - Testes que focam no negócio e criticam o produto: esses são o que chamo de testes "clássicos". Os testes de aceitação feitos na homologação do produto ou de suas partes, testes betas e testes exploratórios. São os testes feitos não com o objetivo de dizer que o software funciona, mas, pelo contrário, de encontrar defeitos. Essa categoria às vezes é negligenciada por alguns agilistas mais radicais. Mas a verdade é que bons analistas de testes possuem técnicas para encontrar defeitos que poucos desenvolvedores conhecem (até porque o papel do desenvolvedor é construir e o do testador, neste quadrante, é o de destruir!).

Q4 - Testes que focam na arquitetura e criticam o produto: São os testes de performance, de carga e de segurança. Esses são de responsabilidade dos analistas de testes e costumam ser feitos quando pedaços da aplicação já estão prontas e, especialmente, antes da entrada de um release em produção.

E concluiu com a seguinte recomendação: "Recomendo então a todos os analistas de testes: estudem bastante o processo ágil de testes, as novas técnicas de Behaviour Driven Development e as ferramentas automatizadas que as auxiliam. Assim você se tornará um recurso muito mais valioso para sua equipe e para o resultado final dos projetos."

Principais Benefícios dos Métodos Ágeis.

Existem várias razões pelas quais as empresas adotam os Métodos Ágeis irá agregar valor a seus negócios. Dentre as principais podemos citar:

Experiências dos participantes ao utilizarem processos ágeis

Nessa parte, serão expostas as experiências compartilhadas pelos participantes da mesa, sobre a utilização de processos ágeis. Aproveitem as visões e absorvam o que julgarem necessário, nunca se sabe quando será a hora de colocar a leitura em prática, e ideias são sempre bem-vindas. Como disse o Felipe da Silva: "Gosto sempre de utilizar exemplos que sendo analisados possa-se tirar uma lição extra".

Para o Ronaldo Cruz:

"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 dúvidas 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, negocio e dou suporte ao pessoal do desenvolvimento."

O Vitor compartilhou também a sua experiência dizendo:

"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."

O Fabrício Ferrari apresentou também suas conclusões retiradas de suas experiências:

O Jorge Diz a partir de suas experiências identificou os problemas enfrentados pela disciplina de Teste de software no contexto dos processos ágeis.

É 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:

Conclusão

Voltando ao tema processos ágeis, nesse momento de fechar as ideias, vale relembrar da colocação do Marcelo Andrade, que alertou para o enfoque meramente mercadológico para a palavra ágil. De nada adianta uma empresa dizer que usa metodologia ágil se ela não possuir disciplina e seguir apenas o modismo que a palavra ágil nos traz: "Ontem usávamos metodologia própria, hoje usamos ágil e continuamos seguindo o testa aí". O indicado, seria que empresas que querem entrar na moda, usassem um tempo para estudar e um modelo como mesclas de metodologias ágeis adaptadas para seu cotidiano. Nesse caso, essas empresas poderiam ser o destaque de um evento 'da moda' e ainda ganhar fãs e seguidores, como a globo.com que implantou um misto de metodologias ágeis para desenvolvimento de seus projetos.

E seguindo a ideia de adaptar e implantar, o principal objetivo ao se implantar uma nova metodologia, é sempre melhorar e melhorar, como lembrou o Felipe Silva e que ainda completou dizendo que pela melhoria vale a pena ir à guerra, tomando o cuidado de sempre lutar como um exército unido e não um contra o outro. Lembrando que será necessário mudar a cultura dos soldados, pois de nada adiantará usar, ágil, abobrinha, ou chuchu, se as pessoas da empresa, ou os nossos bravos soldados, não estiverem comprometidas e engajadas em implementar o modelo e fazê-lo acontecer. Não existe a bala de prata!

Inicie com o primeiro passo e siga passo a passo. Não de uma vez, como tentam fazer alguns, que pensam que um processo novo que cai de sem pára-quedas e irá funcionar. Traga o cliente para perto do time, busque ter uma pessoa da área de Teste de Software, no seu time. Já vimos que o teste tem muito, se não tudo a ver com essa guerra. Ele é a arma secreta para deixar seu cliente satisfeito. E principalmente, ao iniciar um novo processo ágil, lembre-se da máxima do Marcelo Andrade:

SE VOCÊ NÃO TESTA, VOCÊ NÃO É ÁGIL!

<- Voltar para o capítulo anterior | Ir para o próximo capítulo ->

Referências Bibliográficas

[1] CRISPIN, Lisa et al. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley Professional. 2009. 576P.

[2] KOSCIANSKI, André. Qualidade de Software. São Paulo. Novatec. 2007 400p.

[3] PAPO, José. O papel do analista de Testes dentro dos processos ágeis - Uma Introdução. Disponível em < http://josepaulopapo.blogspot.com/2009/09/testes-agil-papel-analista.html> Acesso em 09/11/2010.

[4] SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para o Desenvolvimento de Software. Disponível em <http://www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf > Acesso em 01/11/2010