태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

해외 서비스 QA를 짧게 경험하면서 느낀점 그리고 고민을 나누고 싶습니다.

|

먼저 이런글을 자유게시판에 써도 되는지 모르기에 상당히 조심스러운데
만약 게시판의 목적에 맞지 않는다면 운영하시는분들께서 삭제하셔도 무방합니다.

안녕하세요
저는 현재 모 개발사에서 해외서비스QA를 9개월 정도 담당 하고 있는 사람입니다.
QA경력이 짧아 많은 지식이 없지만, QA의 중요성과 그것이 바탕이 된 나름데로의 QA에 대한 비전을 가지고 제가 지금 하고 있는 일에서 가능하면 많은 것을 배우고 또한 고민을 나누며 그것을 통해 다른분들과 같이 성장하고 싶은사람입니다.

아래에 의문을 가지는 내용이 각회사마다 처리하는 프로세스가 대외비의 내용이라면 어쩔수없는 부분이지만,
그렇지 않고 혹시 저와 유사한 고민을 가지고 계신분이라면 같이 고민하면서 좀더 좋은 방법을 찾아보면 어떨까 합니다.

국내 개발이 되어 해외 서비스하고 있는 게임을 담당하고 계신 다른분들은
개발사의 담당국가 QA와 퍼블리싱사의 PQA와 SQA 에 대한 커뮤니케이션을 어떻게 처리하고 있으신지요?
 저의 경우에는   실제로 해외서비스 담당 QA를 진행하면서 회사규모가 큰 퍼블리싱 업체와 규모가 영세한 업체가 운영하는 각기 다른 두개의 국가를 담당하고 있습니다. 실제로 진행을 하면서 가장 절실히 느끼는점은 PQA나 SQA가 디테일하게 이뤄지지 않는 다는 점이었습니다.
 업데이트 되는 스팩에 대한 기획서를 전달되더라도 해당내용에 대한 인지가 정확하게 이뤄지지 않는 경우도 많고
대부분의 경우는 기획서에 명시된 내용에 대한 체크리스트나 테스트케이스를 작성하지 않은체 경험기반테스팅을 진행하는 경우가 대부분이기에 이후 발생하는 사후대책부분에서도 처리가 매끄럽지 못했습니다.

 그런부분을 보완하기 위해서 일단 제가 체크리스트를 작성하여 해당 내용을 공유하고는 있지만,
결국 제가 테스트를 진행한 방법으로 동일하게 진행이 되기에 지금의 방법으로는 살충제 파라독스를 예방하지 못하고 있으며, 또한편으론
동일한 내용에 대한 2개의 체크리스트로 각기 다른사람이 테스트를 진행하기에 동일한 이슈에 대해서 두번의 리포팅이 발생하기도 합니다.
물론 그런부분에 대해서는 문제가 리포팅될경우 퍼블리싱사의 담당 QA(보통은 GM이 하더군요)가 저에게 해당 이슈가 리포팅되었는가의 확을 거치기는 하지만, 업무가 효율적으로 진행이 되는것 같지는 않아 고민입니다.
 장기적으로는 저도 많은것을 알고있지는 못하지만 테스팅 기법을 전달하여 퍼블리싱사의 QA의 수준을 끌어올리고 개발사와 퍼블리싱사의 담당 QA가 각자가 만든 체크리스트로 크로스테스팅을 진행하는것을 목표로 간단한 기획서리뷰 방법 그리고 각종 테스팅 기법에 대해서 정리를 하고 있지만, 보다  효율적인 방법은 없을까 고민을 하고 있습니다.

 최근에 든 생각은 웹기반 체크리스트툴을 만들어 관리하면 체크리스트내용 등록및 진행상태등에 대해서도 실시간으로 동기화 될수있을것 같고 테스트 진행상황에 대한 정보도 다른 작업자들의 접근성이 높아져 일정관리가 더욱 용이하지 않을까라는 생각이 들어 올해 중기계획으로 작성해볼까 합니다.

아마도 이글을 읽고 계신 어떤분들은 제가 생각하는 방법에 대해서 과거에 진행하셨거나 진행을 하고 있지 않을까 라는 생각이 들었습니다.
염치 없지만, 혹 그런분이 계시다면 피드백을 해주시면 정말 감사하겠습니다.
아니면 위에 적은것처럼 저와 유사한 고민을 하고 계신분들중  다른 해결방안을 가지고 계시거나 제시해주실수 있으신분이 있으시다면 글을 남겨주시면 감사하겠습니다.

두서 없는글 남겨서 죄송합니다.
2012년 첫날도 어김없이 테스트로 하루를 보내고 있습니다.
아마도 많은분들이 저와 비슷한 하루를 보내고 계시겠지요 새해 복 많이 받으시고
이카페의 목적에 맞는지는 모르겠지만, 현업에서 실무를 하면서 가지는 다른분들의 고민을 듣고 싶고 다른분들이 적용하고 계시는 방법이나 툴등에 대해서도 많이 배우고 싶습니다.
다시한번 두서 없는글 남겨서 죄송하고 끝까지 읽어주신분이 있으시다면 정말 감사합니다.



Trackback 0 And Comment 3
  1. Favicon of https://gameqa.tistory.com BlogIcon GameQA 2012.01.04 14:30 신고 address edit & del reply

    도서관 카테고리로 옮겼습니다~ :)

    (QA관련 지식이나 노하우 공유는 도서관 카테고리로 분류하고 있습니다)

  2. Favicon of https://gameqa.tistory.com BlogIcon GameQA 2012.01.04 15:01 신고 address edit & del reply

    1. 개발사에 QA가 있는 경우, 1차로 개발사에서 QA를 하고, 2차로 퍼블리셔가 QA를 진행합니다.
    2. 개발사에 QA가 없는 경우, 퍼블리셔가 QA를 진행합니다.

    해외QA의 경우, 기본적으로는 개발사에 QA가 있고, 퍼블리셔도 QA를 하는 1번 경우와 같습니다.
    (다만, 국내 퍼블리싱과 달리 언어나 물리적인 거리, 시차 등에서 커뮤니케이션 환경이 조금 다릅니다)

    개발사에 QA가 있을때는, 기획서만 넘겨주는 경우와 테스트케이스를 넘겨주는 경우가 있습니다.
    여기서 테스트케이스를 넘겨 줄 때, 별다른 코멘트가 없으면 대개는 이것만 체크를 한다고 보셔야 됩니다.
    특히나 해외는 국내만큼 온라인게임에 대한 노하우가 없기 때문에 QA수준이 기대보다 낮다는걸 전제하고 있어야 합니다.
    (당연히 기획서만 넘겨주면 테스트케이스를 넘겨 줄 때보다 체크가 더 안됩니다. 다만, 퍼블리셔가 좋은회사라면-국내 퍼블리셔라면- 시도해 볼수는 있습니다)

    결국, 개발사의 QA가 일일이 챙겨야 한다는게 현실입니다.
    고민하고 계시는 문제의 해결책은 피드백을 어떻게 주고 받을 것인가를 잘 정하는 것인데,
    보통 이런 피드백은 -규모가 있는 회사에서는- 전담 PM을 따로 두고, (해외팀, 로컬팀 등으로 불립니다)
    담당자가 따로 없고, 개발사의 QA가 이를 다 관리해야 하는 경우라면,
    피드백을 위한 창구(툴이나 웹페이지)를 따로 둡니다.

    개발QA의 프로세스가 회사마다 조금씩 다르긴 하겠습니다만,
    기본적으로는 버그처리 로직이
    버그제보 -> QA에서 확인 -> 담당자 지정 -> 처리 -> QA에서 처리확인 -> 업데이트
    이런 순서를 따릅니다.

    여기에서 [버그제보 -> QA에서 확인] 단계는 해외라고 해서 다르지 않다고 생각하시면 문제의 해결책이 보이실 겁니다.
    해외에서 버그를 자유롭게 제보하도록 창구를 만드시고,
    그 버그를 QA에서 확인하여, 버그이면 BTS에 등록하시고, 중복이나 버그가 아니면 제보자에게 피드백을 주시면 됩니다.

    만약, 시스템을 잘 만들수 있거나 보안 이슈에서 자유로운 회사라면
    BTS를 통합해서 해외도 함께 볼수 있게 하는것도 좋은 방법입니다.
    다만, 이렇게 하더라도 해외의 QA담당자와는 언어소통의 문제가 있으니
    결국은 해외파트너사의 PM이나, 개발사의 해외PM을 통해야 하기 때문에,
    근본적으로는 실무자가 직접 BTS에 들어와 보기는 어려울 겁니다.

    경험으로 볼 때...
    개발사와 퍼블리셔 사이에서 언어소통을 해주는 담당자를 잘 구워 삶으시면
    지금 겪고 계시는 많은 문제들을 해결할 수 있습니다;

    참고로, 외국계 모 회사는 개발사와 퍼블리셔가 동일한 툴로 통합환경을 구축하여 사용하고 있어서
    버그처리도 통합관리되어 이런 고민은 별로 없다고 하더라구요.
    (이렇게 하려면 개발사와 해외가 모두 영어를 사용해야 겠지요?; 우리에겐 먼나라의 이야기인것 같습니다; )

  3. renardy 2012.01.05 12:30 address edit & del reply

    개발사만큼 퍼블리셔가 능동적이고 창의적이지 못하는점이 없지않아 있습니다. 다 그런건 아니지만서도. 대부분 퍼블리셔 담당자들은 자주 바뀝니다. 사업부는 오래가지만, QA나 GM분들은 게임을 자주 바꾸더라구요. 그래서인지 몰라도 퍼블리셔가 QA를 한다고 하면 개발사들은 그다지 신뢰를 하지 못합니다. 그래서 개발사에서 퍼블리셔로 딜리버리 한 후에도 라이브 열리기전 QA를 또하죠...

    국내는 제외하고 해외서비스시 제 경험상 말씀드리면, 해외도 비슷합니다. 인원 변경이 잦은것도 있고, 게임은 잘하지만.
    QA하는데 개발사에게서만 받은 정보로 테스트하고, 버그전달되는 내용도 자세하게 정보가 오지는 않는것 같습니다.
    특히나 유저제보의 경우에는요.

    그리고 BTS의 경우 거의 같이 쓰기는 힘들고 항상 엑셀이나 요점된 워드 문서로 오기때문에 추적이 정말 힘들지요.

    그래서 저의 경우는 해당 서버에 직접 테스트 가능한 환경을 만드는것과 항상 메인서버(한국서버)를 기준으로 발생했던
    문제로 확인을 1차적으로 한뒤, 국가 특성별 버그사항 체크, 히스토리 관리를 하여 해외담당시 발생하는 리스크를 최소화
    하려고 했습니다.

    그리고 전달되는 정보가 부족한 경우, ex)버그확인시 스크린샷 및 로그, 덤프가 제대로 오지 않거나 재현률이 국내에서는
    힘들경우, 원격을 이용하는 경우도 있습니다.

    위에서 얘기했듯이 퍼블리셔에서는 한계가 있으니, 개발사에 몸담고 있으시면, 직접 담당국가에 대한 모든 사항을 체크하고
    처리하는게 맞다고 봅니다. 국내도 그렇지만 통역이나 커뮤니케이터의 경우도 게임을 QA보다 잘 알지는 못해서 놓치는 부분이
    정말 많더라구요..ㄷㄷㄷ

    저의 얘기를 잠깐 하자면, 개발/퍼블 한회사에 있던 회사도 다녀봤고, 대/중형 퍼블리셔와 일했던 개발사에도 일해봤고, 외국계개발사에서도 일해봤습니다. 셋중 하나에서 일하고 있고요. 이것저것 경험해 본봐로는. 개발사에 속해 있는 QA라면 다재다능하게 능력을 발휘하는게 제일 좋은것 같습니다.

    프로세스 개선능력을 키우는게 제일 중요할것 같아요. 그리고 퍼블리셔든 개발자든 친분 쌓기랑요.

    답이되었는지 모르겠네요. 그냥 제말만 주절주절 쓴것 같아서 ㅎㅎ