A
maioria dos métodos ágeis tenta delimitar e reduzir o risco pelo
desenvolvimento do software em curtos períodos, denominados iterações, os quais
despendem menos de uma semana de tempo a um máximo de quatro semanas, sendo que
cada iteração é como um projeto de software em pequena escala do projeto
principal, e inclui em si todas as tarefas necessárias para implantar um mini-incremento
de uma nova funcionalidade: planejamento, análise de requisitos, projeto,
codificação, teste e documentação (Desenvolvimento ágil de software, 2005). Enquanto em um
processo convencional cada iteração não está necessariamente focando em
adicionar um conjunto de funcionalidades, um projeto de software com
metodologia ágil busca a capacidade de implantar uma versão nova do software ao
fim de cada iteração, etapa a qual a equipe responsável reavalia as prioridades
do projeto.
Pressman denota a filosofia do método ágil
para desenvolvimento de software da seguinte forma:
“A engenharia de
software ágil combina uma filosofia e um conjunto de diretrizes de
desenvolvimento. A filosofia encoraja a satisfação do cliente e a entrega
incremental do software logo de início; equipes de projeto pequenas, altamente
motivadas, métodos informais, produtos de trabalho de engenharia de software
mínimos e simplicidade global de desenvolvimento. As diretrizes de
desenvolvimento enfatizam a entrega em contraposição à análise e ao projeto
(apesar dessas atividades não serem desencorajadas) e a comunicação ativa entre
desenvolvedores e clientes” (PRESSMAN, 2002)
Métodos
ágeis enfatizam comunicações em tempo real, preferencialmente in loco, em vez de documentação escrita.
A maioria dos stakeholders de
um grupo ágil deve estar agrupada em uma sala. Isso inclui todos aqueles
necessários para terminar o software: no mínimo, os programadores, gerentes
e/ou analistas de negócio e seus clientes. Nesta sala devem também se encontrar
os testadores e projetistas. Métodos ágeis também enfatizam trabalho no
software como uma medida primária de progresso. Combinado com a comunicação
face-a-face, métodos ágeis produzem pouca documentação em relação a outros
métodos, sendo este um dos pontos que podem ser considerados negativos (Desenvolvimento ágil de software, 2005). É recomendada
apenas a produção de documentação que realmente será útil.
Segundo
(NADALETE, 2010) em se tratando de desenvolvimento ágil,
alguns princípios definidos por meio do Manifesto Ágil são utilizados com o
objetivo de nortear a linha de produção, como:
●
Indivíduos
e interações 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;
●
Capacidade
de responder a mudanças mais que seguir um plano.
Os
mesmos princípios usados para direcionar o desenvolvimento ágil, devem ser
considerados quando for aplicado teste ágil, ou seja, testar de forma ágil
exige uma forte adaptação na rotina e dinâmica da equipe de teste, em relação
ao processo de desenvolvimento adotado, com o objetivo de propiciar um processo
relativamente simples e que possa ser executado com grande facilidade e
agilidade, cobrindo o maior número de riscos, com um nível de qualidade que
seja apreciada e valorizada pelo cliente ou usuário final
(NADALETE, 2010).
Afirma (LEAL, 2009)
que os requisitos para metodologias de teste para processos ágeis não possuem
grande diferenciação em relação processos guiados por planos. O que é diferente
é o grau de importância atribuído aos testes em cada um dos processos. Nos
processos guiados por planos, existe uma extensa série de artefatos documentais
resultantes de uma análise profunda sobre o sistema a ser desenvolvido. Sendo
assim testes são utilizados nesse caso apenas como mais um artefato produzido
pelo processo visando garantir a detecção de erros antes da liberação da versão
final
Segundo análise comparativa realizada por (NETO, 2004) tomando como base os
documentos gerados na etapa de testes o RUP orientado para pequenos projetos gera apenas um único documento que é o Modelo
de Testes, já a XP gera quatro, que são os Testes de Aceitação, Testes de
Dados, Testes de Resultados e Unidades de Testes (KENT, 1999). Esses quatro documentos gerados na
programação extrema são englobados num único documento no Processo Unificado da
Rational, fazendo com que este artefato se torne extenso e abrangente, porém
sendo tratado como único (KRUCHTEN, 2000)
Reitera (MÁRIO, 2009)
que no processo XP antes do desenvolvimento do código, recomenda o processo,
que se crie uma bateria de testes unitários para que a história fique
satisfeita. Então o foco dos programadores é a satisfação destes testes
unitários. Para a codificação o XP, recomenda que esta seja feita em pares,
isto garante outros aspectos como qualidade, e rapidez. Os testes unitários são
mantidos ao longo das várias iterações e passam a fazer parte de uma bateria de
testes de regressão, que não é mais do que todos os testes unitários agrupados
para serem testados periodicamente de uma vez em períodos curtos. A ideia é
confirmar que nada deixou de funcionar. Os clientes são considerados parte da
equipe de desenvolvimento, uma vez que a todo o momento são questionados sobre
prioridades e testes de versões.
Ressalta-se que muitos métodos ágeis, como
Lean, Scrum e
XP recomendam que todas as pessoas de um projeto (programadores, gerentes,
equipes de homologação e até mesmo os clientes) trabalhem controlando a
qualidade do produto todos os dias e a todo o momento, pois acreditam que
prevenir defeitos é mais fácil e barato que identificá-los e corrigi-los. A
Programação eXtrema, em particular, recomenda explicitamente testes automatizados
para ajudar a garantir a qualidade dos sistemas de software (BERNARDO, 2008). Através da definição do processo ideal e simplificado,
onde o teste ágil é suportado, um conjunto de práticas que proporcionem a
diminuição do tempo entre o erro e a sua descoberta tende a ser estabelecidos
em conjunto com uma sistemática de trabalho que possibilite à área de teste de
software ser mais proativa do que reativa.
Analisemos
algumas das práticas do processo de teste tradicional aplicados na tentativa de
gerenciar o "chaos", ou ao
menos evitar culpados (HENDRICKSON, 2006).
●
A área
de teste de software assumindo a postura de "Último Defensor da
Qualidade";
●
Restrições
no gerenciamento de mudanças;
●
Preparação
detalhada e planejamento acima de tudo;
●
Conjunto
de documentação pesado para a terceirização dos esforços de teste;
●
Critérios
de entrada e saída rigorosos e com aprovações;
●
Automatização
de testes pesada e com foco nas regressões;
●
Tentativas
de execução do processo.
Ao se
tratar de teste ágil, essas mesmas práticas não se adaptam à dinâmica almejada.
Em um ambiente ágil de controle de qualidade devem-se considerar os prazos e as
atividades de teste do começo ao fim da iteração (NADALETE, 2010). Ao contrário do teste tradicional, não
se espera que uma única equipe se responsabilize pela qualidade final das
entregas, mas sim que todas as equipes tenham sua colaboração no controle dessa
qualidade, desde o levantamento das necessidades do cliente, até a implantação
do produto final gerado.
Ainda afirma que no teste tradicional,
espera-se que os defeitos sejam identificados no último nível, pela equipe de
QA,
enquanto que ao se aplicar teste ágil, isso é antecipado pela própria equipe de
desenvolvimento por meio de práticas como desenvolvimento em pares, integração
contínua, pequenas entregas, refatoração constante e padrões de codificação, de
técnicas como TDD (Test Driven Development) e ATDD (Acceptance Test Driven
Development), e através da automatização dos testes gerados. Ao se trabalhar
com testes ágeis, (NADALETE, 2010) observa algumas mudanças de conceito em
relação ao modelo tradicional, tais como:
- Mudanças
são inevitáveis, e com base nisso toda equipe, incluindo os programadores,
testadores e clientes, são responsáveis pelo resultado final;
- Todos
da equipe devem estar acessíveis e se comunicando ativamente através do
projeto;
- O
teste de software se torna mais preventivo, ou seja, programadores testam mais
cedo, com mais frequência e agressivamente. Neste ponto a prática de TDD pode e
deve ser aplicada;
- Toda
equipe solicita ativamente feedback das
demais;
- Testadores
e programadores tendem a ser mais proativos (participação direta com o cliente)
e técnicos (aplicação de práticas XP e técnicas como TDD e ATDD);
- Testadores
precisam saber automatizar, com o intuito de manter o ciclo de entregas dos
testes sempre no prazo estabelecido e com teste de regressão atualizado. Só não
se automatiza o que realmente não pode ser automatizado ou não vale a pena ser
automatizado (e.g. Teste de
Usabilidade);
- Os
testes tonam-se uma rotina que nasce e morre junto à iteração planejada.
