Testes simulados X Testes na vida real

Testes simulados X Testes na vida real

Dentro do processo de desenvolver um produto ou serviço, uma das etapas finais é validar se aquele item consegue atender as necessidades do cliente.

Dentro do desenvolvimento de software, as metodologias ágeis propõem entregas parciais, de algumas funções, em períodos de tempo curtos (chamados de sprints) para o cliente real já ter acesso e avaliar se o software executa como necessita. Desta forma, o feedback do cliente corrige a direção dos próximos passos com menor custo. Uma mudança no software tardia exigiria mudar muito código em diversas partes (módulos), aumentando o prazo e o custo. Neste modelo, não é esperado um conjunto rígido de necessidades previamente definidas, as necessidades mudam conforme o cliente utiliza.

Delegar para o cliente final validar é uma estratégia que vem ganhando espaço, principalmente em aplicativos “grátis” para smartphones em que usuários voluntários se inscrevem para este fim, como exemplo o Whatsapp abaixo que já lotou.


Mas esta ideia pode ser prejudicial para marca e reputação, principalmente quando o cliente está pagando por uma solução e não optou por ser um testador. Pior cenário quando impacta a operação do cliente, impedindo seu faturamento.

Diferentes formas de validar

Um contorno para verificar sem interferir no cliente é contar com profissionais especializados em validações. Há diferentes tipos de testes a serem realizados, dentre eles:

1.       Testes unitários – se aquela função executa a ação corretamente, isolado das demais

2.       Teste funcionais – se o conjunto de funções tem o resultado esperado correto, ações típicas do usuário

3.       Testes integrados – se a nova função não gera erro nas demais

4.       Testes E2E (end-to-end) fim a fim – se o fluxo e o resultado estão corretos para aquele negócio, como usuário final

5.       Testes exploratórios

Quando se trata de software, os testes do 1 ao 4 são amplamente automatizados com diferentes ferramentas, pois assim podem ser executadas repetidamente nas próximas sprints, reduzindo o custo com testes.

Porém, todas estas opções possuem limitações. Percebo ao longo dos anos que a forma como o cliente utiliza na vida real, com dados válidos em grande quantidade, não é refletida nas simulações e automatizações, tornando o processo ineficaz. Isto é mais evidente quando a solução não é apenas software e interage com outros equipamentos, gerando erros absurdamente básicos com impacto catastrófico.

Portanto, realizar testes no ambiente real (em campo), no local e ambiente que o produto ou solução é utilizado de verdade, permite identificar e tratar problemas não encontrados pelos testes automatizados ou simulados. Avaliar uma solução em campo apresenta um custo maior, e por isto não pode ser a única forma de validação, e por isto é essencial um profissional experiente para escolher cenários corretos com uso mais intensivo, sendo desta forma eficiente no processo.

Entre para ver ou adicionar um comentário

Outros artigos de Willian José Ceccon Ramos

  • DFMEA aplicado a software embarcado?

    DFMEA aplicado a software embarcado?

    No seu negócio, os produtos ficam bons quando termina o prazo do projeto? Ou surgem muitos problemas graves depois do…

  • IoT bom é aquele que não é lembrado

    IoT bom é aquele que não é lembrado

    Semana passada criei o artigo sobre a relevância de IoT (Internet of Things) para algumas áreas. Nesta semana vou…

    1 comentário
  • IoT na borracharia?

    IoT na borracharia?

    Semana passada me deparei com um vídeo de um brasileiro que colocou em sua humilde borracharia uma Alexa Echo. É a IoT…

    2 comentários

Outras pessoas também visualizaram

Conferir tópicos