O que se pode aprender com Bugs?

IMG_1296(Berlim, Memorial aos Judeus assassinados na Europa) – Há algumas semanas, quando visitei o Memorial, o sentimento de solidão e falta de direção invadiu-me. Acho que esta foi a principal conquista do arquiteto (Peter Eisenman)… trazer este sentimento para os visitantes. Exactamente na posição em que tirei a foto, perguntei-me “o que aprendemos com este horror?”. Inspirada pelos princípios de  aprendizagem contínua para melhoria contínua, gostaria de fazer a mesma pergunta mas aplicada a bugs e alteracoes de requisitos ou Change requirements (CR): o que podemos aprender com bugs? Podemos encara-los como oportunidades de melhoria.

Bugs realcam sempre alguma vulnerabilidade no planeamento e implementacao do produto, desde as fases iniciais de requisitos. Mas se os bugs chegam até ao utilizador/ usuário final, bloqueando o melhor desempenho e percepção do produto, as razoes para tal devem ser analisadas e o facto deve ser encarado como oportunidades de melhoria.

Bugs saem extremamente caros, desde os custos para corrigi-los até ao risco de decepção e perda de clientes. Sobre este assunto muito se tem escrito, recomendo particularmente o resumo efectuado no post: o custo financeiro dos bugs de software

Requisitos mal documentados ou incompletos, também originam interpretações erradas sobre as funcionalidades desejadas. É por isso que as funcoes de engenheiro de requisitos, analista de negócios e engenheiros de Experiencia do Utilizador (UX) são tão importantes, quando introduzidos desde a fase de exploração do projeto. Técnicas de prototipagem rápidas (interativas ou baseadas em papel) podem ser muito úteis para criar uma entendimento comum antes de iniciar a fase de programação.

Podem verificar-se também ineficiências ou erros no design da solução ou arquitetura, sendo que, nestas situacoes bugs ou ineficiências serão detectados após a implementacao do produto, já com ele contexto real de utilizacao.

Outra situação de risco ocorre quando o design ou arquitetura da solucao sao feitas ou aprovadas por pessoas não qualificadas para tal. Infelizmente, acontece muitas vezes, especialmente em grandes organizações, que arquitetura e importantes decisões ao nível do design de solução são tomadas, nao por pessoal qualificado, mas por niveis hierarquicos superiores, sem chamarem estes peritos a contribuirem.

Gostaria de partilhar convosco algumas notas pessoais, onde descrevo, como comeco a desenhar um plano para balizar qualidade, definindo ferramentas com claros objectivos de teste e aceitacao dos requisitos desde a fase inicial do projecto.

O que podemos aprender com Bugs?

Devemos reforçar a qualidade, a cobertura e a automação de testes, com vista a uma prática contínua de testes, reforçada pela introdução em vários níveis de automação.




Deixar uma resposta

Este site utiliza o Akismet para reduzir spam. Fica a saber como são processados os dados dos comentários.