brunch

You can make anything
by writing

C.S.Lewis

by 커리어가 꼬인 스타트업 기획자 Sep 29. 2016

실전 앱 테스트 노하우

스타트업에선 이렇게도 한다.

지난 주 소프트웨어 QA가 왜 중요한지에 대한 글을 썼고, 오늘은 실제로 앱을 테스트하는 필자의 노하우를 정리해보려고 한다. 경력이 있으신 분에겐 익숙한 내용이기 때문에, 막 테스터 업무를 맡은 신입 기획자나 인력이 부족해 모두 테스트를 진행해야 하는 스타트업에서 참고하면 좋을 것 같다.

먼저 서비스(이하 앱)를 테스트 하는 목적은 우리가 열심히 개발한 '앱의 상용화'에 문제가 되는 결함(이하 버그)을 찾기 위해서다. 아무리 대단한 능력을 가진 사람들이 모여 만든 소프트웨어라도 버그는 늘 존재한다. 소프트웨어는 수십, 수백만줄의 텍스트가 모여 유기적으로 동작하는 것인데, 그 길고 긴 텍스트가 토씨 하나 빠짐없이 완벽할 수는 없긴 때문이다.

따라서 테스트에 임할 때는 '버그는 늘 존재한다' 는 마음으로 편하게 접근하길 바란다. (간혹 테스트를 하다보면 반복되는 버그와 사이드 이팩트로 인해 집중력이 떨어지는 시점이 온다. 이때 멘탈이 흔들리면, 발견하기 쉬운 버그도 놓치고 업데이트 하는 경우가 종종 있다..)

1. 기획서 분석하기

앱 테스트의 시작은 기획서 분석이다. 기획서는 모든 요구사항이 반영된 문서이기 때문에 정책, 화면, 예외 상황에 관한 모든 정보가 담겨 있다.

어떻게 시작해야 될지 몰라 고민이 된다면.. 일단 해당 기획서를 처음부터 쭉 가볍게 읽어보는 것이 좋다. 제대로 된 기획서라면 해당 기능의 사용 목적과 기능, 정책이 담겨 있을 것이다. 이를 가볍게 숙지한 상태로 화면 왼쪽에는 기획서, 오른쪽에는 엑셀 프로그램을 실행한다.

2. Test sheet 만들기

Test sheet를 만드는 이유는 테스터 본인에게도 도움이 되고, 팀원들과 공동 테스트를 할 때 중요한 기준이 되기 때문이다. 아무리 본인이 익숙해진 상태라 하더라도 Test sheet는 꼭 확인을 하며 테스트 해야 한다. 아무리 꼼꼼한 사람도 깜빡하기 마련이고, 테스트가 익숙해진 상태에서는 기본적인 확인을 간과하는 경우가 많기 때문이다.

간혹 테스트를 Jira나 Asana, Slack 등의 서비스를 이용해 처리하는 경우가 있다. 이 경우에도 Test sheet는 반드시 필요하다. Test sheet는 테스트 기준을 확립하기 위한 것이지, 테스트 결과를 공유하기 위한 문서가 아니다.

아래는 필자가 실제 사용하고 있는 Test sheet 양식의 일부다.

Test sheet 예시

위의 Test sheet는 구분을 크게 모듈과 화면로 나눈다. 모듈은 테스트하는 앱의 '탭 메뉴'를 잡으면 무난하다.

예를 들어 카카오톡을 테스트한다고 했을 때는 모듈을 크게 '인트로, 친구목록, 채팅목록, 채널, 더보기, 공통'과 같이 6개 정도로 나누면 무난하다. 모듈은 다시 여러 개의 화면으로 구성된다. '인트로' 모듈 안에는 스플래시 화면과 로그인 화면, 회원가입 화면, 비밀번호 찾기 화면등이 존재한다.

화면 다음 칼럼에는 테스트 범위, 즉 테스트 대상을 작성한다. 보통 UI 확인과 입력란, 기능버튼 등으로 묶는 편이다. 그리고 조건에는 특정 예외 상황을 맞춰 테스트 해야 하는 경우의 조건을 입력한다.

테스트 케이스에는 실제 사용자가 테스트 해야하는 행동에 대해 기술한다. 다음은 기대값으로 특정 행동에 대한 정상 케이스를 설명해줘야 한다. 그리고 테스트한 결과는 Pass, Fail, N/A(해당없음) 로 구분하여 작성한다. 테스트 결과가 Fail 인 경우에는 결과(본인 이름) 항목에 문제가 있는 증상을 기술하여 담당자가 확인할 수 있도록 한다.

건의사항이나 추가의견은 사용 상의 오류가 버그는 아니지만 좀 더 나은 제품을 위해 필요한 개인적인 의견을 작성하면 된다. (필자는 시간에 쫒기는 경우가 많아 구두로 전하는 편이다.)

일반적으로 상용화 직전의 앱들은 테스트 케이스가 약 500개 안팍으로 최초 작성에 시간이 들지만 한번 작성을 완료하고 나면, 문서 유지보수에 많은 노력이 들지 않고 다수의 테스트가 활용할 수 있어 기본적인 서비스 품질을 확보하는데 매우 유용하게 사용할 수 있다.

3. 구글 문서-스프레드 시트 활용하기

이제 열심히 작성한 Test sheet를 활용할 때가 왔다. 앞서 잠시 언급한 Jira나 Asana, Slack 등을 사용한다면 가볍게 넘어가도 좋다. 하지만 위와 같은 서비스를 이용하기 힘들 때는 구글 문서도구를 활용하는 것도 괜찮은 방법이다.

구글 문서도구는 기본적으로 팀간 협업을 지원하고 있다. 따라서 Test sheet를 구글 문서도구에 스프레드 시트로 만들고 이를 담당자들과 공유하면, 테스터가 확인하고 입력한 결과값을 실시간으로 공유할 수 있다. 테스터가 여러 명인 경우에는 Test sheet 양식 우측에 '결과(테스터 1)' 칼럼을 여러 개 추가해 사용하면 된다.

지금까지 앱을 테스트하기 위해 필요한 Test sheet 작성과 테스트 결과를 공유하기 위한 도구를 간략하게 소개했다. 이제 실제 앱 테스트에 활용할 수 있는 팁을 전하고자 한다.

1. 테스터가 고려해야 할 3가지 접근법

기능 (요구사항을 그대로 구현)

UI/UX (사용 상의 불편함, User flow, 애니메이션 등 체크)

성능 (화면 로딩속도, 콘텐츠 재생 속도 등 체크)

하나의 화면을 테스트할 때에도 꼭 기능, UI/UX, 성능을 고려해가면서 봐야한다. 당연히 Test sheet를 작성할 때도 위의 3개 요소가 전부 담겨 있어야 한다.

2. 스마트폰 네트워크 연결 테스트 Tip

스마트폰 앱은 사용자 환경이 각각 다르기 때문에 네트워크 연결에 따른 테스트를 꼭 진행해야 한다. 지하철 안이나 버스, 건물 지하 주차장 등 네트워크 연결에 문제가 될만한 환경이 일상 속에 산재해 있기 때문이다.

위와 유사한 환경을 만들기 위해 필자는 전자렌지를 활용한다. 스마트폰을 전자렌지에 넣고 전자렌지 문을 닫아 네트워크를 차단하거나 문을 살짝 열어 인위적으로 전파가 약한 상태를 만들 수 있다. 이렇게 하면 앱이 네트워크 연결 중단이나 딜레이시에 어떻게 동작하는지 손쉽게 확인할 수 있다. (혹시라도.. 전자렌지 버튼을 눌러 돌리면 큰일나니 주의해야 한다..)

3. Basic sheet 작성 및 활용

앞서 위의 단락에서 작성한 Test sheet 내 케이스는 일반적으로 500개 정도 된다. 그런데 일부 탭 기능의 업데이트마다 500개 전부를 확인해보는 것은 사실 투자 대비 그리 실속있는 행동은 아니다. 따라서 기초적인 테스트에 사용할 별도의 Basic sheet를 작성이 필요하다.

Basic sheet는 대략 50~70개 케이스가 적당하며, Test sheet에서 각 모듈 별 핵심기능과 서비스의 코어를 담당하는 주요 기능을 뽑아 구성한다. 어떤 항목을 뽑아야 할지 고민이 된다면 담당 개발자와 함께 고민해보는 것도 좋은 방법이다.

이렇게 만든 Basic sheet는 앱의 특정 모듈 일부만 수정된 상태에서 그 중요도나 위험성이 높지 않을 때, Test sheet에서 수정된 모듈 부분만 발췌해 함께 사용한다. 이를 통해 앱의 기본기능과 수정모듈에 대한 테스트를 빠르게 확인할 수 있다.

4. Test 환경 고려

아이폰과 안드로이드 모두 최초 개발 이후에 상당히 많은 버전과 기기들이 개발되었다. 그 동안 화면 사이즈도 달라졌고 OS 버전에 따른 API 나 접근권한 또한 계속 변화하고 있다. 따라서 테스터는 Fail 항목에 대한 문제를 기술할 때에 스마트폰 모델명과 OS 버전을 공유해야 한다. 그래야 담당 개발자가 손쉽게 에러의 원인을 파악할 수 있다.

테스터가 여러 명인 경우에는 OS 버전과 스마트폰 제조사 별로 담당 테스터를 구분하는 것도 좋은 방법이다.

keyword