인디게임 테스터 서버

테스트 서버가 제대로 굴러가려면 개발자와 테스터가 같은 버전을 보고 있어야 합니다. 이게 어긋나면 제보가 전부 쓸모없어지죠. 이 설계도가 빌드를 독립 카테고리로 뽑은 이유가 그것입니다.

빌드가 바뀌면 옛 버전 제보가 쏟아집니다

빌드가 바뀔 때마다 알리지 않으면 옛 버전으로 테스트합니다. 활성화봇에 버전을 띄우세요.

/공지 로 현재 빌드 번호와 배포일을 임베드에 담아 고정하시고, 새 빌드가 나오면 그 글을 갱신하세요. 채널 맨 위에 늘 최신 버전이 보이면 제보에 엉뚱한 버전이 섞이지 않습니다.

버그 제보 양식에 버전 번호 칸을 넣으세요. 이게 없으면 고친 버그가 계속 올라옵니다.

패치노트를 짧아도 쓰세요

테스터는 뭐가 바뀌었는지 모르면 같은 곳만 봅니다. 새로 손댄 부분에 버그가 가장 많은데 말이죠.

패치노트에 「이번에 바뀐 것」과 **「특히 봐줬으면 하는 것」**을 적어두세요. 후자가 테스트 효율을 크게 올립니다.

비밀유지 채널이 이 설계도의 핵심입니다

출시 전 게임의 내용이 새면 개발사에 실제 피해가 갑니다. 그래서 이 채널이 맨 앞에 있어야 합니다.

• 스크린샷·영상 외부 공개 금지 범위를 명확히
• 어디까지 말해도 되는지 — 존재 자체를 비밀로 하는 경우도 있습니다
• 언제 풀리는지 — 출시일인지, 별도 공지인지

서약을 받으실 거면 참여신청 단계에서 받으세요. 빌드를 받은 뒤에는 늦습니다.

그리고 미성년자 참여라면 보호자 동의가 필요할 수 있습니다. 법적 효력이 걸린 서약이니까요.

모집공고가 포럼인 것을 살리세요

모집공고가 포럼입니다.

테스트 한 건에 기간·플랫폼·요구 사양·보상이 붙고 지원이 댓글로 쌓입니다.

보상을 명확히 적게 하세요. 무보수인지, 게임 키를 주는지, 크레딧에 올리는지요. 안 적으면 나중에 서운함이 남습니다.

요구 사양도 꼭 적으세요. 사양이 안 되는 사람이 참여하면 「이게 원래 느린 건지 내 컴퓨터가 느린 건지」를 구분 못 합니다.

버그제보가 포럼인 것이 정확합니다

버그 카테고리에 버그제보·재현·처리현황이 있고, 버그제보가 포럼입니다.

버그 하나는 제보하고 재현하고 고쳐지는 과정을 거칩니다. 제보 하나가 그 셋을 다 담고 있어야 합니다.

제보 양식을 고정해두세요. 무엇을 했을 때 / 무엇이 일어났고 / 무엇을 기대했는지 세 줄이면 개발자가 바로 씁니다. 「버그 있어요」는 아무 도움이 안 됩니다.

태그를 재현 가능 / 재현 안 됨 / 수정됨으로 만드세요.

재현 채널이 버그헌터의 자리입니다

제보된 버그를 다른 사람이 따라 해보는 것이 재현입니다. 한 사람에게만 나는 문제인지를 그때 구분합니다.

이게 개발자의 시간을 가장 많이 아낍니다. 재현이 안 되는 버그를 쫓는 것만큼 낭비가 없거든요.

처리현황 채널에는 고쳤는지 아닌지를 남기세요. 제보한 사람이 반응을 못 받으면 다음부터 안 합니다.

피드백 카테고리를 버그와 나눈 판단

버그는 고쳐야 하는 것이고 피드백은 판단할 것입니다. 성격이 완전히 다릅니다.

섞이면 개발자가 「이건 버그가 아니라 의도한 건데」를 계속 설명하게 됩니다.

아이디어 채널에는 채택 여부를 개발자가 밝히는 문화를 만드세요. 아무 반응이 없으면 제안이 끊깁니다. 「좋은데 지금은 못 한다」도 답입니다.

대기자 역할을 열어두세요

역할에 개발자·버그헌터·테스터·대기자가 있습니다.

대기자는 다음 테스트를 기다리는 사람입니다. 테스트는 인원이 정해져 있어서 못 들어온 사람이 생기거든요.

이 자리가 있으면 그 사람들이 남습니다. 다음 회차 모집이 훨씬 쉬워져요.

버그헌터는 제보를 꾸준히 하는 사람입니다. 개발자에게는 가장 값어치 있는 사람이니 드러내 주세요.

다른 봇을 쓰시더라도 현재 빌드 번호를 늘 보이게 두는 것이 제보 품질을 정합니다.