게임 테스트가 끝난 후의'회고'와'품질 분석'이 매우 중요하다.

1. 시작
게임 테스트를 진행할 때
새로 발표할 때도 힘들었는데 운영에 들어가면 더 힘든 경험이 있나요?
운영 타이틀도 운영 시간이 길어졌어요.
"매번 조치를 실시할 때마다 고장이 끊임없이 증가하고 있다."
"여기에도 같은 문제가 있겠지."
여러분들도 그런 생각을 하셨을 거라고 생각합니다.
이번에는 이런 점에 대한 테스트 후의 회고와 품질 분석이 얼마나 중요한가
말할 수 있었으면 좋겠어요.
2.무엇을 위한 것인지 돌아본다
우선 "돌이켜보면 무엇을 위한 것일까?"
일반적으로 말하면
[언행과 경향을 객관적으로 파악하고 다음 개선점에 대해 조사하고 개선점을 실시한다.]
여기다
게임 개발 프로젝트로서의 회고
KPI와 DAU 등의 정보에서 다음에 어떻게 해야 할지 등 개선점을 객관적으로 찾아내다
실행할 수 있을 것 같습니다.
그렇다면 시험의 회고는 어떻게 진행되었을까
다음 몇 가지를 토론하고 다음에 계속 연락합시다.
• 테스트 중 발생한 문제점
- 문제가 발생했을 때 어떻게 행동해서 대책을 세웠는지
- 테스트에 미치는 영향
- 다음 대책
예컨대
설치 지연, 테스트 일정 단축
이런 문제가 발생했다.
이벤트 발생 시 임시 대응 필요
· 인원 증가 대응
• 일정 조정
나는 이런 조치를 취할 가능성이 있다고 생각한다.
다만, 우리가 발생한 후에 어떻게 대응해야 하는가
이런 일이 없도록 하기 위한 대책은 아니다.
이런 상황을 막기 위해서는 대책을 논의하는 것이 회고의 장으로 효과적이다.
나는 문제가 발생하지 않도록 하는 것이 매우 어려운 과제라고 생각한다.
이런 상황에서 발생 빈도를 낮추기 위해서는 어떻게 해야 하는가
노력할 필요가 있다.
이런 예에서
같은 문제가 발생할 때마다 회고하지 않는다
근무 시간이 촉박하고 초조하면 테스트 오류를 초래할 수 있다.
또 인원 증원, 초과 근무 등도 발생하면 여분의 원가가 발생한다
결과적으로 부정적인 연쇄 반응이 생겼다
나는 회고할 필요가 있다고 생각한다.
단, 문제점만 토론하지 마라
어떤 곳이 비교적 좋은지 토론할 필요가 있다.
다음 번에는 어떻게 그 좋은 일을 이어갈 수 있을까
더 좋은 순환이 생길 가능성이 있다.
3. 품질분석은 무엇을 위한 것이고 무엇을 위한 것인가
다음은 품질 분석입니다.
여기도 고개를 돌릴 때와 같은 부분이 있어요.
품질 분석을 사용하여 각 조치의 불량 경향을 파악하다
테스트 범위 재평가, QA 측면에서 개선해야 할 점, 개발 측면에서 개선해야 할 점.
품질 분석은 다음과 같은 정보 등을 사용한다.
· 테스트 중 발생한 고장 수량(등급별, 기능별)
• 장애 발생 원인 (장애 범주)
예컨대
총 100건의 고장이 발생했다고 가정하면
다만 이 메시지는 지난번보다 고장 수가 많고 적음을 판단할 수 있다
앞으로 효과적으로 활용할 수 있는 수치로는 약한 상태다.
그렇다면 불합격 등급에 따라 다음 수치를 표시하는 경우는 어떨까?

아까보다 중요도를 알게 된 고장수.
왜냐하면 어떤 기능에 무슨 고장이 났는지 몰라요.
나는 정보가 부족하다고 생각한다.
상술한 정보 외에도 다음과 같이 고장 종류의 정보를 대조해 보는 것은 어떻습니까?

이것으로 각 등급에 무슨 불합격의 원인이 있는지 알 수 있다
나는 경향을 쉽게 파악할 수 있다고 생각한다.
그리고 하나

위에서 말한 바와 같이 각 기능에 따라 불합격 유형에 따라 합계하다
어떤 고장 원인이 어떤 기능으로 인해 대량으로 발생했는지 확인할 수 있다
개선을 향한 회고를 할 수 있다.
상술한 예를 분석한 후
· 메인 사이트 설정 오류가 전체의 3할 이상을 차지
· 주설 오류 중 큰 문제로 발전할 수 있는 비용
[트위스트 기능][점포 기능]에 문제가 많은 상태입니다.
· 불합격 레벨은 【B】일 수 있습니다
비용과 관련된 부분이기 때문에 시험의 입도로서 계속 상세하게 확인해야 한다
• 매번 같은 고장 경향이 발생할 때마다 개발의 운용 절차에 문제가 있을 수 있음
잠깐만, 나는 매우 큰 예를 들 수 있다고 생각한다.
이 내용을 보면 회고와 마찬가지로 다음에 이런 위험을 줄이기 위해 무엇을 할 수 있는지 토론한다
나는 실제 행동을 통해 초기의 품성을 높일 수 있다고 생각한다.
4. QA 담당자의 회고뿐만 아니라 개발자의 회고도 중요하다
이전 항목에 앞서 QA 내 검토, 품질 분석 등을 사용합니다.
QA 내에서 어떻게 다음 움직임을 일으켜 개선에 힘쓰는 내용이 됐다.
그렇다면 QA의 문제점에 대한 조사와 개선 대책이 그것만으로도 가능할까.
QA 담당자와만 상의하면 QA 측 차원에서만 대화를 할 수 있습니다.
객관성을 조성할 수 있다.
또 개발 담당자가 어떻게 생각하는지, 또 어떤 문제를 안고 있는지 알 수 없는 상태가 될 수 있다
QA 담당자와 개발 담당자도 돌아볼 필요가 있다.
쌍방의 대응을 통해 문제점을 더욱 깊이 있게 개선하고 내용을 대응할 수 있다
같은 문제가 발생하지 않도록 서로 협력해야 한다.
5. 마지막
일률적으로 회고하고 품질 분석을 한다고 하지만.
나는 목적을 명확히 한 후에 무엇을 해야 할지 진행할 필요가 있다고 생각한다.
목적을 정하는 등 무엇을 위해 이런 코디를 하느냐에 따라 항목마다 다를 수 있다
그중에서 본 보도에서 공감할 수 있는 것은
그리고 참고할 게 좀 있으면 좋겠어요.