Metodologia de testes ágil

São múltiplas as organizações que têm encetado processos de transformação com vista a transitarem do tradicional processo de desenvolvimento em cascata para processos ágeis.
No sentido de acompanhar esta tendência e de proporcionar sempre aos seus cliente serviços alinhados com as sua necessidade a Link desenvolveu a sua própria metodologia de testes funcionais para processos de desenvolvimento ágeis.

A execução de testes em processos de desenvolvimento ágeis trás alguns desafios em relação ao processo tradicional.

O primeiro destes desafios prende-se com a forma como os requisitos são especificados. Ao contrário dos processos tradicionais de desenvolvimento, em que existe uma longa fase preliminar de análise e de especificação de requisitos que termina tipicamente com a produção de especificações funcionais detalhadas, nos processos de desenvolvimentos ágeis esta fase preliminar não atinge a mesma profundidade nem detalhe (baseando-se na produção de user stories), o que dificulta a especificação de casos de testes detalhados por uma equipa de testes autónoma à equipa de desenvolvimento.

Outro desafio prende-se com o facto de os teste terem de ser especificados e executados no final de cada iteração ou sprint, o que exige uma dinâmica diferente por parte das equipas de testes, que nos modelos tradicionais só entreveem após a conclusão de todos os desenvolvimentos. Esta característica, inerente ao desenvolvimento ágil, aumenta também a necessidade de se executarem testes de regressão (ao que foi dado como concluído em iterações anteriores), e consequentemente a necessidade de investir na automação de testes.

De forma a corresponder a estes desafios a Link tem adotado uma abordagem para endereçar a execução de testes em modelos de desenvolvimento ágeis, que assenta nos seguinte princípios base:

• Alocar às equipes de desenvolvimento Agile especialistas em processos de testes por forma a capturarem todas as informações pertinentes para a execução dos testes, durante as iterações ágeis.
• Execução de testes no final de cada iteração de desenvolvimento (sprints) para homologação das user stories (ou funcionalidades) consideradas prontas (definition of done).
• Planeamento e realização de sprints específicos dedicados exclusivamente a testes em que são realizadas baterias de testes que testam o software numa visão integrada (BSIM- Business Simulation).

A figura abaixo ilustra a metodologia de testes da Link ajustada aos desenvolvimentos ágeis.

No ciclo de desenvolvimento ágil, antes do início dos ciclos de construção é realizado o planeamento da release, ou Iteração 0. Nesta fase é feito o dimensionamento e a priorização das histórias que integrarão a release da aplicação/sistema a desenvolver, formando o backlog de trabalho. É também feita a previsão inicial de requisitos e arquitetura, a identificação e organização da equipe de desenvolvimento e o entendimento do(s) objetivo(s) do projeto.

A equipa de testes participa nas reuniões de preparação da Iteração 0, com o intuito de entender os riscos, o impacto dos testes na duração dos sprints, os dados de teste, as dependências, etc… 

Nesta fase os testes são planeados a alto nível, e antecipa-se a necessidade de recursos para a sua execução (por ex. ambientes, ferramentas, dados de testes, etc..).

No início de cada iteração, é realizada a sessão de planeamento (ou Sprint Planning). Nesta sessão é analisado o backlog, e são identificadas as histórias que serão desenvolvidas no decorrer desta iteração, bem como com as estimativas de todas as tarefa que são necessárias para implementar a(s) história(s).

A equipa de testes participa no Sprint plannig para se inteirar dos requisitos/funcionalidades que irão ser desenvolvidos nesse sprint. Com base nessas informações inicia a especificação de casos de teste os quais serão detalhados durante a iteração

A equipa de testes sistematiza também nesta fase quais os testes de aceitação que, quando passados, determinam que uma história (ou funcionalidade) está terminada (definition of done).

Durante a fase de construção as histórias selecionadas no Spint planning são desenvolvidas, e os respetivos testes preparados.
Os casos de testes de alto nível descritos durante o planeamento da iteração são utilizados pela equipa de desenvolvimento como guia/apoio na implementação das histórias.Em paralelo com o desenvolvimento, a equipa de testes inicia a especificação detalhada de casos de teste. Através da participação colaborativa entre a equipa de testes e de desenvolvimento são especificados testes que refletem detalhes da(s) história(s) que auxiliam o desenvolvimento. No final da Iteração, a equipe de desenvolvimento realiza as sessões de review e retrospetiva nas quais a equipa de testes é envolvida com vista a melhorar o seu processo de testes. 

Tipicamente nessas sessões, ocorre a uma demonstração do que ficou concluído no decorrer da iteração, para obter feedback e inputs da equipe cliente.

Nesta fase são disponibilizadas à equipa de testes as histórias/funcionalidades que foram desenvolvidas.

Os testes são executados tipicamente no final da iteração, mas poderá eventualmente ocorrer algum paralelismo com o início da próxima iteração. Os testes de maior duração podem portanto ser realizados no decorrer do sprint N+2.

Todos os defeitos detetados são reportados à equipa de desenvolvimento. As correções dos defeitos detetados é considerada no planeamento dos próximos sprints pela equipa de desenvolvimento, que as deverá estimar, priorizar e inserir no backlog.

Além dos testes manuais executados em cada iteração, a equipa de testes executa também testes de regressão. O objetivo destes testes é assegurar que os desenvolvimentos de novos sprints não provocam regressões sobre histórias ou funcionalidades dadas como concluídas e aceites pelo cliente em sprints anteriores.

Ao longo de um projeto os testes de regressão são gradualmente automatizados pela equipa de testes. À medida que novos testes são automatizados, são também adicionados à suíte de regressão e serão executados periodicamente (ex: todos os dias ao final do dia) ou sempre que ocorrer um novo build, de acordo com as políticas do processo de integração continua definidas.

No final dos ciclos de construção, antes de colocar o produto em produção, realizam-se os testes do fim do ciclo de vida, o jogo final.

Essa iteração serve para adicionar testes mais sofisticados, nomeadamente testes de ponta-a-ponta que cruzem funcionalidades desenvolvidas ao longo de vários sprints, simulando situações reais de negócio (BSIM- Business Simulation).

No decorrer deste Sprint caso seja possível, podem ainda ser realizados TESTES EXPLORATÓRIOS – para perceber o comportamento da aplicação em casos totalmente fora do padrão.