Frente à constante evolução do
software, enquanto propriedade intelectual e produto de mercado, estabeleceu-se
como prática indispensável a constante inovação em seu processo de
desenvolvimento tendo em vista a redução de custos e a melhoria do produto
final para um aumento de competitividade no mercado.
O software está cada vez mais
complexo e sua concepção continua a exigir mais dos seus desenvolvedores.
Segundo o relatório “CHAOS” (Standish Group, 2009), 32% dos projetos obtiveram
sucesso (isto é, foram entregues dentro do prazo estipulado, do orçamento e
finalizados), 44% tiveram problemas de atrasos, redução do escopo do software
e/ou rombo no orçamento e 24% falharam, foram cancelados ou não foram usados;
estes fatos provam a dificuldade que existe em se compreender os fatores, as
causas relevantes para as mudanças no curso do processo de desenvolvimento de
um software.
[COSTA, 2011] expõe que as
metodologias tradicionais têm como principal característica serem divididas por
etapas definidas, como “Análise, Modelagem, Desenvolvimento e Testes”, sendo
que cada etapa só é iniciada após o termino da etapa anterior, sendo elas
interdependentes e cada uma acaba por gerar documentos, diagramas UML e/ou um
protótipo de software. E, muitas destas metodologias fazem uso, por exemplo, do
modelo Cascata, que utiliza uma abordagem sequencial tendo início pela coleta
dos requisitos e, após, passando por planejamento, modelagem, construção e
implantação. Embora o modelo seja preciso e organizado, cada etapa seja
documentada e o modelo prevê que o processo seja seguido às riscas, o que é
deveras interessante, de acordo com [PRESSMAN,2006] projetos reais raramente seguem o fluxo sequencial que esse modelo propõe; não obstante, por se tratar de um modelo
linear, uma modificação no decorrer do processo pode causar confusão e, como
sabe-se que para o cliente é difícil estabelecer todos os requisitos
explicitamente no início do projeto, isto torna muito difícil demorado e
burocrático o desenvolvimento de software em empresas de menor porte e
processos menos definidos através do uso de metodologias tradicionais.
Com a intenção de superar este e
outros obstáculos que no ano de 2001, foi assinado o famoso “Manifesto para
Desenvolvimento Ágil de Software”, por dezessete especialistas em processos de
desenvolvimento de software representando os métodos Scrum [Schwaber e Beedle,
2002)], Extreme Programming (XP) [Beck (1999)] e outros. Estes estabeleceram
princípios comuns compartilhados por todos esses métodos, criando então a Aliança Ágil e o estabelecimento do
“Manifesto Ágil” [Agile Manifesto (2012)]. Neste documento, importantes
desenvolvedores declararam terem descoberto formas melhores de desenvolvimento de
software e que, a partir daquele momento, valorizavam mais indivíduos e
interações em vez de processos e ferramentas; software funcional no lugar de
documentação completa; colaboração com o cliente substituindo a negociação de
contrato e resposta à mudanças ao invés de seguir um plano determinado.
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. 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 seguinta 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”.(2006)
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. É
recomendada apenas a produção de documentação que realmente será útil.
Segundo [SCOTT, 2008] os processos
ágeis mais populares e suas principais características são :
• SCRUM: Forte presença de liderança
no projeto e gerenciamento dos requisitos.
• Crystal Clear: Foco na eficiência
e habilidade, gestão de configuração, integração freqüente.
• Adaptive Software Development: Adaptação
continua do processo, iterativo, tolerante a mudanças.
• Feature Driven Development (FDD):
Desenvolvimento dirigido por atributos, com pequenas iterações, posse
individual das classes, desenvolvimento dirigido por atributos ou grupo de atributos,
construções regulares.
• Dynamic Systems Development Method
(DSDM): Baseado no modelo RAD (Rapid Application Development), muito utilizado
no desenvolvimento de aplicações focadas em interface com o usuário. Suas
principais características são a prototipagem, testes por todo o ciclo da
iteração, alterações reversíveis e aplicação de estudos de viabilidade.
• Extreme Programming (XP): Possuiu
um conjunto de práticas para desenvolvimento de software, cujas mais
diferenciadas são refatoramento, programação em pares, propriedade coletiva,
ambiente único com desenvolvedores e clientes, elaboração de histórias (user
stories) e ainda desenvolvimento dirigido por testes (Test Driven Development -
TDD).
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.
Apesar de se valorizar muito mais os itens da
esquerda, os itens da direita não são desconsiderados, ao invés disso, os mesmos
são aplicados de forma ponderada e conforme a necessidade do processo, sem que
haja impacto nas entregas a serem realizadas, prazos estabelecidos e qualidade
do produto final gerado. 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
[LEAL,2009] afirma 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 4 (quatro), que são os Testes de
Aceitação, Testes de Dados, Testes de Resultados e Unidades de Testes [BECK,
99]. Esses 4 (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,00].
[TOMÁS,2009] reitera 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 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 tendem a ser estabelecidos em conjunto com uma sistemática de
trabalho que possibilite à área de teste de software ser mais pró-ativa
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 deve-se considerar os prazos e as
atividades de teste do começo ao fim da iteração. 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.
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, observa-se
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 pró-ativos (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.
Nenhum comentário:
Postar um comentário