Desvendando o processo de Teste de Software

Em um projeto de software é natural que os envolvidos foquem no resultado final, esperando que a solução funcione corretamente.

Porém, antes de pensarmos no que seria uma solução funcionando corretamente, sugerimos primeiramente que você pense no contexto de negócio onde o sistema está envolvido.

Por questões estratégicas, agilidade na tomada de decisões, redução de custos, entre outras características, grande parte dos sistemas estão integrados, o que aumenta a complexidade e consequentemente a necessidade de testes mais robustos para manter a qualidade.

Com base nisso, chegamos a um segundo pensamento que se faz necessário, apesar de já estar implícito: as soluções precisam funcionar, do ponto de vista técnico e de negócio, ou seja, não podemos nos preocupar apenas se o sistema está funcionando sem erros (visão técnica).

Devemos levar em consideração também se ele está atendendo ao propósito para o qual foi desenvolvido (visão de negócio). No entanto, durante um projeto de desenvolvimento de software, muitas vezes estas visões estão separadas, e é até natural que estejam, pois costumam ser exercidas por áreas diferentes.

Quando é indicado que um software apresenta problemas, não estamos nos referindo apenas à indisponibilidade de um site, lentidão do sistema ou a outra característica técnica. Podemos nos referir também ao fato de o software expor uma característica funcional/de negócio que não está correta.

Este é mais um ponto de atenção que é preciso ter para que no final do projeto possamos afirmar que o software possui qualidade. Antes de continuarmos, vale lembrar que erros, defeitos e falhas são conceitos distintos, porém, para simplificar o entendimento, iremos tratar como uma única definição: “inconformidade do software”.

São pelas razões mencionadas que existem os Testes de Software e as equipes de teste e qualidade. Com base no que foi exposto, ao adotar os testes e garantir uma visão unificada (técnica e funcional) do software, dificilmente os objetivos e resultados esperados da solução não serão alcançados.

Portanto, o objetivo deste artigo é ressaltar a necessidade dos testes e discorrer sobre conceitos importantes, relacionados à fase de planejamento, a qual representa a base para as demais etapas (análise, modelagem, implementação, etc.).

Como um exercício para os desenvolvedores que não gostam de testar ou que acham que a etapa de testes deve ser menor ou praticamente não existir, sugerimos que reflitam sobre os impactos que podem ocorrer quando um software falha. Independentemente da área de seguimento, podemos listar alguns problemas em comum:

• Prejuízos financeiros;
• Perda de credibilidade;
• Perde de qualidade e retrabalho;
• Perda de confiança;
• Ações legais.

A partir desses itens, podemos perceber o quanto os testes precisam ser levados a sério e colocados em um patamar de discussão onde a redução ou eliminação da fase de testes para atingir o prazo e custo desejados seja uma possibilidade.

Para desmitificar a questão de que é possível ter economia de custos ao reduzir a fase de teste, apresentamos nas Figuras 1 e 2 um cenário comum que podemos nos deparar por conta de retrabalho. Note que o cenário de propagação de erros por má/não execução de testes pode gerar custos e retrabalhos maiores ao longo do projeto, os quais certamente superariam os custos de uma fase de testes bem planejada e executada.

Como esperado, este cenário não é aceitável em um projeto, ainda mais quando lidamos com soluções corporativas que exigem precisão cirúrgica de custos e prazos. Portanto, os testes de software não podem ser encarados apenas como mais uma fase do projeto, já que ela pode ser crucial para o sucesso ou fracasso do mesmo. Ao contrário do que muitos pensam, os testes começam muito antes da “simples” execução de testes em cima do código desenvolvido.

Talvez a seguinte definição nos ajude a ampliar um pouco a nossa visão sobre os testes: “Teste é o processo que consiste em todas as atividades do ciclo de vida, tanto estáticas quanto dinâmicas, voltadas para o planejamento, preparação e avaliação de produtos de software e produto de trabalhos relacionados, a fim de determinar se elas satisfazem os requisitos especificados e demonstrar que estão aptas para sua finalidade e para a detecção de defeitos.” (Glossário de termos do ISQB)." [...] continue lendo...