아이폰4용 핀로 슬라이스3케이스, 얇긴 얇네요.

전에 써오던 아이폰 케이스인 에어자켓이 깨져서 새 케이스를 찾아봤습니다. 에어자켓이 케이스 중에서는 얇은 편에 속하는 녀석이었는데요 두어번의 추락에서 나름 아이폰 흠집을 잘 막아주었습니다. 얇은 케이스를 선호하는지라 더 얇은 녀석이 없나 찾다가 발견한 Pinlo의 슬라이스(slice) 3. 두께 0.35mm 라고 합니다. 국내에서도 팔긴하는데 일부 색상만 수입이 되었습니다. 제가 찾는 검정반투명은 없더군요.

결국 이베이에서 주문. 18.9$ 주었습니다. 배송비 5$이 아까워서 이왕 주문하는 김에 2개 주문했고요. 지난주 화요일에 주문하고 오늘 받았으니 8일 걸린 셈입니다.

샛노란 뽁뽁이 봉투에 담겨올 줄 알았는데 의외로 상자입니다. 2개라서 그런가봅니다.

각각 원래의 개별포장에 비닐봉투에 한번씩 더 넣어서 왔습니다. 별도의 완충재는 없었는데 다행이 파손이나 흠집은 없었습니다.

개별 포장입니다. 트레이싱지 같은 느낌이 나는 띠지가 한겹 둘러있습니다.

박스 아래쪽 띠지에 인쇄된 내용입니다. 이러저러한게 들어있다고 합니다.

포장케이스의 양옆 두군데 스티커를 떼어내면 뚜껑이 열립니다. 반투명이고 무광입니다.

이런이런. 이렇게 얇나요? 조금 과장해본다면 케이스라기보다는 케이스형태를 한 두툼한 일체형 보호필름으로 봐야하지 않나 싶습니다. 에어자켓도 얇지만 두께는 핀로 슬라이스3 쪽이 체감할 수 있을만큼 더 얇습니다.

아이폰에 끼운 모습입니다. 사진엔 두툼하게 나왔는데 실제론 무척 얇습니다. 보시다시피 버튼마다 딱 맞춰서 구멍이 파여있기 때문에 아이폰4와 4s용 잘 알아보고 사야합니다.

물론 얇다보니 떨어뜨렸을 때 충격보호 효과는 두툼한 케이스보다는 떨어질것으로 예상합니다. 그래도 두툼한 고무재질 케이스 아닌 다음에야 아스팔트 바닥에 철푸덕 떨어지는데는 장사없다는 생각이고요. ㅋ

아이폰4 케이스는 무조건 얇아야한다는 생각을 하는 분들께는 추천할만한 제품입니다. 에어자켓은 매끈한 표면이었는데 이 녀석은 무광이 보여주는 느낌만큼의 미세한 표면질감이 있습니다. 손톱으로 꾹 눌러서 긁어보면 지나간 자국이 바로 남네요. 전 이 정도는 감수할 수 있을만큼 얇은 두께에 만족해하는 중입니다.

[업데이트]@2011/12/14 08:00

같이 들어있는 보호필름 사진을 빼먹었네요. 제품 포장안에 들은 흰색 얇은 상자를 꺼냅니다. 저 안에 보호필름이 들어있습니다.

붙이기전에 아이폰을 닦는 천, 보호필름, 기포제거용 플라스틱조각 그리고 케이스 분해방법을 설명한 쪽지가 들어있습니다. 오른쪽 아래, 왼쪽 아래 순서로 들어내라는군요. 필름 품질은 그냥저냥~

연하장을 보낼 때다.

친구들과 한 해 동안 일어난 기쁜 일과 고생한 일을 서로 나누며 술잔을 기울일 궁리도 물론 해야하지만;;

한글자 한글자 꾹꾹 눌러 써서 감사한 마음을 전하는걸 잊어선 안되는 분들이 있다.

기획자,PM 입장에서 본 QA

유,무선을 막론하고 인터넷 서비스를 오픈하기 전 내부적으로 검수를 받는 QA (Quality Assurance)

서비스나 회사 특성상 내부 조직에서 할 수도 있고 별도의 외부 전담부서에서 진행할 수도 있습니다. 대상이나 방법론 역시 각 서비스마다 고유한 양식을 갖고 있을 겁니다. QA는 서비스 품질 관리상 필수적인 절차이면서도 버그가 발견되면 오류 수정과 그로 인한 실서버 적용 일정에 차질을 빚을 수 있으므로 (즉, 일정 연기의 부담 또는 부득이한 야근 등) 서비스 실무부서에서는 심한 스트레스를 받는 과정이기도 합니다.

QA를 진행하는 부서, 테스터 입장이 아닌 QA를 받는 기획, PM 입장에서 그동안 겪은 QA를 바탕으로 몇가지 생각을 정리해 봅니다. 위에서도 말했지만 QA는 회사마다,서비스마다 규모와 절차가 다르니 아래 내용은 읽는 분의 상황에 따라 맞지 않을 수도 있음을 염두에 둬 주세요.

1. QA 전

  • TC(Test Case) 작성
    테스터들이 실제로 테스트를 진행해야하는 각각의 항목을 명시한 표를 말합니다. TC는 서비스 규모에 따라 적게는 수십개 항목에서 많게는 수백개, 수천개가 되기도 합니다.
  • TC를 작성할 때는 테스트 하는 내용과 규모에 따라 다릅니다만 보통 서비스의 핵심 과업 및 메뉴구조에 따라 서비스가 제공하는 기능과 화면 메세지, 오류 처리 방법을 명시합니다. 메뉴를 사이트맵이나 트리구조처럼 늘어놓고 각각의 메뉴에서 제공하는 기능과 메세지를 정리하여 빠지는 기능이 없도록 TC를 작성합니다. 물론 개선,변경된 부분이 있으면 그 부분에 대해서만 QA를 할 수도 있고 그 부분 때문에 다른 쪽에서 오류가 발생할 수도 있기 때문에 전체를 다 QA하는 경우도 있습니다.
  • 명확한 테스트 케이스와 결과 표시
    TC를 작성하면서 자주 저지르기 쉬운 오류는 TC의 내용과 결과물을 명확하게 서술하지 않는 것입니다. 기획자나 개발,운영 등 해당 서비스에 관여하고 있는 사람이 서비스를 이해하는 정도와 QA조직에서 해당 서비스를 이해하는 정도는 서로 다릅니다. 예를 들어 “A라고 써 있는 버튼을 눌렀을 때 ㄱ의 세부 내용이 잘 표시되는가?” 라고 쓰면 테스터들은 “잘 표시”가 어떤 내용이 어떤 방식으로 화면의 어디부터 어디까지 얼마동안 표시되어야하는지 알 수가 없습니다. 오랫동안 서비스를 들여다본 사람 입장에서는 당연하다고 생각하는 항목이 다른 사람에게는 전혀 그렇지 않을 수 있지요. 예를 들어 화면에 텍스트를 표시할 때 화면을 넘치는 글을 줄바꿈할지, 점(…)으로 표시할지, 왼쪽으로 천천히 스크롤 시킬지, 그냥 잘라내버릴지, 어떤 화면이 과연 “잘” 나오는 것인지 알 수 없습니다. 올바른 출력 예를 화면 캡춰그림과 함께 보여주면 좋습니다.
  • 테스터용 환경 셋업 (네트워크, 위치정보, 로그인 정보, 호스트 정보 )
    테스터들이 사용할 장비, 네트워크, 프로그램, 로그인 계정, 호스트 정보들을 미리 정리하여 테스트에 문제가 없도록 준비해야 합니다. 특히 QA조직이 다른 네트워크, 다른 위치에 있는 경우는 각별히 조심해야 합니다. 대부분의 개발서버는 외부에서의 접근을 차단 또는 제한하고 있으므로 테스터가 QA도중 서비스 접속이 안되거나 잘못된 서버로 연결되어 엉뚱한 결과를 얻을 수 있습니다. QA조직에서는 그래서 QA 전날 또는 당일 오전 일찍 QA환경점검을 하기도 합니다만 이 단계에서 전체적인 서비스 테스트 환경을 모두 체크하기는 어렵습니다. 서비스의 구조와 동작방식을 알고 있는 서비스팀과 개발조직에서 테스터들의 QA환경에서도 문제가 없는지 미리 점검해야 합니다.
  • 주요 오류에 대한 사전 점검
    TC 작성과 아울러 QA전에 충분한 사전 테스트를 하는 것이 매우 중요합니다. 각 메뉴별로, 각 기능별로는 물론 주요 사용자 스토리별로도 테스트를 해봅니다. 서비스를 개편했거나 기능을 개선한 것이면 해당 기능 자체는 물론 영향을 받을 수 있는 다른 기능에 대해서도 주의를 기울여 살펴봐야 합니다. 이 점에 대해서는 개발자에게 사전에 의견을 들어보는 것이 좋겠지요.
  • 놓치지 말고 체크해야할, 자주 나오는 오류케이스
    • 입력칸에 잘못된 값(html태그, 특수문자, 비정상적으로 긴 문자열, 빈 공백, 큰 이미지 첨부 등)을 넣었을 때에 대한 처리를 빼먹었을 때
    • 브라우저 메뉴에서 뒤로와 앞으로를 반복할 때 페이지의 전체 또는 일부 영역이 제대로 표시되지 않는 경우 (폼 입력값 위주로)
    • 사용자가 URL을 직접 치고 들어 올 때에 대한 준비 미흡
    • 초기에 아무런 데이타도 들어 있지 않은 경우와 서비스에 오류가 났을 때 출력할 화면 준비 미흡. (오류시 서버가 내뱉는 오류메세지를 그대로 화면에 출력하는 경우를 “내장이 튀어나왔다”고 할 정도로 부끄러워하는 기획자들도 있습니다.)
    • 레이어가 서로 잘못 얹혀지거나 위 레이어가 아래 레이어 영향을 끼쳐 기능이나 화면 표시가 겹치거나 가리는 현상

2. QA 진행중

QA중엔 테스트 중 문제가 보고되진 않는지 만약 그렇다면 어떤 문제인지에 대해 여러 부서. 담당자와 시간을 다투며 문제를 파악하느라 정신이 없습니다. 일시적인 문제일 수도 있고 개발이나 디자인 과정에서의 오류가 있을 수도 있습니다. 그러나 짜증내고 누구를 질책할 일이 아닙니다. QA에서 나오는 오류에 대한 책임은 꼼꼼하게 챙기지 못한 기획자와 PM에게 있다고 생각합니다. 손발은 바쁘지만 마음은 도를 닦는 자세로 침착하게 상황을 판단하고 이슈들을 정리해나가시길 바랍니다.

  • 기능 질의에 대한 대답
    테스터들은 기획서와 TC를 참고로 테스트를 합니다. 그런데 실제로 서비스를 만들다보면 애초 기획서와 달라지는 부분이 생길 수 있습니다. 이걸 다시 기획서에 반영을 해놓으면 좋은데 그러지 못하는 경우가 종종 있죠. 이러면 테스터들은 기획자에게 해당 현상을 문의하게 됩니다. 기획서에는 디자인 한겹 올린 예쁜 오류메세지가 그려져 있는데 실제로는 시스템 기본 경고 오류상자가 나온다든가 말이죠. 이게 오류인지 아니면 일정상 또는 기술적인 문제로 제외된 기능 (이른바 Spec out이라고 하는) 것인지에 대해 바로바로 대답을 해주어야 합니다. 물론 그보다는 QA전에 미리 이러한 점에 대해 정리를 해서 테스터들에게 공유를 하는 편이 더 좋습니다. 마치 책 오탈자에 대해 뒷표지 안쪽에 정오표를 첨부하는 것 처럼.
  • 진짜 문제가 나타났다.
    이렇게 현상에 대해 설명 또는 정의를 하면 되는 간단한 경우외에 진짜로 문제가 생기는 경우들이 있습니다.

    QA중 이상 현상이 나오면 테스터는 재현되는 현상인지를 확인한 후에 PM에게 직접 또는 QM이라는 QA책임자를 통해 담당기획자에게 이 현상에 대한 문의를 하게 됩니다. 기획자(또는 PM)은 이 현상의 원인을 파악하여 알려줘야 하는데, 원인을 찾는 과정이 쉽지 않습니다. 기획단계에서 그렇게 동작되도록 한 것인지 아니면 정말 오류인지, 오류라면 프로그램상의 문제인지 API 문제인지 네트워크 문제인지 그것도 아니면 또 다른 문제인지를 파악하기 위해서 해당 서비스의 기획자,개발자, 디자이너,UI개발자, 네트워크 엔지니어 등과 빠르게 문제점을 파악하여 회신하여야 합니다. 이것은 테스트에 소요되는 시간에 대한 문제이기도 하고 오류판정의 등급에도 영향을 끼치는 일입니다. 이 과정 때문에 QA가 진행되는 시간 동안에는 서비스에 관계된 실무자나 실무책임자와 계속 연락이 되는 상태를 유지해야 하고 그러기 위해선 미리부터 QA일정을 통보하고 이에 대한 협조를 구해야 합니다. 만약 PM이 이들에게 QA 일정에 대한 공유를 하지 않았다면 당사자가 QA날에 휴가를 냈어도 할 말이 없는거죠.

3. QA를 마치고

  • 판정 등급에 대한 검토와 어필
    QA가 끝나면 QA과정에서 발견된 문제점을 정리하고 이 문제가 심각한 문제인지 아니면 사소한 문제인지 QA담당부서에서 등급을 매겨 옵니다. 화면에 나와야할 글자가 나오지 않았다면 CSS 오류일 수도 있고 DB 입출력에 문제가 있을 수도 있고 아니면 API에서 값을 못 불러왔을 수도 있겠지요. 사실 사용자 입장에서 보면 글씨가 나오지 않았다는 것이 중요하지 우주전쟁으로 외계인이 데이타센터에 들어와서 서버운영요원들을 납치해가는 바람에 장애가 생겼는지는 상관할 바가 아니긴 하지요. 테스터들은 그 문제가 생긴 원인의 심각성 보다는 사용자 입장에서 겪는 오류와 주요 과업의 실패에 대해 중요하게 생각하는 듯 합니다.

    그런데 이 오류라는 것의 심각성이 QA담당자가 생각하는 정도와 기획자가 생각하는 정도가 서로 다를 수 있습니다. 예를 들어 입력칸에 아무것도 넣지 않고 글 작성 완료 버튼을 눌렀는데 “내용을 입력해주세요”라는 오류메세지 없이 그냥 제목없는 결과물이 나왔다고 칩시다. 테스터들 입장에서는 이 오류를 심각한 오류로 판단할 수 있습니다. 일반적인 경우에선 오류일 수 있습니다. 그러나 새로운 모든 서비스들이 기존 서비스들의 평균적인 인터페이스를 제공해야만 하는 것은 아닙니다. 예를 들어 비공개 개인 다이어리에서 제목이 없는 경우 본문의 앞부분을 제목처럼 사용하는 기능을 도입했을 수 있습니다. 이 경우에는 오류가 아니겠지요. 스마트폰에서 사진등을 자기 자신에게 메일 첨부파일로 보내는 경우가 있는데 이렇게 자신에게 메일 첨부를 보낼 때에 한해서 제목없는 메일에 대한 경고문 없이 바로 보내는 경우도 생각해 볼 수 있습니다. 기획자는 “우리 서비스에서는 이러저러한 이유로 그렇게 하기로 했다”고 이야기할 것이고 QA에서는 “고객이 혼란스러울것이다.(또는 오류라고 볼 것이다, 또는 실수할 수도 있을 것이다.) 그러니 제목없이 작성완료 버튼을 눌렀을때에는 경고창을 띄우는 것이 좋겠다.”고 제안을 할 수 있을 것입니다.

    합당한 제안이라면 수락하면 될 것이고 그보다 더 중요하게 생각하는 명분이나 실익이 있다면 다시 설득을 해 볼 수 있겠지요. 적당한 선에서 포기하느냐, 다른 절차를 밟아서 이를 관철 또는 조정하느냐는 각각 회사마다, 경우에 따라 또 사람에 따라 다를 것이기 때문에 어떻게 하는게 맞다고 말하긴 어렵습니다. 경험상 QA 마무리 단계에서 의견충돌이 있기 마련이고 조정 과정에서 극심한 스트레스를 겪게 되곤 하더군요. 그러나 서로 회사로부터 부여받은 권한과 의무에 따라 각자의 일을 하고 있는 것임을 잊지말고 공식적인 절차에 따라 (쉽진 않지만) 차분하게 설명하고 우아하게 설득하는 자세가 필요합니다.

곰곰히 생각해보면 기획자,PM으로서 QA를 할 때 가장 중요한 것은 서비스와 기능에 대한 충분한 이해와 문서화 능력, 그리고 각 QA 및 유관부서 담당자와의 원활한 대화능력이라고 생각합니다.

QA는 필요악이 아니라 반드시 필요한 당연한 과정입니다. 다만 내가 검토해서 오류가 없다고 확신한 항목, 또 미처 살펴보지 못한 부분에 대한 오류들이 검출되고 또한 서비스를 만들면서 옳다고 생각했던 세계관에 대한 반론이 들어오는 것에 대한 대응 과정이 상당히 스트레스 받고 피곤한 과정이어서 힘든 것입니다.

서비스가 세상에 나오기 전 마지막 산고 단계인 QA과정, 스트레스 어차피 받으시겠지만 그러려니 하고 모든 실력과 품성을 최고조로 발휘해서 즐겁게 잘 하시기 바랍니다. ^^;

머리로 정리하기 어려우면 눈으로 보면서 하기

엊그제 앱에서 일부 프로세스를 정리할 일이 있었습니다.

두가지 항목에 대해서 각각 참일때와 거짓일때 조합 즉 4가지 경우에 대해서 그리고 두번째 항목의 값은 나중에 거짓에서 참으로 바꿀 수 있어서 거기에 대한 고려도 해야 했습니다.

대충 순서도로 분기할 지점과 동작에 대해서 연필로 그려봅니다. 분량과 복잡도, 익숙한 정도에 따라 마인드맵으로 해도 되고 메모장의 들여쓰기 내어쓰기로 해도 됩니다. (첨부한 사진들은, 회사 일이다보니 어느정도 흐릿하게 하였습니다. 대략 분위기만 봐주세요.)

순서도로 대충 파악한 다음엔, 실제로 표시될 화면을 캡춰해서 프린트한 후 1,2,3,4 번호를 매기고 얼럿,메세지 창에는 A,B,C라고 이름을 붙였습니다. 순서도를 하나하나 따라가보면서 1-A 2-A 이런식으로 경우의 수를 그려나갑니다.

그런데 이렇게 해놓고 보니 화면의 이름도 아니고 숫자와 알파벳으로 이루어진 프로세스는 눈에 들어오질 않네요. 헷갈리고 정신이 없습니다.

결국 필요한 화면과 메세지를 캡춰도 하고 그림으로 그려서 여러벌 프린트해서 잘라 놨습니다.

각각의 경우에 따라 화면에 표시되는 페이지와 메세지를 따로따로 만들어보려고 합니다. 빈 A4용지에 재접착이 가능한 풀칠을 하고 화면을 하나하나 붙여나갔습니다. 경고창이나 확인/취소 창도 풀칠해서 화면위에 덧붙였습니다. 영역이 더 필요하면 빈 용지를 붙여나갔습니다.

분기할 지점에서는 아래쪽에 새 옵션에 따른 화면을 그려나가고 색색 견출지로 선택한 옵션을 써서 붙이고 필요하다면 포스트잇으로 설명도 붙입니다.

이렇게 붙여놓으니까 좀 정리가 되네요.

프리젠테이션 도구로 그렸으면 한 화면에 볼 수 있는 공간의 제약으로 일목요연하게 정리하기 어려웠을 겁니다.

물론 개발자에게 저 이어붙인 A4용지를 주며 개발을 부탁할 수는 없는 일이죠. 전체 구조를 하나의 화면에 작게 그리고 메세지와 확인/취소창의 위치를 표시해줍니다.

위 페이지에서 경우에 따라 표시될 화면 이름과 메세지의 구조를 파악했다면 실제로는 어떤 화면인지를 그린 화면을 첨부해서 이해를 돕도록 했습니다. 서로 같이 일하고 있어서 무슨 페이지라고 하면 서로 모를리 없지만 만에 하나 서로 다르게 알고 있는 경우도 있을 수 있으니 명확한 화면을 명시해서 서로 공유하는게 좋죠.

가끔 이렇게 아날로그적인 방법을 사용해보면 훨씬 일이 수월해지기도 합니다.