SW Test - 다양한 검증 방법(2)

6. Regression Testing(회귀 테스트)

 

이미 테스트가 완료된 부분에 테스트를 반복하는 것을 의미합니다. 에러 수정 이후 기능의 변경 등이 있는 경우 이용하거나 발견되지 않았던 또다른 에러를 발견할 수도 있습니다. 버그 수정 이후 그 버그 뿐만 아니라 연관된 기능들에 발생할 수 있는 문제점을 검증합니다. 반복적이고 입체적인 검증을 할 수 있지만 수정된 문제점 위주로 검증을 진행하므로 새로운 문제를 찾을 확률은 낮은 편입니다.

 

비슷한 개념으로 Confirmation Testing(확인 테스트)이 있는데 이는 결함이 발견되고 수정된 후에 원래의 결함이 성공적으로 수정되었는지 확인을 위해 다시 테스트하는 것을 말합니다.

 

 

7. Configuration Testing

 

여러 종류의 환경에서 SW를 검증하는 방법입니다. SW가 여러가지 플랫폼에서도 작동되는지 확인하는 것입니다. 휴대전화용 App을 개발해서 iOS용과 Android용 모두 이상없이 동작하는지 확인하는 것들이 여기에 해당될 수 있습니다. HW기종에 따른 검증을 진행하려면 가격이 비싸다는 단점이 있고 모든 HW를 상대로 검증할 수는 없기 때문에 많은 비용이 들더라도 샘플링 검증을 실시하게 됩니다.

 

8. Exploratory Testing

 

탐색적 테스트는 미리 계획을 세우지 않습니다. 테스트 엔지니어의 지식에 따라 효과성이 결정됩니다. 비용이 적게 들며 누구나 시작할 수 있습니다. 하지만 시스템의 지식에 대한 한계가 있으므로 아는 부분에 대해서만 검증을 진행하므로 모르는 부분은 확인하지 못하고 넘어갈 수 있습니다.

 

 

 

9. Alpha & Beta Testing

 

실사용자의 입장에서 미리 사용해 보는 검증 방법입니다. 알파 테스팅은 주로 회사 내 직원들을 위주로 실시합니다. 같은 회사 내의 다른 개발팀을 대상으로 실시합니다. 풀버전을 설치하지 않고 검증을 원하는 부분만을 선별하여 설치하고 검증합니다. 베타 테스팅은 회사 외부의 실사용자들과 계획을 세워서 검증을 실시합니다. 게임개발업체에서 베타 테스트를 많이 진행하고 있습니다.

 

10. Stress Testing

 

시스템에 가혹한 조건들을 만들어 문제가 생길 때까지 검증하는 방법입니다. 가용 메모리의 양을 최소화시킨다거나 대용량의 데이터를 입력시킨다거나 하는 등의 방법이 있습니다. 검증기간을 줄일 수 있다는 장점이 있지만 비용이 많이 듭니다. 기능이 어느 정도 안정화된 상태에서는 새로운 버그를 찾기가 쉽지 않습니다.