97. 소프트웨어 테스팅
성공적인 소프트웨어 신상품 개발가이드
테스트는 소프트웨어 버그를 발견하기 위한 활동이다. 이번 섹션에서는 테스트의 원칙, 테스트 유형, 테스트 유의사항을 설명한다.
소프트웨어 불량을 표현하는 용어로 오류(error), 버그(bug), 결함(defect)이 있는데 아래와 같이 조금씩 의미가 다르다. <소프트웨어 테스트 법칙 293가지, 2004>
- 장애(Fault) : 프로그램의 설계 또는 구현상 오류나 실수를 의미하며 오류(error)도 장애이다.
- 버그 : 소프트웨어가 무엇인가 잘못된 것을 이야기할 때 포괄적으로 이 용어를 사용한다. 보고하는 사람은 버그를 장애, 오동작으로 이야기하기도 한다. 버그가 불량을 의미하는 의미로 사용하게 된 배경에는 1940년대 미국 하버드대에서 그레이스 호퍼라는 사람이 컴퓨터의 오작동을 발견했는데 그 원인이 모기였다는 데서 비롯되었다.
- 결함 : 이 용어는 법적 책임을 수반한다. 결함은 제품에서 명백하게 잘못된 무언가를 의미한다. 따라서 몇몇 기업에서는 결함이라는 용어 대신 예외상황, 문제점이라는 용어를 사용한다.
이책에서는 일반적으로 많이 사용하는 오류나 결함을 구분 없이 사용하겠다.
<거꾸로 배우는 소프트웨어 개발, 2011>은 결함과 세균의 공통점을 다음과 같이 설명하고 있다.
• 지저분하고 더러운 곳에 산다. 깨끗한 것을 싫어한다. 깔끔하고 청결한 소스코드에는 버그가 숨어 살기 어렵다.
• 평소에는 너무 작아서 잘 안 보인다. 병에 걸리면 그때서야 세균에 감염된 걸 알게 된다.
• 주로 떼로 몰려서 산다. 한 놈이 발견되었다면, 거기에 다른 놈들도 우글우글 몰려 살고 있을 가능성이 높다.
• 어지간해서는 박멸이 어렵다. 완전 무균상태는 다분히 이상적인 실험실 환경에서나 가능하다.
• 독자 생존보다는 숙주에 묻어서 산다. 숙주와 매개체가 있어야 번식과 전염이 가능하다.
1) 7가지 소프트웨어 테스팅 원칙
많이 알려진 소프트웨어 테스팅 7가지 원칙은 다음과 같다.
원칙 1 : 테스팅은 결함이 존재함을 밝히는 활동이다.
테스트는 결함이 존재함을 밝히는 활동이지 결함이 없다는 것을 증명하기 위한 활동이 아니다. 더 이상 결함을 발견할 수 없는 상태라 해도 결함이 없다는 것을 증명할 수는 없다. 시간이 지나 언제든지 결함이 발생할 수 있기 때문이다. ‘증거의 부재’가 ‘부재의 증거’는 아니다. 품질이 완벽하지 않다는 것은 결함 한 개만 발견하면 입증 할 수 있지만, 품질이 완벽하다는 것은 입증이 불가능하다.
원칙 2 : 완벽한 테스팅(Exhaustive Testing)은 불가능하다.
이는 원리 1과 연관된다. 완벽한 테스팅이 불가능하기 때문에 결함이 없다는 것의 입증도 불가능하다. 예를 들어 계산기의 기능이 정확하다는 테스트를 어떻게 할 수 있을까? 입력 가능한 모든 수에 대해 사칙연산을 해야 하는가? 워드의 글꼴 지정 테스트도 글꼴 30개, 크기 21종, 색 100가지, 밑줄, 스타일 등을 고려하면 모든 경우의 수를 테스트하기 힘들다. 완벽하게 테스팅 하려는 시도는 불가능할 뿐 아니라 불필요하다.
원칙 3 : 테스팅은 개발 초기에 시작해야 한다.
결함은 조기에 발견할수록 해결비용이 작다. IBM System Science Institute에 의하면 설계단계 결함수정 비용을 1이라고 하면, 코딩시점의 수정비용은 6.5, 테스트 시점은 15, 운영시점에서는 100 이상이라고 한다.
원칙 4 : 결함은 특정 영역에 집중된다 (Defect Clustering)
20%의 원인에서 80%의 결과가 나온다는 파레토 법칙처럼 적은 수의 모듈에서 대다수의 결함이 발견된다. 많은 결함이 발견되는 모듈의 특징은 다음과 같다.
• 복잡한 구조 또는 인터페이스를 가진 모듈
• 난이도가 높은 최신 기술을 적용한 모듈
• 재사용이 아닌 신규개발 모듈 또는 경험이 낮은 개발팀에서 개발한 모듈
원칙 5: 살충제 패러독스(Pesticide paradox)에 유의한다.
살충제를 사용하여 벌레를 잡는 경우 잡을 수 있는 벌레는 한정되어 있다. 테스트 케이스도 마찬가지이다. 동일한 테스트 케이스를 활용한 반복적 테스트로 발견 가능한 결함은 한계가 있다. 보다 많은 결함을 발견하기 위해서는 테스트 케이스를 정기적으로 리뷰하고 개선해야 한다.
원칙 6: 테스팅은 정황(Context)에 의존적이다.
상품의 특성, 사용하는 환경, 고객에 따라 최적의 테스팅 방법은 달라져야 한다.
원칙 7 : 오류-부재의 궤변(Absence of errors fallacy)에 유의한다.
수많은 결함을 발견하고 수정했다고 해서 고객만족을 보장하는 것은 아니다. 품질이 좋은 많은 상품들이 시장에서 실패한다. 오탈자 없는 책이라고 잘 팔리지 않는 것과 같은 이치이다.
2) 테스트 유형
- 블랙박스 테스트(Black-Box Test) vs 화이트박스 테스트(White Box Test)
블랙박스 검사 기법은 소프트웨어 내부를 보지 않고 입력과 출력값을 확인하여, 기능의 유효성을 판단하는 테스트 기법이다. 화이트박스 검사 기법은 소프트웨어 내부 소스코드를 확인하는 기법이다. 화이트박스 테스트를 하는 이유는 소스코드의 실행경로를 파악하여 불필요한 코드 혹은 테스트되지 못한 부분이 있는지를 살펴볼 수 있기 때문이다.이상을 요약하면 표 *와 같다.
- 테스트 레벨에 따른 구분 (단위/통합/시스템/인수 테스트)
. 단위 테스트는 프로그램 단위의 테스트로 개발자가 수행한다. 오류처리 경로, 모듈 내 인터페이스, 경계값을 확인한다.
. 통합테스트는 소프트웨어, 하드웨어를 통합한 인터페이스를 확인하는 방법으로 모듈을 단계적으로 통합하는 점진적 통합방법과 모든 모듈을 한꺼번에 테스트하는 빅뱅방법이 있다.
. 시스템 테스트는 성능, 보안, 신뢰성과 같은 비 기능적 요구사항을 테스트한다.
. 인수테스트는 실제 사용자가 실제 사용환경에서 통합 및 시스템 테스트를 수행하는 것이다.
- 알파, 베타 테스트
• 알파 테스트
상품 출시 전 회사 내에서 수행하는 테스트이다. 일명 개밥 먹기 (dog fooding) 라고도 한다. 이는 알포 사료 회장인 론 그린이 의심 많은 대중을 상대로 광고를 하면서 자기 개에게도 알포사료를 준다고 말한 데서 유행했으며, 마이크로소프트에서 많이 사용되었다.
• 베타 테스트
알파 테스트 결과를 보완하여 상품 출시 전에 실제 사용자를 대상으로 수행하는 테스트이다. 베타테스트를 통해 사내에서 검증하기 힘든 소프트웨어의 다양한 설치환경, 다양한 장비와의 호환성, PC 및 스마트폰의 사양, 성능 등을 검증할 수 있다.
카카오 브런치의 경우 15년 6월 베타테스트를 오픈한 후 19년 8월까지 4년 이상의 베타버전을 운영했다. 이와 같이 베타테스트를 통해 얻어진 정보를 바탕으로 상품을 다시 수정하여 완성품에 대해 충분한 시간을 갖고 실시하는 사용자 테스트를 감마테스트라고도 한다.
3) 테스트 시 유의사항
- 제한된 자원, 시간으로 테스트를 효과를 높이고자 할 때에는 다음에 유의한다.
• 동일한 상품에서 변경된 부분을 테스트한다.
• 일반기능보다 핵심기능을 먼저 테스트한다. 상품이 동작하기 위해 중요한, 널리 사용되는 기능을 테스트한다.
• 신뢰성보다 우선적으로 기능성을 테스트한다. 다양한 조건에서 특정기능을 얼마나 잘 수행하는지 자세히 살펴보기 전에 우선 동작부터 하는지 테스트한다.
• 발생가능성이 적은 위험보다 일반적인 위험에 대해 테스트한다.
• 사람들이 많은 관심을 가지는 영역부터 먼저 테스트한다.
- 품질은 개발자가 만드는 것이지 테스터가 만드는 것이 아니다.
페이스북이 별도 QA 조직을 운영하지 않는 것도 품질에 대한 이러한 철학을 반영한 것이다. 테스트를 통해 품질을 보증하려는 생각은 옳지 않다.
- 재현 불가능한 오류는 시한폭탄이 될 수 있다.
원인을 밝히기 힘들거나 재현이 힘든 오류를 가벼이 여겨서는 안 된다. 큰 사고로 이어질 가능성이 있기 때문에 해결 될 때까지 별도 목록으로 관리하여야 한다.
- 테스트 자동화에 유의한다.
• 테스트 자동화는 테스트 비용 절감보다 개발속도 향상을 목표로 적용한다.
• 100% 자동화를 맹신하지 말고 효과가 있는 선까지 적용한다.
• 테스트 시나리오가 우선이다. 자동화는 좋지 않은 테스트를 더욱 빨리 실행시켜준다.
• 자동화된 회귀테스트는 프로그램 변경, 작업자 변경 등으로 유지보수가 어렵다.
- 과거 결함 데이터를 분석한 체크리스트를 활용한다
같은 조직에서는 같은 산출물을 만들 때 유사한 결함이 발생하기 쉽다. 따라서 이전 프로젝트에서 발생한 결함의 유형을 정리하여 체크리스트로 만들면 유용하다.
- 도구를 활용하여 단순한 오류는 제거한다
코드 인스펙션 도구(예: SonarQube)를 활용하여 단순한 오류를 제거한다. 도구를 활용한 검토의 가장 큰 장점은 비용 대비 효율적이라는 것이다. 모든 결함을 발견하는 효과성의 측면에서는 도구를 활용한 검토활동이 매우 제한적이지만, 단순 오류는 도구를 활용하여 많이 제거할 수 있다.
- 개인보다는 결함에 집중한다
나쁜 것은 결함이지 사람이 아니다. 결함의 발생원인을 찾을 때 ‘누구 때문에’가 아니라 ‘무엇 때문에’에 집중해야 한다.
- 프로젝트 후반까지 남은 결함은 고치기 힘든 결함이다
사람들은 간단하고, 고치기 쉬운 결함부터 고치는 경향이 많다. 결함이 여러 파트와 관련되어 있고 수정하기 힘든 경우에는 차일피일 미루다가 후반부까지 가게 된다. 그렇게 미루다 보면 프로젝트 종료시점에 해결하기 어려운 결함들만 남아있는 경우가 많다. 결함수정에 필요한 시간을 충분히 확보하지 않으면 낭패를 보기 쉽다.
https://brunch.co.kr/@kbhpmp/160
