Revisar é preciso
Nos anos 1990, eu estava alocado em um projeto no exterior. A oportunidade foi ótima, passei meses na Holanda (era uma época em que não havia banda larga e a Internet engatinhava; os times eram literalmente transportados para trabalhar fisicamente onde mais fizesse sentido) e aproveitei para aprender o que, na época, eram práticas inovadoras em desenvolvimento de software.
Um dia recebi um convite para participar de uma “Fagan Inspection”. Eu não tinha ideia do que era isso! No horário marcado, na sala reservada, encontrei diversos desenvolvedores que trabalhavam em outros projetos, bem como integrantes da gestão e especialistas em negócio. Na grande mesa, cada um tinha um lugar já reservado, bem como uma cópia impressa de um trecho de código.
Tratava-se de uma revisão técnica formal (o que hoje, nas normativas de Qualidade, se chama de teste estático), em que o autor do código vai “narrando” linha por linha, e os participantes estão livres para interromperem a qualquer momento, tirando dúvidas, dando sugestões e expressando preocupações. No final da reunião, que durou 2 horas, saímos com uma lista grande de bugs, que o autor se comprometia a resolver até uma segunda rodada da inspeção.
Em que pesem as diferenças de tecnologia e formato da época, a revisão formal que realizamos me chamou a atenção porque:
Encontrou bugs muito cedo no processo de desenvolvimento (inclusive uma boa parte do código nem podia ainda ser testada por conta de dependências externas)
“Educou” os participantes acerca da implementação, via artefato de software, das regras de negócio que a solução se propunha a implementar
Mais tarde, estudando Qualidade no Desenvolvimento de Software e as primeiras versões do CMM (Capability Maturity Model), aprendi que as revisões formais eram a expressão do nível “3PR” do modelo, em que se preconizava a revisão, por terceiros, de artefatos e meta-artefatos de software, com a finalidade de detecção precoce de inconformidades. E a genialidade de tudo isso estava em que uma tarefa relativamente simples (revisar) tinha ganhos tão importantes - em particular, o ganho quanto a retrabalho.
Ao longo então de minha carreira como Engenheiro de QA, sempre que possível, procurei aplicar o conceito de revisões - nas suas diversas formas, desde mais informais até mais formais, e desde “manuais” até automatizadas - como uma prática-chave de garantia de Qualidade. Nessa jornada de 3 décadas, aprendi que:
Qualquer artefato ou meta-artefato de software pode ser sujeito a revisão, com potenciais ganhos: código, especificações, artefatos de design, fluxogramas, documentação funcional e técnica, cards, tickets etc.
A revisão tem maior ganho quando não são observados apenas aspectos técnicos, mas também aspectos funcionais.
Revisões automatizadas (como as feitas por ferramentas de análise estática) trazem muito valor mas não substituem o olhar de um colega que não tem o mesmo viés de confirmação que o autor do artefato.
Qualidade x Meta-Qualidade
Assim como o próprio software em si, todos os artefatos e subprodutos derivados do processo de desenvolvimento de software também estão sujeitos a falhas - seja de conteúdo (especificação), seja de forma (aderência a padrões não-funcionais). Em especial, quando falamos de artefatos de Qualidade, como, por exemplo, cenários de teste, planos de teste, processos documentados, registros de falhas, código de automação, relatórios etc. torna-se ainda mais crítico criar políticas de meta-qualidade, isto é, políticas que promovam a revisão periódica e sistemática dos próprios artefatos de qualidade.
Entretanto - e aqui existe a necessidade de um balanço que depende muito do contexto e da maturidade de cada projeto -, é preciso cautela para que não entremos em uma toca de coelho. Ações de meta-qualidade só devem ser implementadas quando:
(1) O time/projeto já tem maturidade suficiente, em especial com métricas básicas sob controle e
(2) As políticas são implementadas de forma gradual e incorporadas ao processo ágil existente.
Observados os pontos acima, a revisão dos artefatos de Qualidade mostra-se extremamente produtiva, com resultados que vão na direção da otimização contínua dos processos de garantia de Qualidade.
Em suma, a jornada desde a sala de reuniões na Holanda até a defesa da meta-qualidade me ensinou que a revisão, em suas múltiplas facetas, é um pilar fundamental para a construção de software de qualidade. Mais do que encontrar bugs precocemente, a revisão promove o alinhamento, o aprendizado compartilhado e a melhoria contínua, tanto do código quanto dos processos que o geram, além de eliminar o viés de confirmação dos autores dos artefatos sendo revisados. Ao aplicar os princípios da revisão em todos os artefatos, inclusive nos da própria garantia de qualidade, as equipes podem elevar o nível de seus produtos e aprimorar a excelência em cada etapa do ciclo de desenvolvimento. Contudo, a chave para o sucesso reside no equilíbrio: em particular, no caso da meta-qualidade, esta deve ser implementada com parcimônia e consciência, adaptando-se à maturidade do time e ao ritmo ágil, para que a busca pela perfeição não se torne um obstáculo à entrega de valor.