일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
Tags
- Test Case
- Testing
- 위험 기반 테스트
- 테스트케이스
- 비기능테스트
- 유지보수성 테스트
- testing method
- test
- 파이썬
- RBT
- Software life cycle model
- SQA
- 셀레니움
- selenium
- ISTQB
- seleium
- 품질
- 테스트
- Python
- csts
- 애자일
- 자동화
- regression test
- 테스트 설계 기법에 따른 분류
- agile
- risk-based testing
- QA
- 테스트 케이스
- testcase
- maintainability test
Archives
- Today
- Total
Study_Note
why perfect testing is impossible 본문
728x90
반응형
완벽한 테스트가 불가능 한 이유
(why perfect testing is impossible)
소프트웨어 품질 보증(QA)에서 완벽한 테스트가 불가능한 이유는 여러 가지가 있습니다.
몇 가지 주요 이유는 다음과 같습니다.
- 시간과 비용의 제약
소프트웨어는 복잡하며 다양한 기능과 상호작용을 가지고 있습니다. 모든 가능한 상황을 고려하고 테스트하는 것은 많은 시간과 비용이 소요됩니다. 일부 경우에는 이러한 리소스가 제한적일 수 있습니다. - 무한한 입력 조합
소프트웨어는 다양한 입력 조합에 노출됩니다. 이 입력 조합의 수는 매우 많아서 모든 경우를 테스트하는 것은 현실적으로 불가능합니다. 사용자의 행동, 환경 조건, 하드웨어 및 소프트웨어의 조합 등이 무한하게 다양하기 때문입니다. - 복잡성과 다양성
소프트웨어는 복잡한 시스템으로, 다양한 구성 요소 및 서로 다른 상태로 동작할 수 있습니다. 이러한 다양성 때문에 모든 측면을 완벽하게 테스트하는 것은 어려운 일입니다. - 인간 요소
사용자의 행동 및 의도는 예측하기 어렵습니다. 사용자는 예상치 못한 방식으로 소프트웨어를 사용할 수 있으며, 이러한 사용자 행동을 예측하고 테스트하는 것은 매우 어려울 수 있습니다. - 변경 가능성
소프트웨어는 지속적으로 변경되고 업데이트됩니다. 새로운 기능의 추가나 기존 기능의 수정은 예기치 못한 부작용을 일으킬 수 있습니다. 이로 인해 완벽한 테스트를 유지하기가 어려워집니다. - 비결정적 특성
소프트웨어는 비결정적인 특성을 가지고 있습니다. 동일한 입력에 대해 항상 동일한 결과를 보장하기 어렵기 때문에 모든 시나리오에 대한 테스트를 완벽하게 수행하는 것이 어렵습니다.
따라서 QA 팀은 가용한 리소스 내에서 최대한 효과적으로 테스트를 수행하고, 중요한 기능 및 시나리오에 중점을 두어 소프트웨어의 가장 중요한 측면을 보호하는 데 중점을 둬야 합니다. Test coverage를 최대한 높이고, 지속적인 테스트 및 피드백을 통해 소프트웨어 품질을 지속적으로 개선하는 것이 중요합니다.
동적 테스트에서는 테스트의 한계를 고려하여 효율적으로 테스트 케이스를 설계하기 위해 여러 방법이 사용됩니다. 이러한 방법에는 '동등 분할', '경계값 분석', '조합 테스트' 등의 다양한 방법이 있습니다.
위험 기반 테스트 방법은 테스트 대상의 각 특성에 대한 위험을 분석하고, 그 결과를 기반으로 테스트의 범위를 결정하여 효율적인 테스트 전략을 수립하는 방법입니다. 이를 통해 한정된 비용과 시간 내에서 테스트의 효과를 극대화할 수 있습니다.
[ example ]
- 입력 조합의 다양성
- 웹 브라우저에서 로그인 기능을 테스트한다고 가정해봅시다. 사용자 이름과 비밀번호를 입력하는 부분만 고려하더라도, 올바른 조합, 잘못된 조합, 특수문자의 유무, 대소문자 구분 등 다양한 경우의 수가 있습니다. 이러한 모든 경우를 테스트하는 것은 시간과 노력이 많이 드는 작업입니다.
- 복잡성과 다양성
- 은행 소프트웨어에서 송금 기능을 테스트한다고 상상해봅시다. 이 기능은 사용자 계좌 상태, 수취인 계좌 상태, 보안 조치 등 다양한 부분에서 상호작용합니다. 모든 가능한 상황을 고려하여 완벽하게 테스트하는 것은 거의 불가능에 가깝습니다.
- 인간 요소
- 쇼핑 웹사이트를 테스트한다고 가정합시다. 사용자는 상품을 장바구니에 담고 결제를 진행할 것입니다. 그러나 실제 사용자는 예상치 못한 상황에서 웹사이트를 이용할 수 있습니다. 예를 들어, 주문 중에 인터넷 연결이 끊길 수도 있고, 사용자가 뒤로 가기 버튼을 여러 번 누를 수도 있습니다.
- 변경 가능성
- 모바일 앱의 새로운 업데이트가 나왔다고 상상해봅시다. 업데이트로 인해 기존 기능의 동작 방식이 변경되었을 수 있습니다. 이 경우 새로운 기능 뿐만 아니라 기존 기능의 테스트도 필요합니다. 그리고 이러한 변경은 예상치 못한 새로운 버그를 발생시킬 수 있습니다.
- 비결정적 특성
- 게임 소프트웨어에서 랜덤 이벤트가 발생한다고 상상해봅시다. 이 이벤트는 항상 같은 조건에서 발생하지 않으며, 사용자의 선택에 따라 결과가 달라질 수 있습니다. 이처럼 소프트웨어가 언제나 동일한 결과를 내놓지 않는 특성이 있어 완벽한 예측이 어려워집니다.
'QA_study' 카테고리의 다른 글
test bed, test driver, test stub (0) | 2024.07.26 |
---|---|
sanity test , smoke test , regression test (1) | 2024.02.26 |
requirements engineering (1) | 2023.12.08 |
software life cycle model (2) | 2023.12.06 |
decision table testing (0) | 2023.07.31 |