A ilusão da garantia de qualidade de software na abordagem tradicional
Atualmente muito se fala e muito se vive a metodologia ágil. Tanto que já não é um termo exclusivo de desenvolvimento de software. Já temos hoje abordagens ágil em recursos humanos, processos financeiros e atendimento ao cliente, por exemplo. Mas de tanto se falar das vantagens de se usar o ágil, percebi que eu não conhecia de maneira concisa a raiz dos problemas de se usar metodologias tradicionais, que há algum tempo atrás funcionaram muito bem em indústrias e projetos de software focados em entrega de grande quantidades de requisitos.
No livro "Agile Testing: A Practical Guide for Testers and Agile Teams (Crispin e Gregory 2009)" um dos capítulos iniciais mostra as similaridade do modelo tradicional com o modelo ágil, usando o waterfall (cascata) como exemplo, para depois mostrar as diferenças. Na abordagem waterfall, todas as etapas são seguidas de forma sequencial. As fases básicas geralmente são de definição de requisitos, planejamento, execução e validação, podendo variar dependendo do tipo de iniciativa, conforme ilustra a imagem abaixo:
Olhando esta abordagem de uma forma otimista, entendemos que o processo de teste é executado em sua totalidade logo após a liberação do código com recursos necessários para tal (inclusive tempo), logo, esta abordagem funciona muito bem quando a preocupação com a qualidade está acima das preocupações com custo ou tempo de desenvolvimento. Entretanto, a prática nesta abordagem é de codificar não apenas pequenas partes do sistema (como estamos acostumados na abordagem ágil) mas de um sistema completo que muitas vezes ficou nesta etapa de codificação durante meses. Com isso, já temos um gatilho para olhar o cenário negativo que esta abordagem pode criar e, citando as palavras das autoras do livro:
"... o processo de teste fica "esmagado" porque a codificação leva mais tempo do que o esperado e porque as equipes entram em um ciclo de codificar e consertar (code-and-fix) no final."
Além do fator tempo, quando são identificados defeitos pelos testes, cria-se dentro daquele diagrama que vimos acima, mais algumas etapas nada agradáveis, o que é chamado de codificar e consertar (code-and-fix):
Nestas etapas adicionais, não há previsibilidade em relação às atividades e não há previsibilidade em relação aos resultados obtidos, tornando muito difícil avaliar a qualidade e os riscos do projeto.
Conhecendo essas desvantagens, adicione o "code-and-fix" em um contexto em que for encontrado um defeito impeditivo de continuar os testes. Logo, é necessário parar todo o processo, aguardar a correção para desimpedir e somente depois retomar as atividades.
Recomendados pelo LinkedIn
De acordo com Lehman (1974), à medida que mudanças são introduzidas no software, as interações entre elementos fazem que a entropia interna aumente, ou seja, ocorre um crescimento cada vez mais desestruturado.
A junção destes acontecimentos, na maioria das vezes resulta em atraso no projeto, atraso na liberação do software para o cliente e alimenta-se a visão de que o time de testes é que está causando o atraso nas entregas. Logo, o controle de qualidade neste contexto se torna uma ilusão, pois os testes são vistos como uma etapa de validação que atrasa as entregas onde pode-se perder a rastreabilidade e confiança das correções.
A diferença da abordagem tradicional para a abordagem ágil, é que no ágil o processo é iterativo e incremental, onde os testadores validam cada incremento da codificação assim que ela termina. Se constrói um pouco e se testa um pouco e, somente após certificado que o que foi feito está funcionando corretamente, passa-se para o próximo "pedaço" do que precisa ser construído. Existem várias abordagens dentro do ágil e uma delas é que cada requisito criado é expandido, codificado e testado e é possível realizar liberações logo após cada iteração sem que isso impacte módulos já validados e liberados anteriormente.
A grande diferença aqui é que os testes não são deixados somente para o final. Com isso é possível obter um feedback rápido, possibilitando a medição de riscos de qualidade, levando o projeto adiante, focando no valor do negócio e entregando o software com a qualidade exigida pelos clientes, em vez de se concentrar apenas na entrega do máximo de requisitos. O controle de qualidade desta forma, não é mais uma etapa "esmagada" e pressionada para a liberação do software e sim uma realidade compartilhada entre todos os membros do projeto.
Referências: