CTFL Mobile Tester Syllabus 제2장 테스트 계획과 설계

Certified Tester Foundation Level  Mobile Tester Syllabus

 

제2장 테스트 계획과 설계

 

2.1 기능 및 특성 식별
기능이 많은 모바일 디바이스를 테스트하기는 쉽지 않다. 따라서 테스팅 범위 내에 속하는 기능 
과 특성에 집중하는 것이 중요하다. 예를 들면, 신규 어플리케이션을 여러 종류의 스마트폰에 적 
용하는 것이 목표라면, 어플리케이션의 기능, 디바이스와 어플리케이션의 연동성 그리고 어플리케 
이션의 성공에 중요한 품질 특성（예: 사용성과 성능）에 집중해야 한다. 만약 새로운 스마트폰을 출 
시한다면 목표는 달라진다. 이 경우 테스터는 핸드폰의 자체 기능, 대표적인 어플리케이션 지원 
여부, 디바이스와 네트워크 사이의 통신 방식（WiFi, IP-over-USB 등） 그리고 기타 다양한 품질 특 
성에 집중해야 한다. 이 실라버스는 디바이스 자체보다는 모바일 어플리케이션 테스팅에 초점을 
두고 있다.
요구사항은 비교적 간소한 경우가 많다. 사양서, 요구사항 문서, 유즈 케이스 또는 유저 스토리 등 
의 형태를 보여준다. 일반적으로 테스터는 포괄적인 요구사항을 기대하기보다는 사용 시나리오를 
식별할 수 있는 유즈케이스를 활용해서 테스트할 수 있도록 계획해야 한다. 만일 이용 가능한 유 
즈케이스가 없다면 테스터는 유즈케이스를 찾아내어 예상되는 사용방법을 파악하고, 그에 따라 
테스팅을 계획해야 한다.
테스트 범위를 선정하기 위해 테스터는 사용자가 가장 중요하게 여기는 어플리케이션의 특성을 
이해하고 그에 따라 테스트 대상 특성의 적절한 우선순위를 선정하는 것이 중요하다. 만약 사용 
성보다 보안과 성능이 더 중요하다면, 이를 고려해 리스크를 식별하고 각 분야에서 필요한 테스 
팅의 강도와 유형을 결정한다. 이해관계자는 각각의 특성 테스트를 위해서는 사람（필요한 기술을 
가진）과 도구 및 환경에 대해 투자가 필요하다는 것을 이해해야 한다.

 

2.2 리스크 식별 및 평가
안전 최우선(Safety-critical) 또는 과업 최우선(Mission-critical)이 아닌 모바일 어플리케이션은 일반 
적으로 기능이 많은 반면 그 기능의 구현 및 테스팅에 사용할 수 있는 시간은 많지 않다는 특징 
을 가진다. 요구사항은 간단하고 비공식적인 경향이 있으며 따라서 리스크를 식별하고 평가하는 
과정도 간단해야 한다. 이를 위한 한 가지 방법은 어플리케이션을 물리적 역량과 기능적 역량으 
로 나누어서 접근하는 것이다.
물리적 역량이란 사용자가 물리적으로 터치하는 장치(예: 버튼, 아이콘, 디스플레이, 그래픽)와 사 
용자가 사용하는 디바이스의 물리적 기능(예: 회전과 가속도계) 등을 말한다. 이러한 역량은 그 자 
체로 기능은 아니지만 어플리케이션의 기능을 사용 가능하게 한다. 이러한 역량을 식별한 후, 각 
역량의 범주(예: 디스플레이)를 나열하는 목록을 작성하고 사용자 관점에서 각 역량의 중요도를 
심각, 높음, 중간, 낮음으로 구분한다.
예: 일반적인 환경에서 이미지를 완전히 로딩하는 것이 심각 등급이라면 수용할 수 있는 수준의 
해상도는 높음 등급, 이미지 로딩 중단 시 재시도 없이 한 번에 로딩하는 것은 중간 등급, 그리고 
접속이 끊어졌을 때 재시도하여 로딩하는 기능은 낮음 등급으로 구분할 수 있다. 유사한 예로, 디 
바이스를 회전시킬 때 이미지가 회전하는 기능은 심각 등급, 회전 시 크기 자동 조절 기능은 높 
음 등급, 이미지와 텍스트가 함께 회전하는 것은 중간 등급으로 구분할 수 있다.
기능적 역량을 평가하기 위해서는 SW의 목적을 고려해야 한다. 한 예로 네비게이션 어플리케이 
션에서 정확하게 지도를 불러오는 것을 생각해 보자. 이 경우 정확하게 지도를 불러오는 것은 심 
각 등급, 차량 위치를 지도에 표시하는 것은 높음 등급, 지도에 주유소를 표시하는 것이 중간 등 
급, 공사 중인 지역을 표시하는 것은 낮음 등급으로 구분할 수 있다.
이러한 가벼운 접근법(lighter-weight approach)은 테스터로 하여금 실제의 디바이스나 시뮬 레이 
터로 테스트해야 할 디바이스의 물리적 특성뿐만 아니라 사용자가 중요하게 생각하는 기능도 이 
해할 수 있게 한다. 이러한 유형의 스프레드시트를 가지고 작업함으로써 테스터는 빠져있던 요구 
사항을 발견하거나 문서화되지 않았지만 구현된 기능 등을 발견할 수 있다.
리스크 분석을 위한 가벼운 접근법의 예는 여러 자료를 통해 찾아볼 수 있다. 전통적인 리스크 
분석 접근법 역시 모바일 테스팅에 보다 잘 맞게 경량화하여 사용할 수 있다.

 

테스터가 프로젝트 일정에 맞게 리스크를 식별하고 평가하는 것은 중요하다. 무거운（신축성이 부 
족한） 리스크 분석법은 짧은 프로젝트 일정을 맞추지 못하고 테스팅을 지연시키기 쉽다.
생산 메트릭 또한 리스크 영역확인에 도움이 되며 다음과 같은 메트릭을 사용할 수 있다 

• 다운로드 총 수 - 어플리케이션에 대한 관심도（동시 사용자 수의 최대치를 제공함）
• 어플리케이션 사용자 수 - 어플리케이션 실 사용자 수（다운로드 후 사용하지 않는 수 
제외됨）
• 실사용자 비율 - 다운로드 총 수에 대한 어플리케이션 실 사용자 수의 비율
• 신규 사용자 - 일정 기간 내 어플리케이션을 처음 사용하는 사용자 수（특히 실사용자 
비율로 알 수 있는 감소하는 사용자 비율과 비교할 때 유용함）
• 방문 빈도 수 - 일정 기간 내 사용자의 수에 대한 방문 횟수 비율（사용자 충성도 측정）
• 방문 깊이 - 어플리케이션 사용 시 평균 방문 화면 수
• 지속 기간 - 어플리케이션 사용 시 평균 사용 시간
• 이탈를 - 일회 방문 사용자 비율（어플리케이션 다운로드 및 접속 후 다시 사용하지 않는 
사용자）
이러한 메트릭을 이용해 테스팅 또는 개발 시 고려해야 할 높은 리스크 영역을 식별할 수 있다.
예를 들어 이탈률이 높다면 사용성 문제가 있다는 것을 나타내는 것일 수 있다. 또한, 실사용자 
비율을 이용해 현실적인 성능 테스팅 목표를 정할 수 있다.

 

2.3 커버리지 목표 결정
리스크를 식별 및 평가하고 나면, 커버리지 목표를 결정해야 한다. 결정 과정에 테스트 매니저 등 
다른 사람들의 의견을 반영하는 것도 중요하지만, 테스터는 테스트 범위를 모두 고려해서 커버리 
지 목표가 현실적이고 프로젝트 테스팅 목표를 달성할 수 있을지 등에 대해 팀 내에서 동의를 얻 
어야 한다.
프로젝트 테스팅 시작 전 다음 항목들을 고려하여 바람직한 커버리지를 결정한다:

• 요구사항 - 요구사항이 정의되어 있는 경우, 요구사항 커버리지를 테스팅 가이드라인의 
하나로 사용해야 한다. 테스트 케이스와 요구사항 간의 추적성이 유용한 이유는 모바일 
어플리케이션의 경우 새로운 기능이 추가되거나 기존의 기능이 업데이트 혹은 수정될 
경우가 많은데, 그럴 경우 요구사항이 변하기 때문이다. 요구사항 변경이 발생했을 때 
이러한 테스트 케이스와 요구사항 간의 추적성을 활용해서 테스터는 재실행이 필요한 
테스트 케이스를 파악할 수 있다

• 리스크 - 식별된 리스크는 테스팅되어야 하며, 테스트 케이스와 리스크 아이템 간의 
추적성이 필요할 수 있다

• 기능 - SW 기능 자체도 테스트되어야 하지만 그와는 별도로 관련된 리스크를 검증하기 
위해 기능이 다시 테스트될 수 있다. 모든 기능이 나열된 목록을 작성해 두면 리스크 
레벨을 확정하고 각 기능에 대한 테스트 커버리지를 추적하는 데 도움이 된다

• 코드 - 모바일 어플리케이션을 빠르게 개발해야 하므로 단위 테스팅은 매우 중요하며 
개발이 시작되기 전에 코드 커버리지 목표를 결정해야 한다. 자동화된 단위 테스팅은 
차후 업데이트 때마다 별도의 추가 인력 및 수동 테스팅 시간 없이 동일한 테스트를 
실행할 수 있도록 함으로써 업데이트의 품질을 향상하는 데 도움이 된다. 또한 자동화된 
단위 테스팅을 지속적 통합 및 개발（Continuous Integration and Development）과 함께 
사용할 경우 그 효과는 더욱 극대화된다. 결함 메트릭 및 기술적 부채（Technical debt） 
측정치는 SW 품질을 추적하는 데 사용될 수 있다

• 디바이스 - 디바이스 커버리지는 프로젝트 시작 단계에서 반드시 결정해야 한다.
그래야만 해당 디바이스를 확보하거나 시뮬레이터를 구매 또는 제작할지 결정할 수 있다.
개발자는 디바이스 별로 예상되는 특성에 대한 의견을 제공해야 한다. 이러한 의견이 
있어야만 다양한 특성을 가지는 디바이스 중에 어떤 것을 대표로 선정할지에 대한 올바른 
결정을 내릴 수 있다. 디바이스 기반 어플리케이션어플리케이션 테스팅은 특정 어플리케이션이 어떤 
디바이스에서 사용될지를 예상하고 그 우선순위를 정한다. 모든 디바이스（또는 그러한 
디바이스를 대체할 무언가）에 모든 테스트 케이스를 실행하는 것은 불가능하므로 사용 
가능한 디바이스에 테스트 케이스를 적절히 배분하는 것은 중요한 리스크 완화 활동이다

• 통신 - 디바이스의 인터넷 통신 방식（이동 통신, WiFi, Ethernet, 또는 복합적인 방식）에 
대한 커버리지도 필요하다. 또한 모든 부가 서비스（예: 스타일 시트 로딩）에 대한 엑세스 

그리고 대기 시간(Latency), 혼선(Jitter) 및 재시도(Re-tries) 등과 같은 네트워크의 잠재적 
부작용도 커버리지에 포함되어야 한다

• 지리적 위치 - 어플리케이션이 사용될 것으로 예상되는 지리적 위치도 테스팅에 영향을 
미친다. 만일 어플리케이션이 높은 고도에서만 사용될 것으로 예상한다면 그런 점을 
테스트 환경으로 고려해야 한다. 자주 끊어지거나 느린 네트워크 상황에서도 반드시 
동작해야 하는 디바이스에 대한 테스트와 신뢰성이 높고 빠른 네트워크를 갖춘 
사무실에서만 사용되는 디바이스에 대한 테스트는 다르게 접근할 필요가 있다

• 사용자 관점 - 좋은 테스트 케이스 설계를 위해 사용자의 기대, 지식, 역량, 인격 그리고 
운영 프로파일(사용자가 할 것으로 예상되는 행동) 등을 알아야 한다. 테스팅은 다양한 
사용자의 사용 방법을 시물레이션 해야 한다
테스팅 커버리지 요구사항을 이해하는 것은 테스팅 노력의 범위와 일정을 결정하고 테스트에 필 
요한 장비와 환경을 선정하는데 중요하다.

 

2.4 테스트 접근법 결정
커버리지 목표가 정의되고 나면 적절한 테스트 접근법을 결정할 수 있다. 테스트 접근법 결정 시 
에는 아래 사항을 고려해야 한다:

• 환경 - 테스트는 특정 환경에서 실행해야 하며 그러한 테스트 환경에는 고려해야 할 관련 
조건（예: 비가 오는 야외）이 있다
• 사람 - 제품은 특정 사용자 유형（그룹）을 위해 개발된다. 해당 유형의 사용자가 가지는 
특성을 테스트 케이스에 반영해야 한다（예: 시력이 나쁜 사람은 그림이나 사진을 볼 때 
항상 확대해서 본다）
• 산업 분야별 정황 - 테스트 접근법 결정 시 해당 산업 분야의 요구를 고려한다（예: 안전 
최우선（safety-critical 과업 최우선（mission- critical）, COTS(Commercial Off-the-Shelf;상용제품), 게임, 비즈니스 어플리케이션, SNS）
• 일정 - 테스트 접근법 결정 시 현실적인 일정을 고려해야 하며, 우선순위가 높은（리스크가 
높은） 테스트를 먼저 실행하도록 계획한다
• 범위 - 달성할 커버리지와 리스크 완화 목표를 분명히 할 수 있도록 테스트 범위는 
제한해야 하고 명확하게 표시해야 한다
• 테스트 결과 평가（판정） - 모바일 프로젝트의 경우 안전 최우선（safety-critical） 테스트 
케이스를 제외한 대부분의 테스팅이 구조화가 덜된 기법을 사용하여 시뮬레이터와 
에뮬레이터를 가지고 실행하므로 테스트 결과 평가는 기존 전통적인 프로젝트와는 다르게 
이루어진다. 테스트 결과 평가 방법을 명확하게 제시하고 모든 팀원이 정확하게 
이해함으로써 테스트 상태 보고서와 최종 테스트 요약 보고서를 모두가 이해할 수 있도록 
한다
• 테스트 방법 - 테스팅 방법은 모바일 프로젝트에 따라 다르다.
프로젝트의 공식성과 중요도에 따라, 테스트 접근법은 전통적인 테스트 계획서의 형태로 기록하 
거나 간단한 프로젝트 문서 같은 비공식적 형태로 기록할 수 있다. 어느 방법을 택하든 프로젝트 
팀이 테스트 접근법에 합의하는 것이 중요하므로 테스트 접근은 문서화해야 한다.

 

2.5 테스트 컨디션 식별 및 범위 설정
테스트 컨디션은 모바일 어플리케이션 프로젝트에서 실행할 테스팅을 위한 기본 요소이다. 빠르 
게 진행되는 프로젝트에서는 테스트 케이스를 작성할 수 있는 시간이 부족할 수 있으므로, 테스 
트 컨디션을 확인하고 리스크를 기반으로 각 컨디션의 우선순위를 할당하여 확인된 각 컨디션을 
다루는 테스팅을 실행하는 것이 제한된 시간 내에 테스팅하는 가장 효율적인 방법일 수 있다.
테스트 컨디션은 SW와 관련된 디바이스의 물리적 역량（예: 버튼, 아이콘, 화면 확대, 디바이스 회 
전, 위치 정보）과 어플리케이션의 기능（예: 그림 출력, 지도 표시, 은행 잔고 조회） 그리고 성능과 
사용 가능성과 같은 비기능적 분야로 구성된다. 이러한 역량과 각각의 특성들은 테스트해야 할 
수많은 컨디션들을 가지고 있다. 리스크 평가를 통해 이러한 컨디션의 테스팅 우선순위를 정할 
수 있으며 테스팅의 범위도 정할 수 있다. 예를 들면, 인터넷뱅킹 어플리케이션은 로그인 기능을 
가지고 있으며, 이 로그인 기능을 테스트하기 위해 테스터는 정상 아이디/정상 패스워드, 비정상 
아이디/정상 패스워드, 정상 아이디/비정상 패스워드 등을 테스트할 필요가 있다. 이러한 각각의 
조합이 테스트 컨디션이다.
SW 하나의 기능에 대해 다양한 테스트 컨디션들이 있을 수 있기 때문에, 중요하면서 리스크가 
높은 컨디션을 찾아내 테스트해야 한다. 리스크가 낮은 컨디션은 테스트하지 않거나 다른 테스트 
케이스와 함께 테스트할 수도 있다.
테스트 컨디션을 확인하고 우선순위를 결정하면 테스팅 범위가 결정된다. 우선순위/리스크 기반 
테스팅은 제한된 시간 내에 가장 중요한 컨디션을 특정 수준의 커버리지로 테스트한다는 것을 보 
장할 수 있다. 시간이 다 경과되고 확보한 커버리지가 충분하다고 판단되면 테스팅을 종료한다.

 

2.6 리그레션 테스팅
모바일 어플리케이션에 대한 리그레션 테스팅은 특히 어려움이 많다. SW（펌웨어 포함）도 빠르게 
변하지만 디바이스도 계속 변하기 때문이다. 더 많은 디바이스를 지원할수록 변화의 폭은 커진다.
어플리케이션 자체는 변하지 않더라도 모바일 어플리케이션에 대해서는 주기적으로 리그레션 테 
스팅을 실행해야 한다.
이 실라버스에서 계속 설명하듯이 테스트 자동화, 디바이스 랩 그리고 시뮬레이터가 있다는 것은 
성공적인 모바일 어플리케이션 프로젝트에 매우 중요하며 성공적인 리그레션 테스트 실행을 위해 
서도 필요하다. 리그레션 테스팅이 자동화되고 디바이스 사용이 가능하다면（랩 또는 시뮬레이터를 
통해） 정기적으로（예: 일주일에 1회） 리그레션 테스팅을 실행하도록 계획할 수 있다.
이렇게 하려면 테스트 디바이스와 시뮬레이터를 정기적으로 업데이트하여 리그레션 테스팅이 대 
상 디바이스에서 SW의 기능성을 반영하도록 해야 한다