A inclusão de testes de qualidade no desenvolvimento de software

Não é segredo que em muitos livros de desenvolvimento de software, a inclusão de testes de qualidade neste processo é sempre refletida e a verdade é que, se não prestarmos atenção à qualidade, os custos de manutenção do produto e a capacidade de entrega serão afetados por termos de estar constantemente a corrigir a aplicação ou a resolver incidentes encontrados pelo próprio cliente final. A tudo isto, temos de acrescentar que a nossa aplicação dará um mau serviço por estar cheia de falhas.

Muitas vezes recebemos um código que inevitavelmente tem alguns erros e temos de o corrigir, mas sem quebrar nada, porque se "algo" quebra, teremos de corrigir tudo. De fato, quando o código é custoso de ser mantido, é decidido iniciar novamente a aplicação. Agora, não podemos esperar em nenhum dos casos uma qualidade total, uma vez que é muito cara, contudo, sem um elevado nível de qualidade, é difícil sustentar os custos e a entrega esperada de valor.
 

Há três frases que estão a matar a qualidade no desenvolvimento de software, vamos revê-las:

1. A primeira frase é "Vai haver sempre problemas". Não podemos aspirar à qualidade total com zero incidências, isso é verdade. Equipas com altos níveis de qualidade têm um baixo número de incidentes.
2. A segunda é "Se tivermos tempo, testamos". Com esta frase, tentamos explicar que vamos concentrar-nos no objetivo, que é o que o cliente pediu, e uma vez terminado, vamos prestar atenção à qualidade do nosso produto. No entanto, a experiência mostra-nos que nunca há tempo para a qualidade. O cliente acaba por solicitar alterações ao receber as primeiras funcionalidades, e isto porque as necessidades mudam ou aparecem novas funcionalidades. O resultado é que atingimos uma data sem qualquer tipo de testes, o que acaba por gerar incidentes e um mau serviço aos utilizadores.
3. Finalmente, a terceira frase mais usada é "Vamos corrigi-la na próxima fase". Em muitas equipas, apressamo-nos a terminar uma primeira entrega a tempo, e deixamos a qualidade para a fase seguinte ou contrato com o cliente. No entanto, quando a fase 1 tiver corrido mal, e tivermos de colocar horas extra para "lá chegar", vamos lutar para mudar a nossa estratégia na fase 2. O problema subjacente é a cultura de relacionar o sucesso com a entrega atempada, e não com a qualidade do serviço prestado. De fato, se nos queixarmos do número de incidentes que geramos, alguém nos irá lembrar da primeira frase: "Haverá sempre incidentes".

"Se o McDonald's funcionasse como uma empresa de software, um em cada cem Big Mac's iria envenená-lo, e a resposta seria «desculpe, aqui está um cupão para mais dois»" -  Mark Minasi.

Quais destas já ouviste na BABEL ou na equipa?

Assim, se for possível incluir uma pessoa de GQ na equipa de desenvolvimento desde o início, que se dedique a garantir a qualidade do produto enquanto este se encontra em fase de desenvolvimento, vai acontecer o seguinte:

• Vamos minimizar o número de incidentes;
• Teremos sempre tempo para testar;
• Passamos para a fase seguinte livre de bugs.