Teste de Software - Mitos
A seguir, estão alguns dos mitos mais comuns sobre o teste de software.
Mito 1: o teste é muito caro
Reality- Há um ditado que diz: pague menos pelos testes durante o desenvolvimento do software ou pague mais pela manutenção ou correção posterior. O teste antecipado economiza tempo e custo em muitos aspectos; no entanto, reduzir o custo sem testar pode resultar no design impróprio de um aplicativo de software, tornando o produto inútil.
Mito 2: o teste consome muito tempo
Reality- Durante as fases SDLC, o teste nunca é um processo demorado. No entanto, diagnosticar e corrigir os erros identificados durante o teste adequado é uma atividade demorada, mas produtiva.
Mito 3: Somente produtos totalmente desenvolvidos são testados
Reality- Sem dúvida, o teste depende do código-fonte, mas a revisão dos requisitos e o desenvolvimento de casos de teste são independentes do código desenvolvido. No entanto, a abordagem iterativa ou incremental como um modelo de ciclo de vida de desenvolvimento pode reduzir a dependência do teste no software totalmente desenvolvido.
Mito 4: o teste completo é possível
Reality- Torna-se um problema quando um cliente ou testador pensa que o teste completo é possível. É possível que todos os caminhos tenham sido testados pela equipe, mas a ocorrência de testes completos nunca é possível. Pode haver alguns cenários que nunca são executados pela equipe de teste ou pelo cliente durante o ciclo de vida de desenvolvimento do software e podem ser executados após a implantação do projeto.
Mito 5: um software testado não contém erros
Reality - Este é um mito muito comum no qual os clientes, gerentes de projeto e a equipe de gerenciamento acreditam. Ninguém pode afirmar com certeza absoluta que um aplicativo de software é 100% livre de bugs, mesmo que um testador com excelentes habilidades de teste o tenha testado .
Mito 6: Os defeitos perdidos são devidos aos testadores
Reality- Não é uma abordagem correta culpar os testadores por bugs que permanecem no aplicativo, mesmo após o teste ter sido executado. Esse mito está relacionado às restrições de mudança de tempo, custo e requisitos. No entanto, a estratégia de teste também pode resultar na perda de bugs pela equipe de teste.
Mito 7: Os testadores são responsáveis pela qualidade do produto
Reality- É uma interpretação errônea muito comum que apenas os testadores ou a equipe de teste devem ser responsáveis pela qualidade do produto. As responsabilidades dos testadores incluem a identificação de bugs para as partes interessadas e, em seguida, é sua decisão se eles irão corrigir o bug ou lançar o software. Liberar o software na hora coloca mais pressão sobre os testadores, pois eles serão responsabilizados por qualquer erro.
Mito 8: A automação de teste deve ser usada sempre que possível para reduzir o tempo
Reality- Sim, é verdade que o Test Automation reduz o tempo de teste, mas não é possível iniciar a automação de teste a qualquer momento durante o desenvolvimento do software. O autômato de teste deve ser iniciado quando o software foi testado manualmente e está estável até certo ponto. Além disso, a automação de teste nunca pode ser usada se os requisitos continuarem mudando.
Mito 9: Qualquer pessoa pode testar um aplicativo de software
Reality- Pessoas fora da indústria de TI pensam e até acreditam que qualquer pessoa pode testar um software e testar não é um trabalho criativo. No entanto, os testadores sabem muito bem que isso é um mito. Pensar em cenários alternativos, tentar travar um software com a intenção de explorar possíveis bugs, não é possível para a pessoa que o desenvolveu.
Mito 10: A única tarefa de um testador é encontrar bugs
Reality- Encontrar bugs em um software é tarefa dos testadores, mas ao mesmo tempo, eles são especialistas no domínio do software específico. Os desenvolvedores são responsáveis apenas pelo componente ou área específica que lhes é atribuída, mas os testadores entendem o funcionamento geral do software, quais são as dependências e os impactos de um módulo em outro.