Software com qualidade é mais caro?
Thiago Brito
2 de Março de 2021 Menos de um minuto de leitura

Recentemente eu li um artigo do Martin Fowler onde ele discute sobre o custo de fazer um software com qualidade, é realmente mais caro fazer um software investindo em testes e boa experiência do desenvolvedor desde o início?

Quando comparados com produtos físicos, a tendência é que sejam mais caros devido a melhor qualidade do material, maior complexidade e durabilidade. Todos estes elementos naturalmente tornam o produto mais caro de ser produzido e consequentemente este custo acaba se refletindo no valor final do produto.

Neste artigo vamos discutir algumas armadilhas da percepção inicial de que o custo é maior quando investido em qualidade e os efeitos nocivos deste pensamento ao longo do tempo quando pensamos que podemos economizar pulando esta etapa já no início do projeto.

A grande armadilha, quando pensamos em qualidade de software, é considerarmos o custo de aumento na base de código com novos Unit Tests, setup inicial, maior número de pessoas focadas em testes e também o tempo em que o desenvolvedor está trabalhando em código de teste e não em código que será executado diretamente em produção.

Além disso, gastar um tempo inicial analisando uma boa estrutura do código e como os componentes vão comunicar entre si faz com que o time fique ansioso em ter logo uma vitória rápida entregando algo ao cliente.

Também é muito comum o desenvolvedor ter uma sensação de evolução inicial de desenvolvimento que tende a ser muito maior quando não está sendo investido tempo suficiente em testes, esta percepção tende a ser maior no início do projeto.

Sendo assim, é normal ver equipes que não focam em manter uma base de código com uma extensa base de testes desde o início. Afinal a base de código ainda é pequena e o objetivo entregar valor ao cliente o mais breve possível. 

Quando colocamos esta curva cruzando as funcionalidades criadas em relação ao tempo, vemos a seguinte informação:

Na imagem acima, extraída do artigo do Martin Fowler, mostra que a velocidade inicial crescente com uma tendência de se estabilizar ao longo do tempo. Ou seja, iniciar seu projeto sem uma boa base de qualidade, inicialmente pode parecer um bom negócio, mas em pouco tempo acaba criando uma barreira de produtividade significativa.

Sem uma boa base de testes, apesar da produtividade inicial ser "boa", rapidamente a criação de novas funcionalidades acaba sendo uma tarefa cada vez mais complexa, além de gerar um grande risco de criar bugs que afetam negativamente funcionalidades já existentes.

Já na imagem abaixo, analisamos a situação em que existem dois projetos iguais, onde comparamos a situação onde não existe foco em qualidade e outra com uma excelente qualidade. 

Nesta situação, teremos o seguinte cenário:

Temos aqui alguns pontos importantes:

  • Com alta qualidade a velocidade inicial é menor. Porém o ponto de virada de produtividade tende a ser em algumas semanas e não em meses. Isso pode ser afetado de forma proporcional ao número de desenvolvedores e componentes diversos a serem criados, ou seja, quanto mais DEV e mais funcionalidades, mais rápido o ponto de virada irá ocorrer
  • A linha de crescimento do número de funcionalidades criadas ao longo do tempo compensa a "perda inicial" de produtividade no projeto
  • Sendo assim, quando for criar um novo projeto, considere que terá que dar manutenção ao longo do tempo e que a curva inicial de produtividade mais acelerada no início é apenas uma ilusão.

    Na área de software, um fator importante que afeta o custo de um produto ao longo do tempo é a sua capacidade de adaptação para atender as mudanças nos requisitos dos clientes. Quanto mais difícil for de fazer as mudanças futuras, mais caro o produto será e menor a qualidade percebida pelo cliente devido a falhas e entregas em atraso.

    Criar um produto com uma boa base de testes, independente de quais sejam, tendo como objetivo exercitar o máximo de código com maior cobertura de situações possíveis é sempre a melhor opção.

    Porém, como a maioria dos mortais, nem sempre estamos trabalhando em um projeto completamente novo. Sempre estamos mexendo em códigos legados e em projetos que estão em andamento a algum tempo. Nestas situações, como podemos fazer para aumentar a velocidade de criação de novas funcionalidades?

    Como alterar a curva?

    Quando seu time já está com uma baixa qualidade interna e precisa melhorar a curva, é interessante utilizar algumas estratégias que podem ajudar na segurança ao realizar alterações no produto:

    Crie um ambiente fácil de criar novos testes

    É interessante separar um pedaço do time focado apenas nisso, desta forma, você terá um ambiente rápido para evoluir e colocar novos testes na base. É importante que este ambiente criado seja mantido e melhorado por todo o time e não apenas pelo time de qualidade.

    Ter um bom ambiente para criação e execução de Unit Tests, mantido pelo time de desenvolvimento e System Tests mantido pelo time de qualidade (se houver) e desenvolvimento ajudará a garantir a qualidade futura.

    Nenhum novo código poderá ser criado sem um teste associado

    Implementar bons procedimentos de Code Review e garantir que nada saia sem um teste associado é o investimento que traz retorno mais rápido para a equipe. 

    É exatamente esta ação que trará facilidade e segurança na melhoria contínua do seu projeto.

    Comece a criar testes pelas funcionalidades mais utilizadas

    Muitas vezes os testes são criados em áreas do software que são mais fáceis e não necessariamente tem mais impacto caso quebrem.

    Sempre busque otimizar ao máximo onde criar os testes.

    Cuidado com os refactorings

    Naturalmente ao ver um código bastante ruim, a vontade de jogar ele fora é a maior de todas. Mas reescreve-lo, sem uma boa base de testes, pode ser um grande tiro no pé.

    Além do mais, dependendo da maturidade do projeto, o código já foi testado no campo de batalha a algum tempo.

    O foco é fazer com que novas mudanças sejam feitas sem criar novos problemas, e isso não significa que todo código ruim deva ser mexido.

    Desenvolver software não é uma tarefa fácil, é o conjunto de diversas micro decisões que fazem com que ele seja um sucesso no longo prazo ou um grande fracasso.

    A decisão do time de criar testes logo na largada, apesar de trazer uma sensação de baixa produtividade no início do projeto, reduz o custo de desenvolvimento ao longo do tempo e faz com que a empresa seja capaz de resolver problemas com um menor número de pessoas e tempo tornando o produto cada vez mais barato quando comparado com sua versão com qualidade abaixo do aceitável.