CTFL Mobile Tester Syllabus 제3장 모바일 테스팅 품질 특성

Certified Tester Foundation Level  Mobile Tester Syllabus

 

제3장 모바일 테스팅 품질 특성

 

3.1 개요
다른 어플리케이션과 마찬가지로 모바일 어플리케이션에는 반드시 테스트해야 할 기능 및 비기능
품질 특성이 있다. ISTQB Foundation 실라버스 [ISTQB FL - SYL]에서 언급하는 모든 품질 특성을 적
용할 수 있지만, 이 실리버스에서는 특히 모바일 어플리케이션 테스팅에 필요한 주요 특성만 다
룬다. 모든 모바일 어플리케이션에 그러한 모든 특성을 적용할 순 없지만, 누락된 사항 없이 정확
하게 테스팅 우선순위를 정하기 위해 각각을 고려해야 한다.

 

3.2 기능 테스팅
3.2.1 개요
어플리케이션이 적절한 기능을 사용자에게 제공하는지를 평가할 수 있도록 기능 테스트를 설계한 
다. 기능 테스팅은 SW 동작을 테스트하는 것이다. 모바일 어플리케이션의 기능 테스트는 아래 특 
성들을 다룬다:
• 정확성（적합성, 정밀성）
• 보안성
• 상호운용성
다음은 이러한 각각의 특성들에 대한 설명이다:

3.2.2 정확성
정확성 테스팅은 SW가 사용자가 원하는 기능을 정확하게 제공하도록 보장하고（적합성）, 모든 데 
이터를 전달하는 등 정확하게 기능하도록（정밀성）하기 위해 수행한다. 가령, 역량이 있어도 그것이 
적절한 방법으로 전달되지 않는다면 제품을 사용할 수 없을 것이다. 예를 들면, 스마트폰 어플리 
케이션이 화면에 맞게 그림을 조절하지 못한다면 적합하지 못한 것이고, 그 어플리케이션이 그림 
을 조절할 수 있더라도 잘못된 그림이라면 그것은 정밀하지 못한 것이다.

3.2.3 보안성
보안 테스팅은 보안 테스트 전문가가 수행하는 것이 최선이지만 모든 테스터는 보안 취약점 및 
보안 테스팅이 커버해야 하는 영역을 어느 정도 알고 있어야 한다. 정적 및 동적 분석 도구 등 
보안 테스팅에 도움이 되는 도구도 있지만 바람직한 보안 테스팅을 위해서는 보안 이슈, 테스팅 
방법 및 도구에 대한 생생한 지식을 가지고 있어야 하며 보안 테스트 케이스 작성（경우에 따라 
코딩 포함）을 위한 기술적 역량도 필요하다.

3.2.3.1 모바일 테스팅의 보안성
모바일 어플리케이션은 전통적인 어플리케이션보다 보안에 더 취약하다. 보안 테스팅을 계획하거 
나 테스트 대상을 선택할 때 다음 사항을 고려해야 한다:
• 일반적으로 모바일 어플리케이션은 기존 어플리케이션보다 해커의 공격을 받기 쉽다. 그 
이유 중 하나는 모바일 어플리케이션이 공개 네트워크에 접속되어 장시간 사용되기
때문이고, 또 다른 이유는 사용자가 디바이스에 설치된 다른 어플리케이션에게 영향을 줄 
수 있는 잠재적 취약점을 가진 많은 어플리케이션을 다운로드하기 때문이다

 

사람들은 너무 믿는 경향이 있다. 출처가 불분명한 이메일 첨부 파일은 절대 열지 않지만,
어플리케이션은 의심없이 다운로드하는 경향이 있다. 스마트폰이나 태블릿과 같은 모바일 
디바이스는 편리하고 항상 사용할 수 있기 때문에 사람들은 다량의 개인 정보를 거기에 
보관한다. 책상 위에 있는 노트에 패스워드를 따로 메모하기보다는 디바이스 자체의 
메모장 어플리케이션에 패스워드를 저장한다

• 디바이스는 분실할 수 있다. 사람들은 모바일 디바이스를 자주 분실하곤 한다. 이럴 경우 
그 디바이스는 잘못 사용될 수 있다. 특히 보안이라곤 짧은 패스워드나 간단한 패턴만이 
전부일 경우 그럴 가능성은 더욱 커진다

• 기부, 판매, 교환되는 모바일 디바이스의 기존 데이터를 지우지 않는 경우도 많다. 이런 
경우 수령인이 패스워드, 사용자 이름, 사진, 동영상, 연락처 정보(예: 이름, 전화번호,
이메일 등)와 같은 모든 유형의 사용자 데이터를 얻을 수 있다
사용자의 부족한 보안지식을 보완할 수 있도록 모바일 어플리케이션을 개발하는 것은 중요하다.
보안을 위한 대비가 되어 있으며 관련 기능이 올바르게 동작한다는 것을 보장하는 것이 모바일 
어플리케이션 테스팅에서 중요하다. 테스터는 패스워드나 계정 정보와 같은 민감한 정보가 보호 
되지 않은 상태로 디바이스에 저장되지 않는지 확인할 필요가 있다. 악성 코드(적대적 또는 침입 
적 SW)는 항상 존재하므로, 어플리케이션은 악의적 공격으로부터 스스로를 방어해야 하며 디바이 
스는 설치된 어플리케이션을 검증할 수 있는 보호 기능을 스스로 갖춰야 한다.
다음은 [OWASP - Open Web Application Security Project]에서 게시한 2014년 모바일 보안 위험 
상위 1◦개 목록이다. 이 목록은 매년 업데이트된다:
• 서버 제어 취약점 (Weak server side controls)
• 데이터 저장소 불안전성 (Insecure data storage)
• 불충분한 전송 레이어 보호 (Insufficient transport layer protection)
• 의도치 않은 데이터 노출 (Unintended data leakage)
• 미흡한 인증 및 허가 (Poor authorization and authentication)
• 공개된 암호화 기법 (Broken cryptography)
• 클라이언트에서 주입되는 원치 않는 기능 (Client side injection)
• 신뢰성 없는 입력에 의한 보안 처리(Security decisions via untrusted inputs)
• 부적절한 세션 관리 (Improper session handling)
• 바이너리 보안 미흡 (Lack of binary protections)
보안 위협에는 어떤 것들이 있는지 아는 것은 테스터에겐 무엇을 테스트할지를 알려주고 개발자 
에겐 코딩 시 주의해야 할 사항을 알려 준다.

 

 

3.2.3.2 보안 테스팅 접근법
보안 테스팅은 주로 보안 테스팅 전문가가 수행하기 때문에, 테스터는 보안 테스팅의 시작과 완 
료 방법을 정확하게 알 필요가 없을 수도 있다. 그러나 테스터가 테스팅 중 기본적인 부분은 검 
증하는 것이 중요하며 보안 테스팅에는 아래 사항을 포함해야 한다:
• 접근 통제 - 사용자와 어플리케이션 권한이 있는 경우에는 접근할 수 있으나, 권한이 
없는 경우에는 접근이 거절되도록 한다. 사용자가 접근할 수 있는 기능과 데이터에게만 
접근을 허용하는지 또한 확인한다. 즉, 모바일이 아닌 일반적인 어플리케이션에서의 접근 
보안과 유사하다
• 디바이스에 저장된 데이터 보호 - 디바이스에 데이터를 저장할 때 안전하게 처리해야 
한다. 거래에 사용되는 패스워드, 계정 정보, 신용 카드 정보 등을 거래 처리 중에라도 
접근 가능한 형태로 디바이스에 저장하면 안 된다
• 전송 중인 데이터 보호 - 정보는 네트워크（예: 이동통신, Wi-Fi）를 통해 디바이스와 서버 
간에 전송되며 디바이스（Wi-Fi, 블루투스, SMS） 간에도 전송된다. 안전하게 처리해야 할 
모든 데이터는 전송 도중에 가로채이거나 악용되지 않도록 반드시 암호화한다. 이는 
장애가 발생한 거래나 재시도 거래에도 적용된다
• 보안 정책 - 조직에는 데이터를 어떻게 처리할지, 누가 데이터에 접근 가능한지를 명시한 
보안 정책이 따로 있을 수 있다. 디바이스에서 데이터를 전송/수신하거나 디바이스에 
데이터를 저장하는 경우, 이러한 정책은 모바일 어플리케이션에도 다른 어플리케이션과 
마찬가지로 적용되어야 한다
다른 테스팅의 경우와 마찬가지로, 보안 테스팅의 경우에도 어플리케이션의 특성과 그 용도를 이
해하는 것이 중요하다. 은행 어플리케이션에 대한 보안은 메모리 게임 어플리케이션에 대한 보안
이나 그 중요도와는 다르다.

3.2.4 상호운용성
모바일 어플리케이션이 다른 구성 요소, 디바이스 및 시스템과 정상적으로 상호작용을 하는지 확 
인하기 위해 상호운용성을 테스트해야 한다. 모바일 어플리케이션은 정보와 이미지를 다른 SW와 
교환할 수 있어야 한다. 예를 들어, 스마트폰 카메라로 찍은 사진을 스마트폰에 설치된 이메일 어 
플리케이션을 통해 전송할 수 있다.
상호운용성 테스팅은 테스트 대상 어플리케이션의 상호작용 및 기능에 크게 의존한다. 정보（예:
게임의 최고 점수, 실시간 날씨 예보） 저장소가 있는 웹 서버로 데이터를 전송하는 어플리케이션 
을 최소한의 예로 들 수 있다. 어플리케이션은 보통 단독으로 실행되기도 하고 같은 디바이스에 
실행되고 있는 다른 어플리케이션들과 함께 실행되기도 한다. 디바이스에 새로운 어플리케이션을 
언제든지 추가할 수 있기 때문에 상호 연동하는 모든 어플리케이션을 테스트하는 건 불가능하다.

 

따라서 짧은 시간 내에 지나치게 많은 테스트를 실행해야 할 때 경량화된 방법을 사용하는 리스 
크 기반 접근법을 적용하는 것이 좋다.
상호운용성 테스팅은 여러 환경하에서 어플리케이션의 호환성 검증으로 확장될 수 있다. 한 어플 
리케이션은 모두 다른 속도로 동작하는 다양한 디바이스에서 작동해야 한다. 이런 상호운용성 테 
스팅을 호환성 테스팅이라고도 한다. 모바일 어플리케이션과 모바일 웹 사이트의 호환성 테스트 
가 어려운 이유 중 하나는 각 어플리케이션과 디바이스 브랜드 및 유형이 지원하는 브라우저와 
버전의 수 때문이다. 어플리케이션이 동작할 대상 디바이스 목록을 알아야만 적절한 테스팅 메트 
릭스를 개발하고 조합 테스팅과 같은 기법을 사용하여 테스팅을 디바이스 간에 적절히 분배할 수 
있다. 웹 서버 로그와 웹 분석 및 마켓 분석（예: 아이튠즈와 구글 플레이 등） 정보를 이용하면 특 
정 디바이스/브라우저를 사용하는 특정 어플리케이션 사용자 비율과 같은 환경 설정 정보를 얻을 
수 있다.

3.2.4.1 디바이스 별 고려사항
모바일 디바이스는 다양하며 그 기능 또한 다양하다. 상호운용성 테스팅에 있어 필요한 사항 중 
하나는 디바이스 간 공통점과 차이점을 이해하는 것이다. 특정 버전의 디바이스는 어플리케이션 
의 기능 및 사용성에 영향을 미칠 수 있는 특성을 가질 수 있다. 예를 들면, 하나의 어플리케이션 
이 성능이 낮은（또는 메모리가 적은） 디바이스에서 실행되는 상황과 성능이 좋은 디바이스에서 실 
행되는 상황은 서로 다른 특성을 보일 수 있다. 눈부심 방지 화면보호필름은 특정 사용자 인터페 
이스 디자인을 파악하거나 사용하는데 어려움을 줄 수 있다.
이러한 디바이스 고유 특성 정보는 빠르게 변화하기 때문에 테스팅하기 직전에 확인해야 한다.
또한, 디바이스의 새로운 기능을 예상하여 해당 기능（예: 더 빠른 속도, 대용량 메모리, 운영 체제 
요구사항）이 널리 사용되기 전에 테스팅이 이루어지도록 해야 한다.

3.2.4.2 주변 장치 테스팅
디바이스에는 다양한 주변 장치가 부착되거나 내장되어 있을 수 있다. 대표적인 주변 장치로는 
스캐너, 카드 리더, 생체 인식장비（예: 지문 스캐너）, 카메라, 고도계, 마이크, 스피커 등이 있다. 만 
약 어플리케이션이 특정 주변 장치를 사용하거나 그 유무에 따라 영향을 받는다면, 그 어플리케 
이션에 대해서는 해당 주변 장치가 있는 상황과 주변 장치가 없는 상황 모두를 테스트해야 한다.
이는 시물레이터를 사용해 테스트한다 해도 마찬가지다. 주변 장치에 대해서도 시뮬레이터를 사 
용할 수 있기 때문이다. 그러나 주변 장치의 경우실제의 디바이스를 가지고 테스팅을 어느 정도 
는 진행할 필요가 있다.

 

3.2.4.3 디바이스의 차이점
모바일 디바이스는 각각 고유한 특성을 가진다. 같은 태블릿 군에 속한다 하더라도 차이가 있을 
수 있다. 예를 들면, 통신 프로토콜의 차이, 전송 정보 암호화 유무, 도킹 기능 및 정보 공유 기능 
유무 등 차이가 날 수 있다. 디바이스는 일정 거리 내에 위치한 같은 유형의 다른 디바이스를 인 
식할 수도 있다. 디바이스 간의 다양성과 공통점은 모두 테스트에 새로운 기회를 부여한다. 어플 
리케이션이 한 디바이스 또는 한 디바이스 군과 어떻게 상호 동작하는지, 그리고 디바이스 간의 
차이가 어플리케이션에 어떻게 영향을 미치는지 이해하는 것은 중요하다.
예를 들어, 디바이스가 어플리케이션에 위치 정보를 공유하고 그 어플리케이션은 그 위치 정보를 
다른 어플리케이션과 공유해서 근거리에 있는 유사 디바이스에서 실행 중인 또 다른 어플리케이 
션과 통신한다. 만약 한 디바이스는 위치 정보를 보호하지만 다른 디바이스는 보호하지 않는다면,
어떤 문제가 생길까?
더 많은 기능이 디바이스에 추가되고 새로운 디바이스가 더 많이 출시될 것이므로 이러한 차이가 
테스팅에 미치는 영향은 더욱더 커질 것이다.

3.2.5 테스트 설계
모바일 어플리케이션 테스트 설계 시 다음 사항을 고려해야 한다:
• 어플리케이션의 기능
• 디바이스의 기능
• 어플리케이션의 대상 산업 군 내에서의 리스크（예: 구급차에 의료 정보를 제공하는 모바일 
디바이스）
• 네트워크 접속성
• 운영 체제
• 소비 전력/배터리 수명
• 어플리케이션 유형（네이티브, 하이브리드 등）
어플리케이션의 기능은 요구사항, 유즈케이스, 요구명 세서 등에 명시하기도 하지만 어플리케이션 
에 대해 배우기 위해 실행하는 탐색적 테스팅을 통해 파악하기도 한다. 디바이스의 기능에 대해 
서는 문서화된 명세서를 읽거나 직접 디바이스를 사용해 보거나 디바이스를 잘 아는 다른 사람들 
과 대화함으로써 알아내야 한다. 특히 다른 조직에서 개발한 디바이스를 다룰 경우 더욱 그러하 
다. 모바일 어플리케이션 기능 외 디바이스 역량도 함께 고려해 테스트를 설계해야 한다.
대상 디바이스의 역량과 사양을 이해해야 한다. 특히 그 사양들이 어플리케이션에 의해 활용되는경우에는

더욱 그러하다. 다음은 고려해야 할 디바이스의 사양 중 일부이다. 이 목록은 계속 확장 
될 것이다.
• 화면 크기 및 해상도
• 위치 정보（디바이스의 지리적 위치 식별 역량）
• 통화 기능（전화기로 활용될 역량）
• 가속도계（세 축 기반 가속센서 - 우ᅵ/아래, 앞뒤, 좌우 - 게임 및 회전용）
• 자이로스코프（회전축 운동을 이용한 위치 및 방향 감지 센서）
• 자력계（자기장 방향 측정 - 나침반으로 활용）

예를 들면, 어플리케이션이 자력계를 사용할 경우 자력계가 없는 디바이스는 물론 다양한 유형의 
자력계를 가진 디바이스들에 대한 테스트 케이스를 설계할 필요가 있다.
기능과 더불어 어플리케이션 설치에 대한 내용도 테스트 설계에 포함해야 한다. 대부분의 어플리 
케이션을 무선（OTA: over-the-air）으로 설치할 수 있기 때문에 설치 중 재설치, 업그레이드 및 제거 
등의 상황에서 발생하는 방해 요소에 대한 테스트 케이스가 필요하다. 어플리케이션 설치에 권한 
과 결제가 필요하다면, 그 부분도 반드시 테스트해야 한다.

3.2.5.1 핵심 기초 기법 사용
기본적인 블랙박스 테스트 설계 기법은 ISTQB Foundation 실라버스 [ISTQB_FL_SYL]를 참고하고,
추가 설계 기법은 ISTQB Advanced Test Analyst 실라버스 [ISTQB_ATA_SYL]를 참고하면 된다. 이 
기법들은 모바일 어플리케이션 테스팅에 적용할 수 있으며, 어플리케이션과 디바이스 테스팅 모 
두에 유용하다. 이러한 기법을 적용함으로써 테스터는 원하는 테스트 커버리지를 달성하는 데 도 
움을 받을 수 있다. 아래에 이 기법들을 요약한다.

• 동등 분할（대） - 한 항목의 테스트 결과가 전체 클래스를 대표한다고 가정하여 동등 
처리에 기반하여 동등 클래스를 결정하고 각 클래스에서 한 항목을 테스트한다. 예를 
들면, 해상도가 동일한 모든 카메라는 동일한 품질의 이미지를 만들 것이라고 가정하는 
것이다
• 경계값 분석（BVA） - 입력 또는 출력 범위의 경계에 근거하여 테스트를 선택한다. 예를 
들면, 전화번호부 목록에 저장할 수 있는 최대 건수를 테스트하고, 0 개, 1 개, 그리고 최대 
건수 + 1 건을 테스트한다
• 결정 테이블 - 입력, 자극（원인）으로 인한 출력, 행동（효과）의 조합을 테스트한다. 예를 
들면, 이메일이 수신될 경우 설정된 사운드가 출력되는지 테스트한다

 

• 상태 전이 모델 - 컴포넌트 또는 시스템의 두 상태 사이의 전이를 테스트한다. 예를 들면,
외부 조도가 변함에 따라 디스플레이 밝기가 조절되는지 테스트한다
• 유즈케이스 - 주（메인） 시나리오와 모든 대체 시나리오를 테스트한다. 예를 들면,
배달원이 택배 배송 후 배송이 완료됐음을 기록하고 수취인의 서명을 받고 배송 위치를 
기록할 수 있는지 테스트한다
• 경험 기반 기법
• 탐색적 테스팅 - 어플리케이션에 대해 배우면서 테스트 설계와 실행을 동시에 
함으로써 테스트한다. 예: 신규 어플리케이션에 대해 테스트하는 경우 해당 
어플리케이션을 사용하여 하나의 과업을 완수하고 발견한 모든 결함을 
문서화한다
• 결함 공격 - 대상 SW 에서 예상할 수 있는 결함을 집중적으로 테스트한다. 예를 
들면, 통신 보안 취약점에 대해 집중적으로 테스트한다
• 결함 기반 기법 - 결함 분류 체계에 따라 구체적 결함 유형에 대해 테스트한다. 예를 
들면, 잘못된 입력을 어떻게 처리하는지 테스트한다
• 조합 기법 - 모델이 제공하는 정보를 기준으로 여러 특성의 상이한 조합에 대해 
테스트한다. 예를 들면, 어플리케이션 테스트의 기반이 되는 디바이스와 디바이스 기능의 
조합을 결정하기 위해 페어와이즈 테스팅을 사용한다
이러한 기법들 중의 몇 가지, 특히 상태 전이 모델은 디바이스와 SW의 상호작용을 테스팅하기 
적합하다. 반면 동등 분할과 조합 기법은 테스트를 관리 가능한 크기로 줄이는 데 도움을 준다.
경험 기반과 유즈케이스 테스팅은 테스터가 실사용법 및 시나리오에 집중하도록 한다.

3.2.5.2 모바일 특화 기법 사용
위에서 언급한 기법 외에 모바일 어플리케이션을 테스트하는 데 흔히 사용되는 다른 기법들도 있 
다. 여기 목록과 위에서 언급한 목록은 일부 중첩되지만 적용할 기법의 가장 좋은 조합은 어플리 
케이션의 기능, 어플리케이션과 상호작용하는 디바이스의 역량, 어플리케이션 중요도, 가용 시간,
그리고 테스터의 기술/지식을 고려해서 결정해야 한다.
다음은 모바일 어플리케이션 테스팅에 일반적으로 사용되는 기법이다.
세션 기반 - 테스팅 세션은 처음부터 끝까지 방해 받지 않고, 다른 테스터나 관리자에 의해 검토 
가능하며, 테스팅의 목표에 집중할 수 있도록 설계되었다.
탐색적 테스팅은 다양한 사용자 관점의 탐색 개념으로 확장할 수 있다. 사용자 층은 매우 다양하 
기 때문에 이러한 사용자들이 디바이스를 사용할 때 가질 수 있는 다양한 관점들을 고려하는 것 
이 중요하다. 목적은 실제 사용을 모의 실험해 보는 한편 SW의 특정 측면 및 SW와 디바이스 
의 상호작용에 집중하는 것이며 아래와 같은 관점과 사용 시나리오를 포함해야 한다:

 

• 사용자의 기술 수준 （아래 퍼소나-기반 테스팅 참조）
• 사용자 위치 （예: 실내, 실오I, 가정, 직장, 자동차 안, 비행기 안）
• 주변 환경 조도 （예: 어두운, 밝은 햇빛 아래）
• 기상 조건 （예: 비, 바람）
• 접속 상태 （예: 강한, 약한, 간헐적）
• 사용 가능한 보조 디바이스 （예: 각각의 상호작용）
• 동작 （예: 안정된, 걷는 동안 손안에）

유즈케이스 테스팅과 유사하게 시나리오 기반 테스팅은 사용자가 하나의 작업 수행을 위해 따를 
가능성이 있는 경로를 테스트한다. 시나리오의 타당성은 테스트의 효과성에 직접적으로 영향을 
미친다. 사용자가 따르지 않을 시나리오의 테스팅은 시간 낭비일 수 있으며, 오히려 빈번히 사용 
될 경로의 테스팅에 집중할 시간을 뺏는 것일 수 있다.
사용자는 아주 다양하기 때문에 SW를 사용할 여러 유형의 사람들을 고려하여야 한다. 사용자들 
은 기술, 역량 그리고 욕구 측면에서 아주 다양하다. 아래 목록은 사용자 기반 테스팅에서 사용할 
수 있는 퍼소나 목록의 일부이다.

• 처음 사용자
• 일반적인 사용자
• 빈번한 사용자
• 전문 사용자
• 혼란스러운 사용자 （SW 를 이해하지 못함）
• 화난 사용자
• 겁 먹은 사용자 （기술을 두려워함）
• 참을성 없는 사용자
• 악의적 사용자
• 즐기는 사용자 （SW 를 통한 경험을 즐김）
• 기술적 지식이 있는 사용자
• 특정 연령대 사용자 （예: 65 세 이상）

퍼소나-기반 테스팅에서 테스터는 사용자의 관점을 이해하고 해당 사용자처럼 SW와 상호작용할 
수 있어야 하며 이것은 쉽지 않은 일이다. 특히 테스트 대상 퍼소나보다 테스터의 지식수준이 매 
우 높을 경우 그렇다. 좋은 사용성 요구사항은 다양한 퍼소나 요구사항을 수용하기 위해 필요한 
SW 특성을 다룰 수 있게 도움을 준다.
디바이스와 어플리케이션의 용도는 매우 다양할 수 있기 때문에 요구사항으로부터 독립된 관점에 
서 테스팅에 접근하는 것도 종종 도움이 된다. 예를 들어, 테스트스토밍 （Teststorming™） [Rice]은 
브레인스토밍이나 마인드맵의 활용을 통해 테스트 케이스와 테스트 시나리오를 만드는 데에 활용된다. 

이 기법은 제품 설계와 개발 과정에서 고려하지 못한 SW의 새롭고 창조적인 사용 방법을 
테스터가 생각할 수 있게 해준다. 모바일 디바이스의 용도와 기능이 지속적으로 확장되고 있기 
때문에 테스트 케이스 작성을 위해 요구사항에 명시된 것을 넘어서는 앞선 생각이 요구된다.
다시 한번 되새기기 위한 혹은, 상기하기 위한 체크리스트는 모바일 어플리케이션 테스팅에서 테 
스터가 테스팅에 의해 SW의 모든 측면이 다루어지고 있음을 확인하는 데 도움을 준다. 모바일 
어플리케이션에 대한 요구사항 문서화가 간략해지는 경향이 있기 때문에 테스터는 이러한 문서를 
테스팅을 위한 유일한 지침으로 의존할 수 없게 되었다.

TestStorming-소프트웨어 테스트 설계에 대한 협업 접근법

TestStorming-소프트웨어 테스트 설계에 대한 협업 접근법

테스트 디자인에 접근하는 방법에는 여러 가지가 있습니다. 이러한 접근 방식은 검사 목록에서 테스트 조건을 결합하여 테스트 효율성을 극대화하는 매우 정확한 알고리즘에 이르기까지 다양합니다.

모바일 응용 프로그램, 복잡한 시스템 및 사이버 보안 테스트와 같은 테스트에는 창의성이 필요하고 많은 기능을 다루며 요구 사항 문서, 사용 사례 또는 사용자 사례에 설명 된 내용을 넘어서는 상황이 있습니다.

지난 30 년 이상 동안 다양한 테스트 설계 기법이 서적 및 교육 과정에서 설명되었습니다. 이러한 기술에는 경계 값 분석, 의사 결정 테이블, 요구 사항 기반 테스트 등이 포함됩니다. 이러한 각 접근 방식에는 장점과 단점이 있으므로 테스트 분석가는 특정 상황에서 사용되는 기술의 한계와 요구 사항을 완전히 이해해야합니다.

어떤 경우에는 테스트 설계 기술을 결합하여 더 높은 수준의 테스트 범위를 달성 할 수있을뿐만 아니라 테스트 할 소프트웨어에 대해 다른 각도 나 관점을 얻을 수 있습니다.

몇 년 동안 테스트 디자이너로서의 경험에서 배운 것은 테스트 디자인이 매우 미묘한 활동이라는 것입니다. 교과서 기법은 훌륭하고 필요하지만 기법이 적용되는 방식에 약간의 변화가있을 경우 테스트 효과에 큰 영향을 줄 수 있습니다. 이것이 테스트 설계 기법을 적용하는 방법에 대한 교육이 중요한 이유 중 하나입니다. 그러나 교육은 훌륭한 테스트 디자인의 출발점 일뿐입니다.

내가 관찰 한 또 다른 것은 여러 번 테스트 디자인이 한 사람에 의해 수행되어 문서 또는 다른 항목으로 작업한다는 것입니다. 이는 테스트 디자이너가 종종 고립 된 상태로 작업하고 있음을 의미합니다.

테스트 설계를 단독으로 수행하면 테스트해야 할 중요한 관점과 조건을 놓치기 쉽습니다. 테스트 설계에 대한 공동 접근 방식에는 많은 이점이 있습니다.

공유 문제 해결 능력
테스트 할 애플리케이션에 대한 지식 증가
테스트 디자인에 대한 지식과 경험 향상
테스트 디자인 활동에서 더 높은 수준의 소유권
테스트를 생성하는 방식에서 더 큰 창의력
테스트 우선 순위의 객관성 향상
프로젝트, 테스트 및 해결해야 할 문제에 대한 커뮤니케이션 향상
이 기사에서는 훌륭한 테스트를 신속하게 디자인하는 데있어 간단하고 효과적인 기법을 설명합니다. 이 기술은 테스트 디자인의 세계와 브레인 스토밍의 세계를 결합한 것이므로이 기술을 "TestStorming TM "이라고합니다.

과정

TestStorming이 복잡하거나 연약 할 필요는 없지만 좋은 출발을하는 데 도움이되는 몇 가지 주요 단계가 있습니다.

1 단계 – 입력 캡처 방법 결정

이 과정은 매우 쉬워 화이트 보드를 사용하기 만하면됩니다. 그러나 조직을 추가 할 수있는 마인드 매핑 도구와 세션에서 수집 된 정보를 배포하는 기능과 같은 훌륭한 도구가 있습니다.

그러한 도구 중 하나는 Mac과 Windows 환경 모두에서 잘 작동하는 오픈 소스 마인드 매핑 도구 인 FreeMind입니다 ( http://freemind.sourceforge.net/wiki/index.php/Main_Page ). 또 다른 무료 도구는 XMind ( https://www.xmind.net/ )입니다.

2 단계 – 세션 범위 정의

여기에는 세션에 소요되는 시간과 해결해야 할 기능 수가 포함됩니다.

3 단계 – 세션의 초점 정의

특정 초점을 맞추면 팀이 테스트에서 가치 나 중요성이 제한적인 영역으로 침입하는 것을 막을 수 있습니다. 예를 들어, TestStorming 세션의 초점은 모바일 장치의 보안 측면 일 수 있습니다. 실제로, 초점은 모바일 장치를 사용하여 안전한 주문 프로세스를위한 테스트를 설계하는 것입니다.

4 단계 – 리더 지정

리더가 없으면 세션은 비생산적인 토론으로 이어질 수 있습니다. 또한 리더는 몇 가지 초기 제안을 던져 아이디어의 "펌프를 프라이밍"해야 할 수도 있습니다. 때때로 세션이 중단 될 수 있습니다. 이를 위해서는 리더가 더 많은 아이디어를 얻기 위해 의견이나 아이디어를 주입해야합니다.

리더는 주제 지식과 테스트 지식을 가진 사람이어야합니다. 또한 리더는 역동적 인 그룹 토론을 촉진하고 분쟁을 중재하며 세션을 진행하는 방법을 알아야합니다.

5 단계 – 참가자 초대

리뷰 및 회고와 같은 다른 많은 활동과 마찬가지로 TestStorming 세션의 성공 여부는 회의실에있는 사람들의 품질에 달려 있습니다. 당신은 사람들을 원합니다 :

창의적 사상가
비판적 사상가
응용 프로그램 사용 방법에 대한 지식
응용 프로그램의 조직 목표에 대한 지식
다른 유형의 사용자에 대한 이해
테스트 디자인에 대한 지식
세션에서 다른 사람에게 예의
아이디어를 제공 할 수 있음
참가자를 식별하는 다른 방법은 다음과 같은 역할 별입니다.

테스터
개발자
사용자
6 단계 – 세션 실시

세션에서 다음을 포함하여 몇 가지 사항에 대해 설명합니다.

요구 사항, 사용 사례, 사용자 사례, 사용자 경험 및 응용 프로그램 자체와 같은 테스트 설계의 기초
알려진 위험
알려진 문제
과거 결함 경향
응용 프로그램의 특성 및 테스트 할 특정 기능
응용 프로그램 사용 방법의 컨텍스트
세션의 목적
배경을 이해하면 참가자는 테스트 디자인에 대한 아이디어를 제공합니다. 이것은 다양한 방법으로 수행 할 수 있습니다.

다음과 같은 문맥없는 질문에 답변 :
테스트해야 할 가장 중요한 것은 무엇입니까?
테스트해야 할 가장 중요한 것은 무엇입니까?
테스트 할 기능의 위험은 어디에 있습니까?
어떤 비정상적인 사건이 발생할 수 있습니까?
일반 사용자가 가장 일반적으로 수행하는 이벤트는 무엇입니까?
각 사람은 색인 카드에 "최고 5"테스트를 작성하며,이 테스트에서 리더는 테스트 할 조건 목록에 대한 입력으로 사용합니다.
라운드 로빈 형식으로 방을 돌아 다니면서 테스트 할 조건에 대한 제안을합니다. 이를 통해 사람들은 다른 사람들의 아이디어를 구축 할 수 있습니다.
브레인 스토밍의 기본 규칙 중 하나는 제안 된 아이디어를 제한하지 않는 것입니다. 이 규칙은 TestStorming에서도 준수됩니다. 목표는 테이블, 보드 또는 도구에 대한 아이디어를 얻는 것입니다. 그런 다음 세련 될 수 있습니다.

7 단계 – 테스트 필터링, 수정 및 결합

이것이 마법이 일어나는 곳입니다. 팀이 아이디어를 제공하고 입력 흐름이 느려진 것이 분명 해지면 리더는 팀에게 물러나서 아이디어를 살펴 보라고 요청합니다.

제안 된 테스트 아이디어에서 팀은 다음과 같은 범주로 구성합니다.

기능
위험
사용자 페르소나
분류 프로세스 중에 일부 테스트가 제거되고 다른 테스트가 결합 및 향상 될 수 있습니다.

내가 가장 좋아하는 테스트 디자인 방법 중 하나는 내가 "토글"조건이라고합니다. 예를 들어, 누군가 주문 하는 신규 고객 테스트를 제안 하는 경우 기존 고객이 주문 하는 테스트 조건을 작성하십시오 .

8 단계 – 세션 종료

세션이 끝나면 리더는 제안 된 테스트를 요약해야합니다. 시간을 위해, 각각의 모든 조건을 읽는 대신 요약이 가장 좋습니다. 화이트 보드 또는 플립 차트를 사용하여 아이디어를 포착하는 경우 팀 및 다른 사람들에게 전자 메일로 보내려면 사진을 찍습니다. 도구를 사용하면 차트를 편집 가능한 형식 또는 이미지 형식으로 저장하고 배포 할 수 있습니다.

9 단계 – 테스트 구체화

TestStorming 세션의 목적은 테스트 할 아이디어를 수집하고 해당 아이디어를 강력하고 효과적인 테스트로 사용 지점으로 가져 오는 것입니다.

다음 단계는 테스트 분석가가 훌륭한 아이디어를 취하고이를 강력한 테스트 설계에 사용할 때 세션 후에 발생합니다.

어떤 경우에는 TestStorming 세션의 출력이 좋은 테스트 조건 세트 일 수 있습니다. 다른 경우, 출력은 검사 목록이나 결함 분류 체계에서와 마찬가지로 테스트 할 좋은 아이디어 일 수 있습니다.

세션에서 얻은 세부 사항에 관계없이 아이디어 및 / 또는 조건은 예상 결과와 함께 실행 가능한 테스트 사례로 구성되어야합니다. 경우에 따라 예상 결과를 정의 할 애플리케이션에 대해 충분히 알지 못할 수도 있습니다. 이 경우, 응용 프로그램 탐색을 시작하기위한 장소로 TestStorming 출력을 처리해야합니다.

10 단계 – 테스트 수행

주요 목표는 테스트에 대해 공동 작업을 수행하는 것이기 때문에 테스트가 효과적인 테스트인지 확인하는 방법은 실제로 테스트하는 것입니다. 주요 결정 요인은 테스트 통과 또는 실패 여부가 아니라 적용 범위를 제공하고 위험을 측정하며 간단한 기능 테스트를 넘어서는 방식으로 응용 프로그램을 실행하는 것입니까?

11 단계 – 필요에 따라 테스트 업데이트

테스트를 수행 한 후에는 향후주기에 테스트를 포함할지 여부를 알 수 있습니다. 아마도 특정 테스트를 기반으로 결정할 수도 있습니다. 실패를보다 효과적으로 찾기 위해 일부 테스트를 수정해야하는 위치도 볼 수 있습니다.

 

 

3.3 비기능 테스팅
비기능 테스팅은 기능이 사용자에게 전달되는 방법에 집중한다. 비기능 테스팅에 대한 더 자세한 
설명은 ISTQB Foundation 실라버스 [ISTQB_FL_SYL]에서 볼 수 있다. 이 장은 모바일 어플리케이션 
테스팅에서 가장 중요한 비기능 품질 특성에 집중한다.

3.3.1 성능 테스팅
일반적으로 성능 테스팅은 시스템에 특정 부하가 발생할 경우 시스템의 응답시간을 확인하는 것 
이다. 성능 테스팅은 또한 처리량과 자원 활용을 고려한다. 모바일 어플리케이션의 경우 성능 테 
스팅을 위해 네트워크 접속 유형 및 강도, 디바이스 유형, 디바이스 메모리 등 제어하기 어려울 
수 있는 조건을 고려해야 한다. 모바일 어플리케이션은 다양한 기능을 위해 사용되지만 일부 어 
플리케이션은 다른 어플리케이션들 보다 더 높은 성능 요구사항을 가지고 있다. 예를 들면, 운전 
방향 전송을 위해 디바이스의 지리적 위치를 사용하는 GPS 어플리케이션은 예정 경로의 변화를 
조정할 수 있도록 매우 높은 성능 요구사항을 가지고 있다. 주식 거래와 같이 시간이 중요한 거 
래에 사용되는 어플리케이션 역시 엄격한 성능 요구사항을 가지고 있다. 미디어를 제공하는 어플 
리케이션은 비디오 재생 중에 일시 정지 등의 문제가 없이 사용자에게 좋은 경험을 제공할 수 있 
는 정도의 성능을 일관되게 제공할 필요가 있다.

3.3.1.1 모바일 SW 성능 테스팅
모바일 어플리케이션 테스팅에서는 트래픽을 처리하는 서버의 역량을 검증하는 일반적인 성능 테 
스팅뿐만 아니라 [ISTQB_FL_SYL 참조] 추가적으로 고려해야 할 사항들이 있다. 네트워크 접속성은 
모바일 디바이스의 성능에 중요한 역할을 한다. 접속 속도, 접속 및 재접속에 필요한 시간, 그리 
고 네트워크 대기 시간과 같은 변수는 모두 바람직한 성능을 제공하기 위한 어플리케이션의 요소 
이다. 신뢰할 수 없거나 일관성 없는 네트워크 접속성은 어플리케이션이 원하는 데이터를 얻기 
위해 여러 번 재시도해야 하거나 일부 손실된 데이터를 이용해야 하는 결과로 이어질 수 있다.
손실된 데이터가 어플리케이션 작동을 위해 필수적인 정보일 경우 특히 위험성이 클 수 있다.
모바일 어플리케이션의 성능 테스팅은 어플리케이션 자체, 또는 나아가 어플리케이션과 서버의 
상호작용이 가능한 한 효율적임을 보장하는 것에서 시작한다. 느린 어플리케이션이나 서버로부터 
의 느린 응답은 어플리케이션이 모바일 디바이스에서 실행 중인 경우 훨씬 더 악화될 뿐이다. 모 
바일 어플리케이션 성능 테스팅은 일반적인 성능 테스트뿐만 아니라 어플리케이션의 다음과 같은 
측면을 포함해야 한다.

 

어플리케이션 시작 시간 - 어플리케이션을 사용하기 원한다는 사용자의 최초
의사표시로부터 어플리케이션이 완전히 사용 가능해질 때까지의 시간

• 사용자 인터페이스 지연 - 어플리케이션이 사용자 상호작용（예: 버튼 누르기, 이미지 
이동）을 받는 순간에서부터 그에 대한 응답을 사용자에게 제공하기까지 소비된 시간
• 불규칙적 성과 - 동일한 유형의 입력에 대해 현저히 다른 성능을 보일 때의 문제
• 시각적 지표 - 모든 사용자 인터페이스의 경우처럼 '처리 중이므로 대기하라'는 정보를 
사용자에게 반드시 제공해야 한다. 이러한 정보는 일반적으로 일정한 대기 시간이 발생한 
후에 표시되기 때문에 성능이 저하된 경우에도 정보가 정확하게 표시되는지 확인하기 
위한 테스트를 해야 한다
• 자원 사용 - 모바일 어플리케이션은 자원 공유 환경에서 실행될 가능성이 크다. 그렇기 
때문에 CPU, 메모리, 배터리 등의 효율적 사용은 어플리케이션뿐만 아니라 디바이스 
전체를 위해 중요하다. 모바일 디바이스에서 하나의 어플리케이션만 실행되는 경우는 
매우 드물다. 성능은 실행 중일 것으로 예상되는 일련의 어플리케이션과 프로세스를 
감안해서 측정해야 한다. 이렇게 해야만 테스트 대상 어플리케이션을 실행할 때의 실제 
사용자 경험을 확인할 수 있다
• 작업 완료 - 사용성 테스팅, 성능 테스팅과 중복되는 부분이지만, 사용자가
어플리케이션을 사용해서 하려는 작업을 완료하는 데 소요되는 시간을 테스트하는 것은 
중요하다
• 코드 비효율성 - 모바일 어플리케이션의 코드는 일반적으로 그 규모가 작지만, 여전히 
코드에는 전체 성능에 영향을 미치는 병목（Bottleneck, 무한 루프 또는 다른 비효율적인 
부분이 있을 수 있다. 이러한 코드의 비효율성은 정적 분석（리뷰나 도구, 혹은 둘 다）이나 
동적 분석（도구 중심）으로 검출할 수 있다
이 외에도 웹 어플리케이션은 다음과 같은 부분에 대하여도 테스트해야 할 필요가 있다:
• 사이트 페이지 로딩 시간 - 모바일 어플리케이션이 웹 사이트 상에서 실행될 수 있기 
때문에 사이트 페이지를 로딩하는 데 걸리는 시간은 사용자의 어플리케이션 경험에 
상당한 영향을 미칠 수 있다
• 지연 - 지연은 여러 가지 이유로 발생할 수 있다. 서버 및 네트워크 시간과 연관된 
이유로 발생하는 경우도 많다
• 자원 활용 - 웹 어플리케이션이 사용하는 디바이스 메모리와 CPU 는 상대적으로 적을 
수도 있지만, 서버와 주고받는 양의 데이터가 많은 관계로 상대적으로 더 많은 네트워크 
대역폭을 필요로 할 수 있다

3.3.1.2 성능 테스팅 접근법
유효한 퍼소나를 식별하는 것은 성능 테스트와 사용성 테스트 모두에서 중요하다. 퍼소나(persona)는 사용 
자의 특성뿐만 아니라 사용자가 수행하려고 하는 작업을 정의한다. 이런 정보를 활용해서 일반적 
인 사용자 트랜잭션을 모의 실행할 수 있는 스크립트를 작성할 수 있다. 퍼소나는 자동화된 도구에 

의해 복제되어 일정한 방법을 통해 시스템과 상호작용하는 복수의 가상 사용자를 생성할 수 
있다. 실제 디바이스를 조달하기 어려울 수 있기 때문에, 디바이스 시뮬레이터가 테스트 중 디바 
이스와 동일한 상호작용을 제공하기 위해 흔히 사용된다.
성능 목표와 테스트 용이성 목표는 어플리케이션을 설계하고 대상 환경을 정의할 때 설정해야 한 
다. 이러한 목표는 테스팅의 실제 결과와 비교하기 위해 사용할 수 있다. 성능 테스팅은 개별 구 
성 요소가 사용 가능해질 경우 바로 시작할 수 있다. 어플리케이션이 개발 중일 때 성능 테스트 
를 구축, 실행함으로써 성능이 낮은 구성요소를 바로 바로 확인할 수 있다. 이러한 접근법은 지속 
적 통합 환경(CI;continuous integration)에서 특히 유용하다.
환경은 어플리케이션의 성능에 영향을 미친다. 좋지 않은 디자인, 높은 오버헤드(Overhead), 느린 
통신 속도 또는 기타 요인으로 인해 본질적으로 느린 디바이스는 어플리케이션이 낮은 성능을 내 
는 것처럼 보이게 한다. 시뮬레이터로 테스팅을 수행할 때는 확인된 성능이 실제 사용자가 실제 
디바이스를 통해 경험하게 될 성능을 반영하는지 확인하기 위해 실제 디바이스 상에서 일부 테스 
트를 수행해 볼 필요가 있다. 또한, 무엇이 테스트되고 있는지 이해하는 것도 중요하다. 사용자의 
디바이스에 들어갈 모바일 어플리케이션과 모바일 디바이스를 통해 접근하게 될 웹 어플리케이션 
의 성능 고려사항은 서로 다르다. 성능 테스트 설계 이전에 이러한 차이를 이해하면 유효한 결과 
와 테스팅 초점을 적절하게 잡는 데 도움이 된다.
전반적으로 낮은 성능은 사람들이 어플리케이션을 포기하게 하는 원인이 될 수 있다.
"느리다"의 기준은 사용자가 결정하고 사용자의 기대는 지속해서 바뀌기 때문에 어제의 빠른 성능이 내일은 
너무 느린 것이 될 수 있다.

3.3.2 사용성 테스팅
모바일 어플리케이션은 전통적인 어플리케이션보다 더 넓고 다양한 사용자 기반을 가지는 경향이 
있다. 이유 중 하나는 어플리케이션에 대한 접근이 용이하기 때문이고, 다른 하나는 어플리케이션 
은 언제 어디서나 사용 가능해야 한다는 생각 때문이다. 그러므로 사용성을 유심히 살펴볼 필요 
가 있으며, 특히 사용성 테스트를 계획하고 실행하는 사람은 더더욱 심각하게 받아들일 필요가 
있다.
3.3.2.1 모바일 SW 사용성 테스팅
네비게이션, 색상, 소리, 접근성 등과 같은 전통적인 사용성 분야 외에도 모바일 어플리케이션에 
서 테스팅해야할 추가적인 분야는 다음과 같다:

• 단순성 - 모바일 어플리케이션은 단순하고 사용하기 쉽게 설계되어야 한다

• 레이아웃 - 모바일 어플리케이션과의 상호작용은 때로는 전자 포인터 또는 펜과 같은 
디바이스를 통하기도 하지만, 대부분의 경우 손가락을 통해 이루어진다. 때문에 
어플리케이션에는 손가락 사용을 위한 공간이 있어야 하며, 또 텍스트 입력을 위한 
키보드를 표시할 수 있는 충분한 공간이 있어야 한다
• 직관성 - 사용자는 모바일 어플리케이션을 로딩 즉시 사용할 수 있기를 기대한다. 잠시 
동안은 시험 삼아 사용할 수도 있지만 어플리케이션이 사용하기 쉬운지 아닌지를 거의 
즉시 결정한다. 만약 사용이 어려운 경우, 대부분의 사용자는 어플리케이션을 바로 
삭제하고 대체할 수 있는 다른 것을 찾을 것이다. 만약 사용법을 사용자에게 제공한다면,
보이기는 하지만 강요하지는 않는 수준에서 이루어져야 한다
• 네비게이션 - 네비게이션은 전통 어플리케이션에서도 관심을 가져야 하는 부분이지만 
모바일 어플리케이션에서는 더욱 중요하다. 사용자는 다수의 선택지에서 자신의 경로를 
찾기보다는 자신이 가야 할 방향으로 인도해주길 기대한다. 모바일 어플리케이션은 
간단하고 찾기 쉽게 구성되어 있기를 기대한다
사용하기 어렵다고 판단될 경우 사용자는 해당 어플리케이션을 버리게 될 것이다. 이러한 경향은 
전통 어플리케이션에 서보다는 모바일 어플리케이션에서 더욱 크게 나타난다.

3.3.2.2 사용성 테스팅 접근법
성능 테스팅에서 언급한 바와 같이 퍼소나는 테스팅이 사용자 유형의 대표적인 집합을 모두 다루 
고 있음을 보장하기 위해 사용성 테스팅에 필요하다. 사용자란 단지 최종 사용자만을 의미하는 
것이 아님을 기억해야 한다. 어플리케이션은 때때로 기업의 매출을 증가시키는 데 사용된다. 만약 
특정 캠페인이 특정 회사의 모바일 어플리케이션에 사용된 경우, 그 회사의 영업 팀은 다운로드 
수, 응답 수 및 기타 정보에 관한 통계를 볼 필요가 있다.
사용자의 기대도 중요한 고려 사항이다. 더 많은 어플리케이션이 이용 가능해지고 새롭게 개선된 
디바이스가 등장하며 처리 속도가 향상되면서 사용자의 기대 수준 역시 변할 것으로 예상된다.
사용성 전문가는 제품의 사용성에 대한 시장의 새로운 기대를 충족시켜야 하는 도전에 직면하게 
될 것이다.
사용성 설계 및 테스팅을 시작할 때 실제 사용자가 필요하다. 사용자가 실제 어플리케이션을 사 
용하는 모습을 관찰하면 테스팅이 실제 다루어야 할 사용 시나리오나 인터페이스가 혼란스럽거나 
네비게이션이 불분명한 부분을 밝혀내는데 도움이 될 수 있다. 사용자의 피드백을 얻는 것이 가 
능한 상황이라면, 어플리케이션의 어떤 부분을 좋아하는지 또 개선이 필요하다고 생각하는 부분 
은 어디인지를 판단하는 데 도움을 얻을 수 있다. 사용성 랩과 설문 조사는 제어된 환경에서 이 
러한 정보를 얻는 데 도움이 될 수 있다.

 

그 외에 간단한 메트릭을 활용해서 사용성이란 주관적인 주제에 객관성을 부여할 수 있다. 다음 
과 같은 항목을 측정하면 사용성 요소들을 이해하는 데 도움이 될 수 있다.

• 완료한 작업 수
• 하나의 작업을 완료하는 데 걸린 시간
• 하나의 작업 또는 일련의 작업을 수행하면서 발생한 실수 횟수
• 작업을 수행하는 데 필요한 클릭（액션） 수

위와 같은 자료를 세 번에 걸쳐 측정함으로써 어플리케이션의 학습 용이성도 판단할 수 있을 것 
이다.
효과적인 사용성 테스팅은 소수의 인원으로 구성된 대표 사용자 그룹을 통해 이루어질 수 있다.

선택된 사용자 그룹이 요구되는 퍼소나와 잘 맞는다면, 어플리케이션을 개선하고 미래 
의 디자인을 향상하는 데 사용될 수 있는 유용한 피드백을 비교적 적은 비용으로 습득할 수 있다.
모바일 디바이스는 많은 사람이 사용하기 때문에 테스트 기간 동안 접근성도 반드시 고려되어야 
한다. 만약 특정 접근성 표준을 준수해야 한다면, 어플리케이션이 해당 표준을 준수하는지를 검사 
할 수 있는 도구를 사용하거나 표준 준수를 보장하는 데 필요한 수동 테스팅을 수행하는 것이 중 
요하다. 가독성, 색상 지원, 음성 지원 등과 입력, 화면 크기 조정, 색상 대비 변경과 같이 사람이 
수행하는 상호작용 모두가 고려되어야 할 접근성 항목이다. 또한, 밝은 햇살, 어두움, 비 등과 같 
은 환경적 변화 측면에서도 접근성을 고려할 필요가 있다.
모바일 디바이스는 다양한 기능을 가지는데, 그 중 일부는 모바일 디바이스 주변기기가 필요한 
경우도 있다. 주변기기로는 카메라, 스캐너, 신용카드 리더기, 헤드폰, 키보드 등이 있으며, 이런 
주변기기는 디바이스에 기본적으로 내장되어 있거나 탈부착이 가능한 형태로 제공되기도 한다.
어플리케이션을 테스트할 때 어플리케이션 자체나 어플리케이션이 공유하는 환경과 상호작용할 
수 있는 모든 기기를 고려해야 한다. 주변기기를 사용할 경우 동시처리도 고려해야 한다. 예를 들 
면, 신용 카드 판독기는 휴대 전화에서 실행 중인 은행 어플리케이션에 입력 데이터를 제공할 수 
있지만, 그 판독기를 카메라와 동시에 사용할 경우 작동하지 않을 수도 있다. 주변기기 간의 이러 
한 상호작용은 테스트 대상 디바이스 구성을 선택할 때 고려해야 한다.

3.3.3 이식성 테스팅
이식성 테스팅은 어플리케이션이 대상 환경으로 옮겨졌을 때 어플리케이션 기능이 얼마나 잘 동 
작할 것인지에 초점을 맞추고 있다. 좋은 이식성 테스팅을 하려면 대상 환경과 그 환경의 특성에 
대해 명확히 이해해야 한다.

 

3.3.3.1 모바일 SW 이식성 테스팅
모바일 SW는 모바일 디바이스에서 실행하기 위한 것이다. 디바이스는 다양하고 그 수, 유형, 기 
능은 계속 증가하고 있다. 모바일 테스팅은 일반적으로 테스트 대상 어플리케이션에 영향을 미칠 
수 있는 가장 공통적인 환경과 환경 변수를 다루기 위해 대표적인 디바이스들의 일부분에 집중한 
다. 좋은 이식성의 핵심은 좋은 설계이다. 디바이스 간의 차이 때문에 테스트가 필요한 영역을 결 
정할 때 테스터는 개발자와 함께 협의해야 한다. 예를 들면, 개발자는 일반적으로 어플리케이션이 
iOS와 안드로이드 디바이스 모두에서 동작하도록 필요한 수정 사항을 알고 있다. 그러나 또한 개 
발자는 종종 디바이스 간의, 그리고 유사한 디바이스의 다른 버전 간의 미묘한 차이를 놓칠 수 
있다. 유효한 대표 디바이스 세트를 얻기 위해서는 실제 디바이스를 조달하고 또 일부 디바이스 
를 위해서는 정확한 시뮬레이터를 사용해야 한다.

3.3.3.2 이식성 테스팅 접근법
사용자는 일반적으로 어플리케이션이 서로 다른 디바이스에서 작동하기 위해 수정이 필요하다는 
것을 인식하지 못한다. 그 결과 사용자는 모바일 어플리케이션이 여러 디바이스에서 작동할 것이 
고, 스마트폰, 태블릿, PC 브라우저 등에서 동일한 수준의 사용성을 제공할 것이라고 기대한다. 사 
용자가 그렇게 기대하는 것이 비현실적일 수 있지만, 테스터는 어떤 환경에서 어플리케이션이 제 
대로 작동하는지 확인할 임무가 있다.
현재를 대상으로 하는 이식성 테스팅은 알려진 일련의 디바이스와 SW 버전에 걸친 테스팅을 요 
구한다. 미래를 대상으로 하는 이식성 테스트를 위해서는 어떤 디바이스가 계속 인기가 있을 것 
인지, 어떤 기능이 충돌하거나 제한될 가능성이 있을지 그리고 사용자가 어떤 방식으로 사용할지 
에 대한 예측을 해야 한다. 모바일 디바이스 분야는 매우 빠르게 변화하기 때문에 테스터는 새로 
운 디바이스와 주요 업데이트의 출시 일정에 대해 알고 있어야 한다. 업데이트된 하드웨어 디바 
이스를 구비하기 위해서는 큰 비용이 들 수 있지만, 시물레이터는 실제 디바이스의 출시 시기보 
다 뒤쳐지는 경향이 있다. 그 결과 테스트팀이 테스트를 시도할 기회를 갖기 전에 시장이 이미 
새로운 디바이스로 기존의 어플리케이션을 테스팅하는 경우도 종종 발생한다.
개발자는 설계가 미래 지향적일 수 있게 최선을 다해야 한다. 디바이스 제조업체는 일반적으로 
이전 버전과의 호환성을 어느 정도 보장하겠지만（이전 버전에서 작동하였던 SW가 새로운 버전에 
서도 여전히 작동함을 의미）, 모바일 디바이스의 수명이 워낙 짧기 때문에 이전에 출시된 SW에 
대한 지원은 예전 PC SW 시대에서 본 것보다 훨씬 더 빠르게 중단될 수 있다.
이식성 테스팅에서는 어플리케이션이 디바이스 고유의 네이 티브 인터페이스를 사용하는지 아니면 
보다 이식이 수월한 인터페이스를 사용하는지를 고려해야 한다. 네이티브 인터페이스를 사용하는

 

어플리케이션은 다른 유형의 디바이스에 설치되고 실행될 때 이식성 문제에 부딪힐 가능성이 있 
다. 더 일반적인 인터페이스를 가진 어플리케이션은 다른 디바이스에 이식하기 쉽게 설계된다.
다른 환경으로 이식된 SW는 때때로 새로운 환경에서 기존과는 다른 성능과 사용성을 보여준다.
모든 이식 프로젝트는 성능 및 사용성이 수용 가능한 수준에 도달하는지 확인하기 위한 추가 테 
스트를 고려해야 한다. 예를 들면, 비행 정보를 표시하는 모바일 어플리케이션은 태블릿에서는 가 
독성이 높지만, 스마트폰에서는 화면 크기가 맞지 않거나 크기 조정이 되지 않을 수 있다. 마찬가 
지로 특정 디바이스에서 빠르게 작동하도록 개발된 SW가 다른 디바이스에서는 해당 환경에 최적 
화되지 않았기 때문에 매우 느릴 수 있다.

3.3.4 신뢰성 테스팅
모바일 SW는 모든 곳에서 많은 사람들이 사용하기 때문에, 비즈니스와 개인생활 모두에서 중요 
한 부분을 차지하게 되었다. 사람들이 점점 더 모바일 어플리케이션에 의존하게 되면서 신뢰성은 
중요한 품질 특성이 되었다. 일부 모바일 어플리케이션은 안전-최우선적(safety-critical)이며 매우 
높은 신뢰성을 필요로 한다. 신뢰성은 SW가 얼마나 결점을 잘 처리하는지(결점 허용성), 문제가 
발생할 때 얼마나 빨리 그 문제로부터 복구되는지, 그리고 같은 동작에 대해 동일한 결과를 얼마 
나 일관성 있게 제공하는지를 포함하는 SW의 견고성(robustness) 등을 의미한다.

3.3.4.1 모바일 SW 신뢰성 테스팅
신뢰성 테스팅은 장애를 발생시켜, SW가 장애를 얼마나 정확히 찾아내고 적절하게 처리하여 그 
장애로부터 회복하는가를 검증하는 것이다. 모바일 SW는 통신이 끊겼을 경우 다시 접속 가능해 
야 하며, 트랜잭션 데이터를 분실하지 않고 지속해서 처리할 수 있어야 한다. 모바일 디바이스는 
그 정의처럼, 항상 이동한다. 모바일 디바이스는 접속신호가 약한 장소로도 이동하며 터널, 지하,
비행기로도 이동한다. 최소한 사람들이 이동하는 모든 곳으로 이동하기 때문에 아주 다양한 잠재 
적 신뢰성 문제들을 가지고 있다.
모바일 디바이스의 신뢰성 테스팅은 온도에 대한 내성, 충격, 침수, 폭염과 혹한 등을 모두 고려 
해야 한다. 디바이스에서 실행 중인 어플리케이션은 이러한 조건뿐만 아니라 완전한 전원 차단이 
나 고장과 같은 조건이 가져오는 영향에 대처할 수 있어야 한다.

3.3.4.2 신뢰성 테스팅 접근법
모바일 어플리케이션은 다른 어플리케이션과 마찬가지로 신뢰성 문제에 대한 테스트가 이루어져 
야 한다. 여기에는 메모리 부족 또는 다른 자원 제약, 하드웨어 장애, 네트워크 및 통신 장애가 포함된다.
전통적인 신뢰성 테스트뿐만 아니라 배터리의 저 전력, 완전한 방전 등 전원관련 장애에 대처할 
수 있는 어플리케이션의 역량도 테스팅의 대상이다. 모바일 디바이스는 일반적으로 배터리로 구 
동되기 때문에 전원관련 장애는 전통적인 어플리케이션에 비해 그 리스크가 높다고 볼 수 있다.
마찬가지로 네트워크 접속, 단절 및 재접속（이동 통신에서 Wi-Fi로의 전환과 같은 전환 포함） 같은 
네트워크 접속관련 이슈도 발생할 가능성이 높으므로 모두 테스트해야 한다. 모바일 디바이스는 
기존의 컴퓨터보다 훨씬 오랜 기간 연속적으로 사용하기 때문에 메모리 누수와 같은 문제도 발생 
가능성이 더 높다.
신뢰성은 또한 모바일 어플리케이션이 장애없이（또는 배터리를 재충전하지 않고） 얼마나 오랫동안 
작동할 수 있는지를 알아봄으로써 측정할 수 있다. 간단한 자동화 테스트를 만들어 장애들 사이 
의 평균 시간（MTBF;Mean Time Between Failure을 측정함으로써 필요한 데이터를 얻을 수 있다.

장애가 발생하면 신뢰성 장애 시나리오를 작성할 수 있고, 이런 시나리오를 개발팀에 제공하여 개발팀이

발견된 장애를 예방 또는 처리할 수 있는 더 강한 모바일 어플리케이션을 설계하는 데 도움을 줄 수 있다.

또한, 개발자가 장애가 발생할 경우의 복구 절차도 준비할 수 있게 해준다.