KSTQB_Mobile Tester 2장

2.1 기능 및 특성 식별

기능이 많은 모바일 디바이스를 테스트 하기는 쉽지 않다 따라서 테스팅 범위 내에 속하는 기능과 특성에 집중하는 것이 중요함

ex)

• 신규 어플리케이션을 여러 종류의 스마트폰에 적용하는 것이 목표 : 어플리케이션의 기능, 디바이스와 어플리케이션의 연동성, 사용성과 성능에 집중
• 새로운 스마트폰을 출시 : 핸드폰의 자체 기능, 대표적인 어플리케이션 지원 여부, 디바이스와 네트워크 사이의 통신방식 등 품질특성에 집중

---

2.2 리스크 식별 및 평가

모바일 어플리케이션은 일반적으로 기능이 많은 반면 그 기능의 구현 및 테스팅에 사용할 수 있는 시간은 많지 않다는 특징을 가지고 있다.

비공식적인 경향이 있고, 리스크를 식별하고 평가하는 과정도 간단해야 하며, 물리적 역량과 기능적 역량으로 나누어서 접근하는 것이다.

• 물리적 역량 : 사용자가 물리적으로 터치하는 장치(예: 버튼, 아이콘, 디스플레이, 그래픽)와 사용자가 사용하는 디바이스의 물리적 기능(예: 회전과 가속도계) 등을 말하며 그 자체로 기능은 아니지만 어플리케이션의 기능을 사용 가능하게 한다.
• 기능적 역량 :  디바이스의 S/W 적 기능과 목적을 고려 (예: 네비게이션 사용 시 위치를 잘 잡는지?) 

리스크 영역 확인에 도움이 되는 생산 메트릭 예시

• 다운로드 총 수 : 어플리케이션에 대한 관심도(동시 사용자 수의 최대치를 제공함)
• 어플리케이션 사용자 수 : 어플리케이션 실 사용자 수(다운로드 후 사용하지 않는 수 제외됨)
• 실사용자 비율 : 다운로드 총 수에 대한 어플리케이션 실 사용자수의 비율
• 신규 사용자 : 일정 기간 내 어플리케이션을 처음 사용하는 사용자 수(특히 실 사용자 비율로 알 수 있는 감소하는 사용자 비율과 비교할 때 유용함)
• 방문 빈도수 : 일정 기간 내 사용자의 수에 대한 방문 횟수 비율(사용자 충성도 측정)
• 방문 깊이 : 어플리케이션 사용 시 평균 방문 화면 수
• 지속 기간 : 어플리케이션 사용 시 평균 사용 시간
• 이탈률 : 1회 방문 사용자 비율 (어플리케이션 다운로드 및 접속 후 다시 사용하지 않는 사용자)

---

2.3 커버리지 목표 설정

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

 

프로젝트 테스팅 시작 전 아래 항목을 고려하여 바람직한 커버리지를 결정할 수 있음

• 요구사항 : 요구사항이 정의되어 있는 경우, 요구사항 커버리지를 테스팅 가이드라인의 하나로 사용해야 한다.
• 리스크 : 식별된 리스크는테스팅되어야하며, 테스트 케이스와리스크 아이템 간의 추적성이필요할수 있다.
• 기능 : SW 기능 자체도 테스트되어야 하지만 그와는 별도로 관려된 리스크를 검증하기 위해 기능이 다시 테스트될 수 있다. 모든 기능이 나열된 목록을 작성해두면 리스크 레벨을 확정하고 각기능에 대한 테스트 커버리지를 추적하는 데 도움이 된다.
• 코드 : 모바일 어플리케이션을 빠르게 개발해야 하므로 단위 테스팅은 단위 테스팅은 매우 중요하며 개발이 시작되기 전에 코드 커버리지 목표를 결정해야 한다.
• 디바이스 : 디바이스 커버리지는 프로젝트 시작 단계에서 반드시 결정해야 함 그래야만 해당 디바이스를 확보하거나 시뮬레이터를 구매 또는 제작할지결정할수 있다.
• 통신 : 디바이스의 인터넷 통신방식에 대한 커버리지도 필요함(네트워크 잠재적 부작용도 커버리지에 포함되어야 함)
• 지리적 위치 : 어플리케이션이 사용될것으로 예상되는 지리적 위치도 테스팅에 영향을 미친다. 만일 어플리케이션이 높은 고도에서만사용될것으로 예상한다면 그런 점을 테스트 환경으로 고려해야 한다.
• 사용자 관점 : 좋은테스트 케이스설계를 위해 사용자의 기대, 지식, 역량, 인격 그리고 운영 프로파일 (사용자가 할것으로예상되는 행동) 등을 알아야 한다. 테스팅은 다양한 사용 방법을 시뮬레이션 한다.

테스팅 커버리지 요구사항을 이해하는 것은 테스팅 노력의 범위와 일정을 결정하고 테스트에 필요한 장비와 환경을 신청하는데 중요하다.

---

2.4 테스트 접근법 결정

커버리지 목표가 정의되고 나면 적절한 테스트 접근법을 결정한다.

• 환경 : 테스트는 특정 환경에서 실행해야 하며 그러한 테스트 환경에서는 고려해야 할 조건(비가오는 야외)이 있다.
• 사람 : 제품은 특정 사용자 유형(그룹)을 위해 개발됨 해당 유형의 사용자가 가지는 특성을 테스트 케이스에 반영해야 함 (예: 시력이 나쁜사람은 그림이나 사진을 볼 때 항상 확대해서 본다.)
• 산업 분야별 정황 : 테스트 접근법 결정 시 해당 산업 분야의 요구를 고려한다.
• 일정 : 테스트 접근법 결정 시 현실적인 일정을 고려해야 하며 우선수위가 높은 테스트를 먼저 실행하도록 계획해야 함
• 범위 : 달성할 커버리지와 리스크 오나화 목표를 분명히 할 수 있도록 테스트 범위는 제한해야 하고 명확하게 표시해야 함
• 테스트 결과 평가 : 모바일 프로젝트의 경우 안전 최우선 테스트 케이스를 제외한 대부분의 테스팅이 구조화가 덜된 기법을 사용하여  시뮬레이터와 에뮬레이터를 가지고 실행 하므로 테스트 결과 평가는 기존 전통적인 프로젝트와는다르게 이루어진다.
• 테스트 방법 : 테스팅 방법은 모바일 프로젝트에 따라 다르다. 특정 품질특성, 환경 및 도구에 따라 어떻게 적용하는지 확인해야 한다.

---

 

2.5 테스트 컨디션 식별 및 범위 설정

테스트 컨디션은 모바일 어플리케이션 프로젝트에서 실행할 테스팅을 위한 기본 요소이다.
빠르게 진행되는 프로젝트에서는 테스트 케이스를 작성할 수 있는 시간이 부족할 수 있으므로, 테스트 컨디션을 확인하고 리스크를 기반으로 각 컨디션의 우선순위를 할당하여 확인된 각 컨디션을 다루는 테스팅을 실행하는 것이 제한된 시간 내에 테스팅 하는 가장 효율적인 방법이다. 

---

2.6 리그레션 테스팅

어플리케이션 자체는 변하지 않더라도 모바일 어플리케이션에 대해서는 주기적으로 리그레션 테스팅을 실행해야 한다.
테스트 자동화, 디바이스랩 그리고 시뮬레이터가 있다는 것은 성공적인 모바일 어플리케이션 프로젝트에 매우 중요하며 성공적인 리그레션 테스트 실행을 위해서도 필요하다. 리그레션 테스팅이 자동화되고 디바이스 사용이 가능하다면(랩 또는 시뮬레이터를 통해)  정기적으로 (예: 일주일에 1회) 리그레션 테스팅을 실행하도록 계획 할 수 있다.