VV&T no contexto ágil 67

Uma das principais características das metodologias ágeis é o contato direto e constante entre os membros da equipe de desenvolvimento e destes com o cliente. Dessa forma, o risco de construir um produto que não corresponda às necessidades do cliente é reduzido e os defeitos são detectados mais facilmente.

Ambler (2010a) ressalta duas práticas importantes para obter sucesso com a atividade de testes: considerar a testabilidade do software, ou seja, prever como o software deverá ser testado e comprovar o software desenvolvido constantemente de forma a obter a opinião do cliente, ou de seu representante, verificando se as funcionalidades entregues fazem o que deveriam fazer.

Segundo Opelt e Beeson (2008), um importante passo para conseguir aplicar as atividades de garantia da qualidade é conseguir que tanto os integrantes da equipe de desenvolvimento como os responsáveis pelo negócio reconheçam que existirão benefícios para o projeto. Dentre os benefícios estão: a identificação de defeitos antes que o sistema entre em produção, a adição de uma perspectiva diferente durante o desenvolvimento mais focada na qualidade do produto; e a percepção de quais são os defeitos mais críticos e que devem ser corrigidos.

Nos métodos tradicionais de desenvolvimento, como discutido no capítulo 3, a qualidade tem sido conseguida pelo uso de vários métodos de verificação e validação de software. Na prática, o ciclo de desenvolvimento dos métodos tradicionais prevê a realização de testes, entretanto, mesmo que especificados juntamente com os requisitos, geralmente são executados nas fases finais do ciclo de desenvolvimento. Nos métodos ágeis, de maneira geral, a garantia da qualidade do software recai no teste do código construído e na interação freqüente entre cliente e equipe de desenvolvimento. O desenvolvimento é realizado e versões são liberadas para serem validadas pelo cliente (HEDBERG; IISAKKA, 2006).

Os responsáveis pela realização dos testes nos métodos ágeis geralmente fazem parte da equipe de desenvolvimento e, dessa forma, o time como um todo é responsável pela qualidade do produto desenvolvido. Esta situação pode não se aplicar em ocasiões onde o ambiente de desenvolvimento seja mais complexo e surja a necessidade de existir uma equipe independente de testes que irá trabalhar em paralelo à equipe de desenvolvimento (AMBLER, 2010a).

As principais atividades de teste no contexto ágil estão relacionadas ao teste de unidade, difundidos pela utilização do TDD (Test-driven development ou Test-

driven design). O TDD é uma prática adotada no desenvolvimento ágil que combina

refatoração e o TFD (Test-first development). A refatoração implica em fazer pequenas modificações no código fonte existente de forma a melhorar o código sem necessariamente modificar a sua semântica. O TFD consiste em escrever um teste que determine o resultado de uma determinada funcionalidade e escrever código suficiente para este teste passar (BECK, 2004).

Podem existir dois níveis do TDD, o Acceptance TDD, onde os princípios do TDD são aplicados tendo como entrada os requisitos do sistema, e o Developer TDD, onde os testes são criados baseados na implementação que deverá ser realizada.

O Acceptance TDD é equivalente ao teste funcional e de aceitação realizado nos métodos tradicionais. Os testes de aceitação são realizados com base nas regras de negócio do sistema, ou seja, nos requisitos funcionais. Eles procuram verificar se o software está funcionando corretamente, se seu comportamento está conforme foi definido nas histórias do usuário ou requisitos. Estes testes devem ser realizados a cada entrega de um incremento de software, ou mesmo durante a iteração caso haja alguma incremente de software funcionando.

Segundo Ambler (2010a), a maior quantidade de testes deve ocorrer durante as iterações de desenvolvimento ou construção do software. Testes confirmatórios devem ser realizados pelo time de desenvolvimento e testes investigativos devem ser realizados de preferência, de forma paralela, por um time independente de testes. Os testes confirmatórios possuem o objetivo de verificar se o sistema cumpre o que os stakeholders definiram e o teste investigativo procura encontrar defeitos e problemas que o time de desenvolvimento pode não ter considerado.

O teste confirmatório é composto pelos testes de aceitação e pelos testes do “desenvolvedor”, que representam o teste efetuado sobre o código desenvolvido. Os testes de aceitação combinam os testes funcionais e de aceitação tradicionais. O teste de desenvolvedor une os testes unitários e de integração tradicionais. Unindo essas abordagens, o objetivo dos testes confirmatórios é de procurar defeitos no sistema, alcançando uma cobertura de código satisfatória e garantindo que o sistema está de acordo com os interesses dos stakeholders.

O teste investigativo procura explorar o que pode dar errado no sistema explorando cenários de teste que podem não ter sido explorados pela equipe de desenvolvimento. Os membros da equipe individual de testes, denominados testadores, descrevem os problemas encontrados sob a forma de defeitos, denominados “histórias defeito”. Para corrigir um defeito a equipe de desenvolvimento deve tratá-lo como um requisito do sistema que será inserido no ciclo de desenvolvimento para correção. Os testes investigativos verificarão problemas de performance, integração, segurança, usabilidade, etc.

Uma pesquisa realizada pela empresa Ambysoft no ano de 2008 (AMBYSOFT, 2010) procurou sumarizar entre a comunidade que utiliza TDD quais são as técnicas de teste que eles utilizam na prática. Os resultados podem ser visualizados na Figura 4.4, onde pode-se notar que além de aplicar o TDD existe também a aplicação de atividades de revisão e inspeção, testes realizados no fim do ciclo de desenvolvimento e atividades paralelas de testes.

Figura 4.4 – Práticas de testes e validação de software executadas por desenvolvedores ágeis (adaptado de (AMBYSOFT, 2010))