현실에서의 app 테스트 방법과 문제점

2009년, 국내에 스마트폰이 도입되면서 많은 일들이 일어나고 바뀌었는데, 그 중에 개발자들이 가장 크게 피부로 느끼는 부분은 아마도 잦은 app 업데이트가 아닐까 싶다. 스마트폰이 세상에 나오기 전에는 1년에 한번 app을 업데이트 해서 시장에 내 놓았었는데, 스마트폰이 대세가 된 이후에는 거의 매달 app을 업데이트 하게 되었다. 급기야 어떤 사람이 ‘애자일’이라는 개발 방법론을 내 놓으며, 1~2개월 마다 app을 업데이트 하는 것을 마치 개발자들의 당연한 의무인양 포장하기까지 했으니, 그야말로 개발자들에게는 하루하루가 더욱 애절하게만 느껴지게 했으리라. 이러한 고생은 비단 개발자들만의 일이 아니고 테스터들에게도 크나큰 고역이 아닐 수 없다. 이렇게 빠듯한 일정으로 app이 개발되고 테스트 되어야만 하는 상황에서 제대로 된 테스트를 생각하기에는 쉽지 않았을 것이다. 이러한 문제는 중소기업 뿐만 아니라 대기업에게도 쉽지 않은 도전이며, 다음에 국내 모 대기업의 서비스에 대한 테스트 프로세스에 대해 살펴본다면 독자들도 금방 이해 하실 것이다.

국내 명망이 높은 S사의 핵심 서비스인 A-app(가칭)의 경우, 국내 출시된 모든 스마트폰에 대해 서비스를 제공하고 있는데, 그의 테스트 케이스 개수가 15,000개가 넘고, 출시된 단말 종류는 200기종이 넘는다. 독자들은 출시된 단말이 어떻게 200기종을 넘을 수 있을까 할 수 있겠는데, 그 이유는 이동통신사별로 단말의 기능이 달라지는 파편화가 있기 때문이다. 예를 들면, 통시사별로 app에서 폰빌 과금 하는 방식이 다르고, 통신사의 광고 플랫폼과 연동하는 방식이 다른 등 app 개발에 영향을 주는 것들이 다수 존재한다. 이런 이유로 갤럭시S5 단말도 통신사별로 3종류가 있게 되는 것이다.

한편, A-app 테스트 인력은 10명 정도인데, 이들 인력만으로 15,000개 테스트 케이스를 200종류 단말을 대상으로 테스트 하는 것은 거의 불가능하다. 그래서 사용하는 방법이 테스트 케이스 15,000개 중에서 기능 수정이 있는 부분 위주로 3,000개의 테스트 케이스를 뽑고, 200기종의 단말은 OS버젼 및 LCD 크기 등을 기준으로 16개 그룹으로 나누어서, 그룹 내에 대표 단말 3~5개를 가입자가 가장 많은 순서로 선정한다. 그리고는 2주 간격으로 4개 그룹씩 2달동안 테스트를 수행하여 순차적으로 시장에 릴리즈 하는 것이다. 이렇게 해서 드는 테스트 비용을 돈으로 환산하면, 테스터, 10명이 2달 수행했으니까, 20MM로 1MM당 600만원 적용시 1억2천만원이 드는 것이다. 이 정도 금액이면, 대기업이 아닌 중소기업에서 고려하기 매우 어려운 금액이다. 이렇게 큰 금액을 들여서 테스트를 하는데도 여기엔 몇 가지 헛점이 있다. 첫째, 수정된 기능으로 인하여 수정되지 않은 부분에 문제가 발생할 수 도 있다. 이것을 side-effect라고 부른다. 수정된 부분의 3,000개 테스트 케이스만 테스트 하는 경우, 나머지 12,000개의 테스트 케이스에서 문제가 발생할 가능성이 있는 것이다. 저자가 경험한 바에 의하면 실제로 문제가 생기는 일이 많이 있었다. 또한 16개의 그룹으로 200가지 종류의 단말들을 나누었다고 말씀 드렸는데, 이 경우, 동일 그룹내의 단말들 중에는 실제로 테스트 되지 않고 그냥 상용화 시킨 단말들이 다수 존재하게 된다. 이러한 이유로 인하여 A-app 출시 때만 되면 QA팀 테스터들은 마음을 졸일 수 밖에 없는 것이다.

이렇게 app 테스트는 대기업도 비용 이슈로 인하여 완벽하게 수행하기 어려운 상황이며, 중소기업은 더할 나위 없다. 실제로 app을 개발하는 중소기업 개발자들과 인터뷰를 해 보면 300여개 테스트 케이스를 인기 많은 10여종 단말에 대해 테스트 하는 수준으로 테스트 업무를 수행하고 있는 실정이다. 그러기에 상용화된 app들이 상대적으로 안정성이 떨어지고 문제가 많이 발생하였으리라.

최근에 ㈜BD에서 Testyd라는 서비스를 런칭했다. Testyd 서비스는 기 출시된 100여종의 실제 단말들을 클라우드 상에 두고 개발자가 app을 올리기만 하면, 이를 자동으로 100여종의 실제 단말들에 설치하고 실행시키는 것은 물론이고, 자동으로 눌러야 할 버튼을 찾아 눌러, 실행시켜서, 어디서 죽는지, 반응이 없는지, 지연 반응이 나타나는지, 에러 팝업이 뜨는지 등을 자동으로 찾아주는 서비스이다. 이 모든 과정을 사람의 도움 없이 기계가 알아서 스스로 하기 때문에 밤낮을 가리지 않고 밥도 안 먹고 쉬지 않고 수행한다. 아무래도 기계가 하는지라, 사람 보다는 영리하게 테스트 하지는 못한다. 그러나, 테스트 되지 않은 12,000개의 테스트 케이스, 그리고 200여 기종의 단말들 중, 테스트 해 보지도 못했던 100여종의 단말들에 대해 최소한의 테스트로 Testyd 서비스를 이용한다면 더할 나위 없이 좋지 않겠는가? Testyd는 테스터들에게 정말 기쁜 소식이 아닐 수 없다.

이뿐만이 아니다. 테스트는 크게 세개의 분류로 나뉠 수 있는데, 기능 테스트, 성능 테스트, 사용성 테스트가 바로 그것이다. 일반적으로 테스트라고 하면 기능 테스트만을 생각하고, 또 주로 그렇게 테스트를 수행한다. 사실 기능 테스트도 충분히 못하고 있지 않은가? 성능 테스트와 사용성 테스트 까지 하는 것은 테스트 업계의 어려운 처지를 고려해 볼 때, 거의 사치일 것이다. 이들중 성능 테스트의 경우, Testyd를 이용해서 쉽게 수행할 수 있다. 즉, Testyd를 이용해서 메모리 조건과 CPU조건, 네트웍 조건들을 가변시킬 수 있으며, 이러한 상황에서 눌러야 할 메뉴를 찾아서 차례로 실행시켜 주고 어느 메뉴에서 문제가 발생했는지 찾아 준다면 성능 테스트 효과를 볼 수 있는 것이다. 이런 점에서 Testyd 서비스의 등장은 참으로 획기적인 사건이 아닐 수 없다. 현재 Testyd는 5분간 단순 기능 테스트 수행까지만 한다고 한다. 앞으로 장시간 테스트 및 성능 테스트 등이 추가될 예정이라고 한다. QA팀 테스터가 행복해 지는 그날까지, Testyd의 선전을 바라 마지 않는다.

test kind
[표1] 테스트 분류와 목적 및 방법