[QA] 테스팅의 일반적인 원리

원리 1 : 테스팅은 결함이 존재함을 밝히는 활동이다

테스팅은 결함이 존재할 수 있는 것을 보여줄 수 있지만 결함이 없다는 것을 증명할 수는 없다.

 

즉 테스팅은 결함이 존재함을 밝히는 활동이다.

---

원리 2 : 완벽한 테스팅은 불가능하다

왜 완벽한 테스팅이 불가능하냐?

 

1. 한 프로그램 내에서의 내부조건이 무수히 많음 (무한 경로)

2. 입력이 가질 수 있는 모든 값의 조합이 무수히 많음(무한 입력값)

3.  GUI(그래픽 유저 인터페이스) 이벤트 발생 순서에 대한 조합이 많음(무한 타이밍)

 

따라서 완벽한 테스팅보다는 리스크 분석과 우선순위를 토대로 테스트에 노력을 집중하는 것이 좋다.

---

원리 3 : 테스팅을 개발초기에 시작한다.

 

개발 수명주기에서 가능한 초기에 시작되어야 하며 설정한 테스트 목표에 집중해야한다.

 

조기 테스트 설계를 하면 코딩이 끝나자마자 개발초기부터 준비한 테스트 케이스를 테스트 레벨별로 실행할 수 있어서 테스팅 결과를 단기간에 알 수 있고 전체적인 테스팅 기간도 줄일 수 있다. 

즉 비용 절감 효과를 기대할 수 있다.

---

원리 4 : 결함 집중

출시 전 대다수의 결함은 소수의 모듈에 집중되어 발생하는 결함을 보인다.

따라서 리스크 분석을 통해 테스트 노력을 집중시키는데 필요하다.

---

원리 5- 살충제 패러독스

동일한 테스트를 반복적으로 수행한다면 나중에는 더이상 새로운 결함을 찾아내지 못한다는 의미이다.

새로운 결함을 발견하기 위해 정기적으로 리뷰하고 개선을 한다.

즉 기존 테스트와 테스트 데이터를 바꾸고 새로운 테스트를 작성할 필요가 있다.

---

원리 6 - 테스팅은 정황에 의존적이다.

테스팅은 정황에 따라 다르게 진행이 된다.

은행 소프트웨어를 테스팅하는 경우는 게임 소프트웨어를 테스팅하는 경우와는 다른 방식으로 진행해야한다.

 

즉 대상에 따라 테스트 내용이 달라지는 것을 의미한다.  

---

원리 7 - 오류-부재의 궤변

많은 결함을 존재함을 발견하고 수정을 하는 것은 좋지만 개발된 시스템이 사용자의 필요와 기대에 부응하지 못하면 이러한 과정은 좋지 못한 과정이다.

정의된 모든 요구사항을 충분히 테스트하고 결함을 수정해도 여전히 사용하기 힘들거나 클라이언트의 요구와 기대에 부흥하지 못한다면 부족한 시스템을 만들어 냈다고 본다.

 

즉 단순히 많은 결함을 발견하고 고쳤다고 해서 시스템의 성공이 보장된다고 생각하는 것은 잘못된 믿음이라는 것이다. 

---

언어폭력 검색 서비스 프로젝트를 하며 검수를 하는 작업을 한 적이 있었는데

직접 개발에 참여하다보니 대부분 위에 적힌 테스팅 원리를 지키지 않은 것 같은 느낌이 들었습니다.

특히 원리5인 살충제 패러독스가 가장 많이 체감이 되었습니다. 

 

그때는 QA라는 직무도 전혀 몰랐으며 내가 개발을 했으니 몇번 테스트를 해보았을 때 정상적으로 작동하면 완벽하지 라는 생각을 특히 많이 한 것 같습니다. 그러다보니 같은 테스트만 반복한 기억이 납니다. 

그래서 조건을 정하고 다양한 테스트를 다시 해본 경험이 있습니다.

 

이런 경험으로 생각해보면 왜 개발자와 QA직무가 나누어져 있는지 체감이 됩니다.