Test principles Flashcards
Testing shows the presence, not the absence of defects
Testing can show that defects are present in the test object, but cannot prove that there are no defects (Buxton 1970). Testing reduces the probability of defects remaining undiscovered in the test object, but even if no defects are found, testing cannot prove test object correctness.
O teste pode mostrar que há defeitos no objeto de teste, mas não pode provar que não existem defeitos (Buxton, 1970). O teste reduz a probabilidade de que defeitos permaneçam não descobertos no objeto de teste, mas, mesmo que nenhum defeito seja encontrado, o teste não pode provar a correção do objeto de teste.
Exhaustive testing is impossible
Testing everything is not feasible except in trivial cases (Manna 1978). Rather than attempting to test exhaustively, test techniques, test case prioritization and risk-based testing, should be used to focus test efforts.
Testar tudo não é viável, exceto em casos triviais (Manna, 1978). Em vez de tentar testar exaustivamente, técnicas de teste , priorização de casos de teste e testes baseados em risco devem ser usados para focar os esforços de teste.
Early testing saves time and money.
Defects that are removed early in the process will not cause subsequent defects in derived work products. The cost of quality will be reduced since fewer failures will occur later in the SDLC (Boehm 1981). To find defects early, both static testing and dynamic testing should be started as early as possible.
Defeitos que são removidos cedo no processo não causarão defeitos subsequentes em produtos derivados. O custo da qualidade será reduzido, pois ocorrerão menos falhas nas etapas posteriores do ciclo de vida do desenvolvimento de software (Boehm, 1981). Para encontrar defeitos cedo, tanto o teste estático quanto o teste dinâmico devem ser iniciados o mais cedo possível.
Defects cluster together.
A small number of system components usually contain most of the defects discovered or are responsible for most of the operational failures (Enders 1975). This phenomenon is an illustration of the Pareto principle. Predicted defect clusters, and actual defect clusters observed during testing or in operation, are an important input for risk-based testing.
Um pequeno número de componentes do sistema geralmente contém a maioria dos defeitos descobertos ou é responsável pela maioria das falhas operacionais (Enders, 1975). Esse fenômeno é uma ilustração do princípio de Pareto. Agrupamentos de defeitos previstos e agrupamentos reais observados durante o teste ou na operação são um importante insumo para testes baseados em risco.
Tests wear out.
If the same tests are repeated many times, they become increasingly ineffective in detecting new defects (Beizer 1990). To overcome this effect, existing tests and test data may need to be modified, and new tests may need to be written. However, in some cases, repeating the same tests can have a beneficial outcome, e.g., in automated regression testing.
Se os mesmos testes são repetidos várias vezes, eles se tornam cada vez menos eficazes na detecção de novos defeitos (Beizer, 1990). Para superar esse efeito, os testes e dados de teste existentes podem precisar ser modificados, e novos testes podem precisar ser criados. No entanto, em alguns casos, repetir os mesmos testes pode ter um resultado benéfico, como nos testes de regressão automatizados.
Testing is context dependent.
There is no single universally applicable approach to testing. Testing is done differently in different contexts.
Não existe uma abordagem universalmente aplicável para testes. O teste é realizado de maneira diferente em diferentes contextos.
Absence-of-defects fallacy
It is a fallacy (i.e., a misconception) to expect that software verification will ensure the success of a system. Thoroughly testing all the specified requirements and fixing all the defects found could still produce a system that does not fulfill the users’ needs and expectations, that does not help in achieving the customer’s business goals, and that is inferior compared to other competing systems. In addition to verification, validation should also be carried out.
É uma falácia (ou seja, uma concepção errônea) esperar que a verificação de software garanta o sucesso de um sistema. Testar minuciosamente todos os requisitos especificados e corrigir todos os defeitos encontrados ainda pode resultar em um sistema que não atenda às necessidades e expectativas dos usuários, que não ajude a alcançar os objetivos de negócios do cliente e que seja inferior em comparação com outros sistemas concorrentes. Além da verificação, a validação também deve ser realizada.
