Se você está corrigindo muitos erros no produto final, tem algo de errado!

Quando você compra um produto, a primeira coisa observada é a qualidade. Ou seja, se o produto passou por uma quantidade satisfatória de testes que assegurassem a sua qualidade. Em vários casos existe um selo no produto para certificar os testes realizados.

Por que o mesmo não ocorre com os softwares?

A maioria das empresas de software, principalmente as de pequeno porte, gasta mais tempo corrigindo erros no produto final do que na verificação de erros durante a produção, ou seja, antes da entrega ao usuário final.

Geralmente, nem todos os requisitos do software são levantados na fase inicial do projeto. E, em muitos casos, não existe documentação. Nesses casos, as chances do código ser reescrito durante o projeto é muito alta, além de comprometer a data de entrega do produto final.

Pela ocorrência de problemas com requisitos, e para não ultrapassar a data de entrega, a fase de testes é frequentemente ignorada ou executada por um desenvolvedor.  

Há caso em que os testes são feitos pelo próprio cliente!

Dessa maneira, o produto final é entregue sem a detecção e correção de diversos erros.

Isso porque é de qualidade que estamos falando, algo que deveria ser básico na entrega de qualquer produto! É de cair o queixo, né?  

Em consequência dessa deficiência na execução de testes, o foco da equipe de desenvolvimento é em correção de erros do software entregue. Isso acaba travando o desenvolvimento de novas funcionalidades ou de uma versão mais evoluída daquele software.

Resumindo, existe uma falsa impressão de que a entrega rápida é indicador de qualidade e redução de custos.

O que ocorre é o contrário, pois a detecção e a correção de um erro durante o processo de uso do software pelo cliente custam 100 vezes mais pra empresa do que se esse mesmo erro fosse encontrado e resolvido ainda na fase de requisitos do projeto.

Como melhorar esse quadro?

Se em outras áreas o nível de detalhamento e documentação é extremamente alto antes de iniciar a fabricação de um produto, no caso dos softwares a mesma estratégia deve ser adotada.

A existência de uma equipe de testes preparada e que possua as ferramentas para a elaboração de casos e execução de todos os tipos de testes é primordial para a entrega do projeto com qualidade. Além de impactar diretamente na redução de problemas encontrados na pós-entrega.

Antes da elaboração de casos de testes, devem ser elaborados os casos de uso.

Os casos de uso são criados através de ferramentas CASE após o levantamento de todos os requisitos do projeto.

A representação para modelagem é o diagrama UML (Unified Modeling Language).

Como os casos de uso são compostos:

1. Cenário: descrição dos eventos que ocorrem quando o usuário interage com o sistema;
2. Ator: são os usuários do sistema, representados por bonecos;
3. Caso de Uso: é a funcionalidade realizada pelo ator, representada por uma elipse;
4. Comunicação (relacionamentos): é o que liga o ator a um caso de uso, um ator a outro ator ou um caso a outro caso de uso. É representadoa por flechas, linhas ou flechas pontilhadas.

Após a elaboração dos casos de uso, os casos de testes podem ser criados e executados.

Os tipos de testes dividem-se em funcionais e não-funcionais.

Os testes funcionais verificam as requisições e regras de negócio.

Os testes não-funcionais verificam a confiabilidade, usabilidade, eficiência, manutenção e portabilidade do sistema.

Para a execução dos testes são utilizadas ferramentas que automatizam o processo. A automatização de testes ajuda em relação ao tempo utilizado na execução de testes e na utilização de grandes massas de dados para testes de performance.

Agora só faltam as empresas, mas principalmente os profissionais, mudarem a mentalidade sobre a execução de testes de softwares. É preciso entender que não é mais um custo no projeto, mas um investimento e daqueles que podem evitar muitos prejuízos posteriores.