ISTQB 2024 Section 1.3 – “Seven Testing Principles”
Official Text ↔ Simple English ↔ Korean Translation (한글 해석)
| Official Text | Simple English Explanation | Korean Translation (한글 해석) |
|---|---|---|
| 1. Testing shows the presence of defects, not their absence. Testing can find bugs, but it can’t prove there are none. |
Testing finds problems but cannot prove the software is perfect or completely bug-free. | 테스트는 결함이 있음을 보여줄 수 있지만, 결함이 없다는 것을 증명할 수는 없습니다. |
| 2. Exhaustive testing is impossible. Testing everything is not feasible. |
You can’t test every possible input or path — there are too many combinations. | 모든 입력과 경로를 완전히 테스트하는 것은 불가능합니다. 우선순위를 정해 테스트해야 합니다. |
| 3. Early testing saves time and money. Start testing as early as possible. |
Finding bugs early (for example, during design) is cheaper and faster than fixing them later. | 테스트는 가능한 한 이른 단계에서 시작할수록 시간과 비용을 절감할 수 있습니다. |
| 4. Defects cluster together. Most bugs are found in a few modules. |
Usually, a small number of components contain most of the defects. Focus testing on those areas. | 대부분의 결함은 전체 시스템의 일부 모듈이나 기능에 집중되어 있습니다. 문제가 많은 부분에 집중해야 합니다. |
| 5. Pesticide paradox. Repeating the same tests will find fewer new bugs. |
If you always run the same tests, eventually they stop finding new defects — update and vary tests regularly. | 같은 테스트를 계속 반복하면 새로운 결함을 발견하기 어려워집니다. 테스트 케이스를 주기적으로 갱신해야 합니다. |
| 6. Testing is context dependent. How you test depends on the situation. |
Different systems (e.g., safety-critical vs. gaming app) need different testing approaches. | 테스트는 상황에 따라 달라집니다. 안전 중요 시스템과 게임 앱은 테스트 방법이 다릅니다. |
| 7. Absence of errors fallacy. Even if no bugs are found, the system may still fail to meet user needs. |
Fixing all bugs doesn’t guarantee success if the software doesn’t solve the user’s real problem. | 결함이 없다고 해서 사용자의 요구를 충족한다는 보장은 없습니다. 품질은 기능 뿐 아니라 가치에도 달려 있습니다. |
| Summary | Testing = detect defects early + adapt to context + accept it can’t prove perfection. | 테스트란 결함을 조기에 발견하고, 상황에 맞게 적용하며, 완벽을 증명할 수 없음을 이해하는 활동입니다. |
Tags
ISTQB