|
:: 게시판
:: 이전 게시판
|
- 경험기, 프리뷰, 리뷰, 기록 분석, 패치 노트 등을 올리실 수 있습니다.
통합규정 1.3 이용안내 인용"Pgr은 '명문화된 삭제규정'이 반드시 필요하지 않은 분을 환영합니다.법 없이도 사는 사람, 남에게 상처를 주지 않으면서 같이 이야기 나눌 수 있는 분이면 좋겠습니다."
16/01/13 18:08
1번 같은 경우 아이템 가격이 보통 퍼블리셔쪽에서 정하긴 하는데 대개 개발팀/개발사에서 가이드라인 정도는 줍니다. 개발팀과 퍼블리셔와의 파워게임에 따라 무게추가 한쪽으로 기우는 경우도 많긴 하지만요. imc 정도 되는 회사라면 어느정도 발언권이 있으리라 생각합니다. 아무리 영세한 개발업체에서 만든 게임이라도 적어도 퍼블리셔가 가격 책정한 후에 개발사/팀에게 컨펌 내지는 사전 조율정도는 하죠. 고로 개발팀에 10% 정도는 책임이 있다고 봅니다.
16/01/13 18:23
위에 언급드린 사업팀이 imc 사업팀을 말씀 드리는 거였어요, 사업팀과 개발팀에 구분이 없는 회사가 있는지(?)는 모르겠으나, 개발자가 얼마에 팔아야 해요라는 밸런스 조정은 없지 않나 생각이 들었습니다.
16/01/13 19:18
그게 좀 복잡하긴 한데.. 게임내 아이템 가격에 관한건 개발사내 개발팀(그중에서도 특히 기획팀과 PD) <-> 개발사내 사업팀 <-> 퍼블리셔 PM <-> 퍼블리셔내 운영팀 의 단계로 조율이 들어갑니다. 아예 개발팀이나 개발팀내 사업부에서도 신경 안쓰는 케바케는 있을수 있긴 하지만 적어도 퍼블리셔쪽 PM이 가격 책정을 이렇게 하겠다고 개발팀 PD나 개발팀 사업부에게 최종 결정 확인 정도는 받습니다.
16/01/13 20:02
맞습니다. 저도 착각했네요, 밸런스 조정은 개발 단에서 먼저 진행하는 경우가 있기도 하구요.
그냥 시간 날 때 틈틈히 적다 보니 잘못된 정보가 있었네요, 감사합니다.
16/01/13 18:09
쥐불놀이나 항아리는 개발자 100% 아니면 개발자 0%
둘중 하나라고 생각합니다. 테스트를 넘겼다는건 버그가 발생할 수 있다는 얘기고 그걸 발견 못한게 문제라고 보거나 아예 버그를 만든게 잘못이라고 봐야지 어정쩡하게 얘가 40, 얘가 60 이렇게 칠수는 없다고 봐요. 그리고 제 생각엔 항아리는 QA 잘못이 맞는거 같습니다. 발견하기 어려운 버그가 아니거든요. 사실 파이어볼도 계단밑으로 안굴러가는걸 생각하면 테스트시 모든 스킬을 경사로에서 사용해봤었어야한다고 봅니다.
16/01/13 18:24
파이어볼 이슈는 제가 알지 못해서 고려하지 못했습니다.
멸천도님 말씀 처럼 파이어볼 이슈가 있었다면 다른 스킬을 다 확인하는게 QA 업무 중 하나이죠. 명백하네요, 100 대 0... 그래도 팔은 안으로 굽는다고....90대 10 이정도나...
16/01/13 20:48
으음... 조심스럽게 언급드려 보자면 사실, 1번을 제외한 모든 사항은 "담당 작업자" - 그게 기획적인 부분이면 기획, 개발적인 부분이면 개발 - 의 책임인 게 맞습니다.
개인적으로는, QA에 책임을 묻는 게 무슨 의미가 있는지도 모르겠고, 해서는 안될 일이라고 생각합니다. 예를 들어 1. 매우 기본적인 사항에 대해 오류가 발생 - 기본적인 것도 테스트해보지 않고 커밋한 개발자/기획자(일반적으로 이런 부분은 개발자지만, 요청한 기획자나 버그만든 개발자나 그놈이 그놈) 잘못 - 그래도 이런 건 QA에서도 대부분 걸러지기 때문에, 그리고 이런 게 QA에서 리포팅되면 매우 창피해지고, 만약 작업 담당자가 막내라면 갈굼을 먹을 수도있는, 그리고 혼 좀 나야 될 사항이기도 합니다. 2. 특정 조건에서 오류가 발생 - 개발자가 업무 일정에 밀려 이런 저런 예외 사항에 대한 처리를 못했거나, 기획자가 개발 사항을 전달하면서 발생할 수 있는 예외 사항에 대한 처리 방침을 일러주지 않았을 가능성이 높습니다. - 이것도 역시, 꽤 많은 경우 QA에서 걸러지며, 이런 걸 업데이트 전에 찾아주면 개발자/기획자들이 매우 고마워합니다. 정말로요. 3. 테스트케이스가 방대하여, 사실상 전체 테스트가 불가능 - 예를 들면 스킬이 총 300개 정도가 되는데, 그 중 5개를 슬롯에 꽂을 수 있고 또 어떻게 꽂느냐에 따라 다 다른 조합의 스킬 효과가 발동...... 뭐 이런 식이라, QA 인력이 아무리 많더라도 사실상 모든 경우에 대한 테스트가 불가능하다면 + 거기서 결국 오류가 발생하고야 말았다면 이건 그걸 기획한 사람의 잘못입니다. - 보통 그렇겠지만 저런 경우, QA에서는 테스트 툴이나 테스트 방법에 대한 문의를 기획/개발에 하게 되는데, 이걸 귀찮다거나, 못만들어 주겠다거나 하게 되면 QA에서도 최후 통첩을 날리게 됩니다. "우린 못함. 그럼 걍 업뎃하던가" 그리고 그 결과가...... 아시다시피.... 유일하게 QA의 잘못이라고 말할 수 있는 건 QA가 직접 작업하는 일들 - 운영툴을 이용한 이벤트 세팅 미스라던가, 이벤트 아이템 중복 지급, 유저응대 미숙, 게시판 관리 미숙, 공지에 비속어 사용, 아니면 운영자 캐릭터로 실수로 마을에 보스를 소환한다던가 하는... - 정도지, 그 외의 게임 컨텐츠에 대해서는 QA을 탓할 이유도, 필요도 없다고 생각합니다. 노파심에 쓰자면.. 저는 QA쪽 사람이 아니며 굳이 따지자면 QA 분야에서 일하시는 분들께 늘 고마워하는 사람입니다.
16/01/14 10:11
개발의 실수 = 버그의 생성
QA의 실수 = 버그를 못 찾음 라고 할때 우리가 버그를 발견하는건 QA를 거쳐온거라고 생각해야합니다.(패스 했든가) 말씀하신대로 담당자 100% 잘못이라고 한다면 QA의 업무는 극단적으로 줄어들게 됩니다. QA를 쓰는 이유도 '버그가 있는건 알지만 어디에 있는지 몰라서'입니다. -QA가 검수하는 게임의 품질 요소는 다양하다. ‘버그’(Bug)를 찾아내는 것부터 시작해, 특정 구간이 너무 어렵다거나 게임 기획자(Game Designer)가 의도한대로 동선이 흘러가지 않는 등의 ‘레벨 디자인’(Level Design)의 문제점을 찾아내기도 한다. 그 외 게임 출시 후 위험요인이 될 만한 문제점들을 찾아내기도 하며, 수정된 사항이 제대로 적용되었는지의 여부도 QA가 검수하게 된다.- 출처 : [네이버 지식백과] QA [Quality Assurance] (게임용어사전: 기관/용어, 2013. 12. 12.) 뭐 다만 현 트오세 상황상 QA를 제대로 못돌리고 있다고 보는게 더 맞을꺼같긴 합니다. 클베를 거치고 거기서 나온 의견도 반영이 안되는걸 보면 아무래도 QA인력을 떠나서 개발인력자체가 부족한거같은...
16/01/14 11:44
음, 담당자 100% 잘못이라고 해도 QA의 업무는 변하지 않습니다. 말씀하신대로 버그를 찾는 건 QA의 기본 중의 기본 업무이지요.
다만 현업에서는 버그를 발견하지 못했다고 해서 그게 QA를 문책할 일은 아니라는 이야기입니다. 좀 극단적으로, 해고당할만한 버그 - 예가 안맞을 순 있겠지만 최근 이터널 클래시 이슈 급이라고 생각해 보죠 - 가 게임에 터졌다고 생각하면, 회사 입장에서는 QA에 책임을 묻지 않고 어쨌든 해당 작업을 담당한 기획자나, 개발자에게 책임을 묻게 됩니다. 물론 QA 조직 내에서도 작성된 테스트케이스를 제대로 확인하지 않은 정황이 확인되면 담당자에게 문책할 수 있겠지만, 적어도 제가 알고 지냈던 QA분들은 테스트케이스를 건너뛰시는 분들은 못 봤습니다. 뭐 그런데 써놓고 보니 이건 어디까지나 현업 이야기, 더군다나 제가 경험한 아주 작고 작은 국내 회사 한정이고; 어디까지나 유저 입장에서 느끼는 건 다를 수도 있겠네요 + 회사마다 방침이 다를 수도 있겠네요.
16/01/14 12:07
이터널 클래시 이슈라면 개발자나 기획자의 '의도'가 들어있었던 문제니 당연히 해당 담당자를 문책하는게 맞는겁니다.
제가 얘기하고자하는건 개발자의 실수 = 버그 QA의 실수 = 버그를 발견 못함 이 둘다 일어나지않으면 소비자에게 발견되지않습니다. QA의 업무는 소비자에게 발견되지않도록 미연에 버그를 발견하는 것이며 개발자의 업무는 버그가 나지않도록 프로그램을 잘 짜는거겠죠. 위에 쥐불놀이나 항아리를 100%로 잡은이유는 쥐불놀이의 경우 어느정도 기획의 의도가 있었다고 보여지고 항아리는 파이어볼, 장판스킬등 많은 스킬들이 이미 경사로에서 제대로 동작하지않기때문에 이부분은 특이점으로 판단하고 더 엄격하게 테스트를 했어야한다고 보기때문입니다. 뭐 사실 클베때도 경사로 장판같은건 얘기가 좀 있었던건데.... 그걸 생각하면 QA도 QA지만 윗선에서 그냥 강행한게 현재 트오세 사태를 불러온게 아닐까 싶습니다. 암튼 제 생각을 정리하면 'QA의 기본 업무는 버그 찾기인데 못찾았다고 문책을 받지않으면 QA는 왜 있는가?' 이거 입니다. 물론 이 얘기가 개발자의 실수가 사라진다거나 책임이 면해진다는 얘기는 결코 절대 아닙니다.
16/01/14 10:44
계란님 말씀이 맞습니다.
저도 이 글을 써보면서 가장 조심한 것이 회사 업무 프로세스를 다 밝힐 수 없을 거고, 그게 다른 회사랑은 또 어떻게 다를지 모르다보니 정말 기초적이면서 기본적인 얘기를 하게 됐고, 그게 오히려 정보 전달이 부족해져 버린 것 같습니다. 지금 댓글 달린 내용들이 오히려 전문지식들이 있으신 분들 댓글이 더 많아 당황 중입니다. 크크
16/01/13 21:48
버그의 경우에는 무조건 QA 와 사업의 책임이 들어가야 한다고 생각합니다. (둘의 책임이 100% 라는 이야기는 아니고, 지분이 얼마이던 모든 버그의 책임 논란에서 자유로워 질 수 없는 두 개 포지션이라고 생각해요)
사업은 누구보다도 가장 프로젝트를 잘 알고 있으면서 결국 모든 결정과 책임을 지어야 하는 포지션이기 때문이고, QA에서 sign off 했다는 건 말 그대로 이 프로젝트의 품질을 검증했다 라고 책임을 이미 진거고, 버그 발생 이후에도 책임을 져 f/u 을 해야 하는 직군이니까요. 어떤 상황이나 오류를 발생시킨 부분에 따라 지분율은 달라질 수 있지만, 기본적으로 저 두 포지션은 항상 최소한이라도 지분율이 포함되어 있어야 된다고 생각합니다.
16/01/14 10:46
하지만 최근 싸인오프를 QA가 하지 못하는 게임 회사들이 늘어나고 있습니다.
개발 속도가 서비스 속도(컨텐츠 소모 속도)를 따라가지 못하다보니 사업이나 개발단에서 알아서 리스크를 판단하고 있다는 얘기가 종종 들리더라구요. QA는 일반적으로 검증을 통해 싸인오프하는 조직이라는 인식이 널리 퍼져 있다보니, 싸인 오프 권한 없이 문제 생기면 욕먹는 억울한 QA 조직이 좀 있다고 하네요.
16/01/16 00:39
싸인오프를 QA가 하지 못하는 게임 회사들이 늘어나고 있습니다. < 문구에 적극 공감합니다.
모바일게임으로 대세가 넘어온 이후, 컨텐츠 소모속도가 기하급수적으로 빨라지면서 발생한 현상같습니다. 게다가 최근 중국산 게임이 많아진것도 한몫한다고 봅니다. 중국어가능+QA능력을 모두 갖춘 인력이 업계에 많지가 않지요. 저는 QA는 아닙니다 -_-)
16/01/13 22:07
저도 동종 업계에서 일하고 있지만, 개발사인 아이엠씨게임즈의 내부사정도 모르고 QA 책임을 말하기엔 너무 성급하다고 생각합니다.
일정과 자본에 급급해 적절한 인력배치가 되지 못하는 경우를 여러번 봐서요. 팀내 어제 본 유게의 IT지원팀의 일상 중에서 '왜 IT팀을 쓰는지 모르겠다'라는 말이 생각나네요. support팀에 대한 평가는 조직 전체와 연계해서 봐야한다고 생각합니다.
16/01/14 10:47
서두에서 말씀 드렸다 싶히 지금 우리 회사에서 트오세를 서비스 중이라면, 이라는 가정 이고
IMC나 넥슨에 책임을 묻자는 글이 아니었습니다.
16/01/14 07:23
QA가 책임이 없는건 아닌데 이정도로 심한 숫자의 버그들이라면
A : "아 이거 이문제 있고 저문제 있고 처리해야됩니다." B : "야 시끄러! 우리이거 일단 빨리 오픈해야되는거 몰라? 강행한다! 대충 심한거 아니면 하면서 고치면 되잖아!" A랑 B가 누구지는 잘 아실듯.
16/01/14 09:45
글쎄요. 사업 부분이 책임져야 되는것은 유료화 과금모델부터 마케팅, 이벤트, 업데이트 일정조율등 여러가지가 있겠지만
버그 문제에 대해서는 논외로 봐야 된다고 생각합니다. 운영도 제외해야겠죠. 운영적인 실수부분이 아니라고 한다면요. 출석체크 같은 오류 문제는 웹이랑 연동되는 경우 웹팀이나 연결된 DB문제일수도 있고요. 그걸 테스트 하고도 발견 못한 운영과 QA가 어느부분 책임이 있을수도 있겠죠. 그외 게임내 버그건은 QA와 개발이 동일하게 50:50 비율이라고 생각합니다. 상대적 이론이겠지만 원래 버그 100개 있던것을 QA에서 99개를 잡고 나머지 1개를 못잡아서 나온 버그가 지금 우리가 보고 있는 결과물일수도 있습니다. 반대로 버그 없다고 검수 통과 시켜놓고 버그가 터지면(거의 버그는 업데이트마다 어느 게임이던 터지는거 같습니다.) QA 잘못 비율이 높을수도 있고요. 하지만 먼저 1차적으로 개발팀에서 개발뒤 테스트하고 컨텐츠 부분 확인뒤 QA에 넘어가게 됩니다. 버그를 만드는것은 QA가 아니라 개발입니다. 그리고 그걸 책임지고 검수해야되는 QA도 획기적이거나(?) 상상하지 못했던 방법으로 버그가 발생하는 경우가 많기에 검수 제대로 못한 QA라고 보기는 어렵죠. 개발도 그렇고요. 양비론이지만 게임내 버그 발생 책임에 대해서 이야기 하자면 그냥 둘이 사이좋게 50:50 이 가장 적당하다는 생각입니다.
16/01/14 10:51
계란님과 미고띠님 코멘트에 대댓글 남겼는데,
최근 사업 단계에서 싸인오프를 하는 경우가 종종 있다고 합니다. QA에서는 우려를 이미 전달하였으나, 그를 무시하고 나서 발생되는 문제도 꽤 있다는 것이겠죠. 그래서 이젠, 버그에서 사업팀을 아예 논외로 하면 안된다는 의견 이었습니다. 사실 버그가 나와서 책임을 어디에 묻는게 중요할까요, 고객들은 게임을 못즐겼고, 개발사는 버그로 인해 임시 점검, 정기 점검 들어가 엄청난 손해를 내고 있고 (임시 점검 1회에 손실액을 여기에 커뮤니티에 공개할 수는 없으나...) 서로가 조금 더 잘 챙겼으면... 이라는 아쉬움으로 써본 글입니다. (하지도 않는 게임이면서?)
16/01/16 22:34
테스트 케이스 또는 체크리스트라고 부르기도 하구요.
QA가 테스트할때 사양 명세서 기반으로 체크해야 하는 항목들이라고 생각해 주시면 될것 같습니다.
16/01/17 02:48
모바일 시장의 특수성으로 인해, 모바일 게임에서는 사업의 영향력이 강한 경우가 많은데..
PC 게임에서 이정도로 일들이 터지는걸 보면 IMC가 얼마나 급한지 알 수 있죠.. 이정도로 터지는건 개발/QA/운영/사업 모두 동의하고 가는 겁니다..어쩔 수 없다, 당장 죽게생겼다..이런 신호죠 뭐
|
||||||||||