Do Teste Tradicional ao Ágil? Como chegamos lá?

Atuar em um time ágil vem se tornando o desejo de muitos profissionais da área de teste. Ter a oportunidade de trabalhar com boas práticas, como a automação de testes, faz com que o analista de teste busque novos conhecimentos e desafios. Entretanto, nem sempre é uma tarefa fácil. Mudar a cultura de profissionais que estão no mercado há mais de 3 anos pode ser um tanto quanto complicado, pois muitos não conseguem se adaptar a essa nova realidade.

A ideia deste trabalho é compartilhar a experiência que a NeoGrid adquiriu no processo de mudança, que passou de um contexto mais tradicional para uma realidade mais ágil e vem se desenvolvendo sob esse ponto de vista.

INTRODUÇÃO

Atualmente as equipes de desenvolvimento vêm se preocupando cada vez mais em criar produtos que satisfaçam as necessidades de seus clientes e que agreguem valor ao negócio. Isso acontece porque, através de boas práticas ágeis, as demandas são fracionadas de maneira que possam acompanhar as constantes mudanças feitas pelo cliente.

A partir deste contexto, as atividades de teste de software também tiveram que se adaptar. Trabalhar de uma forma mais dinâmica e realizando as mesmas atividades em metodologias mais tradicionais com um ciclo de desenvolvimento menor. Entretanto, não é uma tarefa simples de fazer, pois esbarra na mudança da cultura dos profissionais da área. Iremos expor como a NeoGrid vem trabalhando de forma mais ágil de forma que não impactasse a entrega de seus produtos.

TESTE DE SOFTWARE TRADICIONAL

Nas abordagens tradicionais a atividade de teste é realizada ao fim da versão, onde o analista de teste estuda os requisitos a partir das especificações. Os artefatos gerados orientam o profissional de teste durante a execução de tais testes. Ao identificar um problema na fase de teste, a demanda retorna para todo o fluxo e impacta no cumprimento do prazo de entrega. O custo do projeto torna-se alto, pois os ciclos de desenvolvimento normalmente são longos e o risco de se desenvolver um produto que o cliente não está esperando também é alto.

TESTES DE SOFTWARE NA METODOLOGIA ÁGIL

A atividade de teste no contexto ágil está focada no teste do negócio. Um de seus objetivos é realizar uma análise crítica do produto para tentar descobrir pontos de melhoria para agregar ao produto final.

Podemos destacar que o analista de teste possui um papel mais dinâmico e crítico dentro do time de desenvolvimento, uma vez que ele tem a visão do todo e poderá contribuir ativamente na qualidade do produto a ser entregue. Através dos testes funcionais manuais validam os requisitos e a partir destes consegue criar testes automatizados para ser adicionados à suíte de testes de regressão. Nesta forma de trabalho, destaca-se o Quadrante do Teste Ágil (Brian Marick), onde os testes são subdivididos elevando a participação e posterior qualidade do profissional que os executa, conforme a figura abaixo.

ÉRAMOS SEIS

Até 2008 a metodologia utilizada no processo de desenvolvimento não estava totalmente formalizada e com isso não havia uma homogeneidade entre as unidades da empresa. Naquele momento chegou a ser analisada a possibilidade adotar o RUP como metodologia de desenvolvimento, porém o contexto de negócio exigia que tivéssemos um ritmo de entregas maior para atender às necessidades de nossos clientes. Entretanto, não tínhamos uma equipe de teste para garantir a qualidade dos produtos entregues, o que gerava muito retrabalho.

Para amenizar e minimizar o retrabalho, a empresa estruturou, em uma de suas unidades, uma equipe única de testes para atender todos os projetos desenvolvidos nesta unidade, que era composta por 6 analistas de teste. Com isso, as equipes de desenvolvimento tinham que planejar suas demandas, para que a equipe de teste pudesse conduzir o processo de desenvolvimento existente. A partir de um calendário de alocação, esta equipe de testes verificava se teria como atender as demandas ou não. Em caso positivo, os analistas de testes eram alocados para atender tais demandas dentro do prazo dos sprints. Nos casos em que não era possível alocar os profissionais nestas demandas, era preciso negociar os prazos entre os projetos, o que atrasava as entregas.

No quadro abaixo podemos visualizar uma coleta de métricas baseada no índice de erros/incidentes em produção em um dos produtos da empresa, quando os testes eram realizados de acordo com alocação da equipe a partir do calendário de alocações.

OBSERVAÇÃO: Consideradas apenas pendências dos tipos Não Conformidade e Incidente.

Os números demonstravam que, mesmo tendo uma equipe dedicada aos testes, os erros em produção ainda continuavam altos. Além disso, alguns pontos ficaram evidentes, tais como:

• não era possível focar no entendimento das regras de negócio, pois devido à alocação ser agendada era um tempo curto para compreender os fluxos das aplicações mais afundo;
• com o ritmo de trabalho acelerado, a análise de teste era impactada e com isso aumentava o nível de stress dos profissionais;
• baixa pró-atividade.

A empresa investiu em alguns treinamentos e, a partir disso, surgiu à necessidade de mudança deste contexto, pois as demandas dos projetos ficaram mais consistentes. Precisávamos acompanhar as mudanças e começamos a trabalhar diferente.

A MUDANÇA

Em meados de 2010 houve a necessidade de aumentarmos a equipe de teste para atender o surgimento de novas demandas. Ao mesmo tempo, os analistas de teste estavam engajados em mudar a forma de trabalho e tentar se adequar ao contexto ágil. As equipes de desenvolvimento dos projetos já trabalhavam com algumas boas práticas ágeis como daily meetings, workshops de requisitos, utilização de user story para especificar os requisitos funcionais e pair programming.

Iniciou-se pelo estudo do Quadrante Ágil para adaptarmos às nossas atividades com as boas práticas. Foi através de pequenas ações que fomos estruturando a nossa nova forma de trabalho e evoluindo como profissionais da área de teste. Foram adotadas atividades como:

• utilização da ferramenta 5W2H para entendimento dos requisitos permitindo o refinamento da análise de teste e assim tornarmos mais pró-ativos;
• realização de dojos internos para disseminar o conhecimento dentro da equipe;
• criar documentação de teste que agregasse valor.

Neste mesmo período, houve a dissolução da equipe, onde os analistas de teste passaram a fazer parte dos times de desenvolvimento. O objetivo dessa separação foi auxiliar na aderência das boas práticas que estavam sendo adotadas neste momento de transição, pois o processo de desenvolvimento também estava passando por mudanças. Isso tudo foi encarado como um grande desafio. Os analistas de teste começaram a participar de forma mais efetiva nas atividades do time, principalmente nas cerimônias iniciais dos sprints.

Na tabela abaixo temos um demonstrativo da mesma coleta realizada após as mudanças ocorridas e com os analistas de teste divididos nos times de desenvolvimento.

Foram consideradas apenas pendências dos tipos Não Conformidade e Incidente.

Aqui podemos constatar que houve uma redução de 48% do erros/incidentes em produção comparados ao ano anterior. Essa redução demonstra o resultado da atuação dos analistas de teste como integrante do time. Além disso, podemos destacar que um perfil mais analítico estava surgindo, pois atuando desde o início do Sprint, o analista de teste conseguia se antecipar às questões que anteriormente só eram identificadas na fase de teste. Também passamos a monitorar os incidentes/não conformidades registradas no ambiente de produção, para que pudéssemos auxiliar na identificação da causa raiz destes problemas.

A essa altura o processo de desenvolvimento já estava remodelado e institucionalizado nas unidades da empresa. Entretanto, neste novo processo as atividades de teste pertenciam a uma etapa do processo, mas não havia nada estruturado como um conjunto de boas práticas efetivas de teste. Sendo assim, os analistas de teste identificaram a necessidade de definir as atividades a serem realizadas dentro da etapa de verificação do processo de desenvolvimento. Em março 2012 foi institucionalizado um conjunto de boas práticas de teste, que é totalmente flexível, para poder se adaptar à realidade de cada unidade.

COMO FUNCIONA HOJE

O analista de teste atua como um facilitador dentro do time de desenvolvimento, pois atua em todo o fluxo do processo de desenvolvimento. Nas cerimônias iniciais do sprint o profissional de teste participa das discussões de requisitos e criação das user stories, onde auxilia no refinamento dos critérios de aceitação, o que o favorece no seu planejamento dos testes.

Além disso, é responsável por criar, executar e manter testes funcionais e não funcionais e elaborar artefatos de teste que se façam necessários, tais como: checklists, cenários de teste, scripts. Criar testes automatizados de funcionalidades que permitem fazer esse tipo de teste através de ferramentas open sourcing, como Selenium integrado com Java TestNG, JBehave, etc. As atividades de teste são realizadas visando a integração contínua.

Outra responsabilidade é monitorar se as atividades do time estão aderentes ao processo de desenvolvimento. Também faz a coleta de métricas de teste, que é repassado para o responsável do projeto informar nas métricas do sprint e ser apresentada nas cerimônias finais.

CONCLUSÃO

Mudar a cultura dos profissionais de teste foi o primeiro grande passo para trabalharmos de um jeito diferente hoje. Acreditar que de fato era possível fazer as mesmas atividades de antes, que levávamos muito mais tempo para fazê-las, e com a mesma destreza. Sim, ganhamos agilidade e melhoramos a nossa qualidade nas entregas.

Superamos obstáculos quando passamos a fazer parte do time, melhoramos a nossa comunicação e nos tornamos mais pró-ativos.

Foi criado um grupo para compartilhar experiências entre todos os analistas de teste da empresa, que tem por objetivo disseminar as boas práticas adquiridas e manter esse conhecimento. Estamos em constantes mudanças, pois durante este período muitos profissionais iniciaram na empresa e recomeçar sempre foi preciso. Certamente somos profissionais mais maduros dentro da área e podemos dividir nossos erros e acertos. Também somos cientes de que estamos em constante evolução.

Autoras:

Dieine da Silva

Pós-graduada em Melhoria do Processo de Software pela Universidade Federal de Lavras e bacharel em Ciência da Computação pela UEPG. Com 8 anos de experiência na área de Teste de Software e Qualidade de Software. Atualmente, é Analista de Testes, Qualidade e Processos da equipe de Arquitetura e Frameworks na NeoGrid.

Patrícia Araújo Gonçalves

Pós-graduada em Teste e Garantia da Qualidade de Software pela Universidade Feevale e bacharel em Administração de Empresa com ênfase em Análise de Sistemas pela PUCRS. Tem 8 anos de experiência na área de Teste de Software. Atualmente, é Analista de Teste da equipe Projetos Especiais na NeoGrid.