검증

빈 칸입니다. 여기 적힌 건 「이 칸이 채워졌다고 말하려면 무엇이 있어야 하는가」뿐입니다.

조건 — 「통과가 무엇을 뜻하는지 한 문장으로」

이 칸의 합격 조건입니다.

테스트가 통과했을 때 그게 무엇을 뜻하는지 한 문장으로 말할 수 없으면, 그건 아직 검증이 아닙니다.

「테스트 100개 통과」는 좋아 보이는데, 그래서 뭐가 보증되는지 말할 수 없으면 아무 의미가 없습니다.

넘어오는 것 하나 — 「0이 두 가지를 뜻하면 안 됩니다」

값을 치르고 배운 것입니다.

결과가 0으로 나왔다고 해 봅시다. 두 가지일 수 있습니다.

실제	화면
검사했는데 문제가 없음	0
검사 자체가 안 돎	0

둘이 똑같이 보입니다. 그리고 좋은 소식처럼 보입니다.

이게 제일 위험한 종류의 착각입니다. 고장 났는데 합격으로 읽힙니다.

그래서 갈라야 합니다.

• 검사했고 문제 없음 → 「0건 (검사 12개 실행)」
• 검사가 안 돎 → 「실행 안 됨」 — 0이 아님

「없음」과 「안 셌음」은 다른 값이어야 합니다.

넘어오는 것 둘 — 「오류 없이 통과」는 「제대로 동작함」이 아닙니다

두 번째로 배운 것입니다.

프로그램을 만들면 오류 없이 빌드되는 것과 실제로 켜서 제대로 도는 것은 다릅니다.

	무엇을 보증하나
오류 없이 통과	문법이 맞음
켜서 돌려 봄	의도대로 동작함

앞엣것을 뒤엣것으로 착각하는 일이 자주 생깁니다. 특히 오류가 안 나면 다 된 것 같은 기분이 들어서요.

그런데 오류 없이 아무 일도 안 하는 코드를 쓰는 건 아주 쉽습니다.

정적으로 통과했다는 건 「깨지지 않았다」이지 「동작한다」가 아닙니다.

다시 정해야 하는 것 — 「무엇이 결함인가」

이건 게임마다 답이 다릅니다.

같은 현상이 어떤 게임에서는 버그고 어떤 게임에서는 기능입니다.

현상	이 게임에서는
캐릭터가 벽을 통과함	보통은 버그 / 벽 통과가 기술인 게임에서는 기능
적이 갑자기 멈춤	보통은 버그 / 경직 연출이면 기능
화면이 잠깐 멈춤	보통은 버그 / 타격감 연출이면 기능

그래서 「무엇이 결함인가」를 먼저 정하지 않으면, 테스트가 정상 동작을 버그로 신고하거나 진짜 버그를 정상으로 넘깁니다.

그리고 이건 기획이 정해야 하는 것이지 테스트가 정할 게 아닙니다.

여기부터는 자세한 기록입니다

⚠ 이 글은 미래 게임 1의 QA와 같은 글이다. 두 칸이 아직 다를 근거가 없어서 지어낸 차이를 적지 않았다.

빈 칸이다. 여기 적힌 건 이 칸이 채워졌다고 말하려면 무엇이 있어야 하는가뿐이다.

넘어오는 것 1 — 0이 두 가지를 뜻하면 안 된다

무협 게임의 검증에서 나온 규칙이고, 이 스튜디오에서 본업 파이프라인으로 실제로 넘어간 것이다.

“찾은 게 없다”와 “찾을 데가 없었다”가 같은 0으로 나오면, 그 테스트는 고장을 통과시킨다. 세는 값과 대상 개수를 따로 내보내고, 대상이 0이면 통과가 아니라 설정 오류로 뜨게 만든다.

넘어오는 것 2 — 정적 통과는 작동 증명이 아니다

파일을 읽어 “고쳤다”고 보고하면 안 된다. 화면 결함은 찍어서, 동작 결함은 실제로 돌려서 판정한다. 하네스가 통과했는데 씬 배선이 비어 있어 실물은 안 돌던 일이 있었다.

다시 정해야 하는 것 — 무엇이 결함인가

무협 게임에서 “전조를 읽을 시간이 없다”는 결함이다. 다른 게임에선 그게 의도일 수 있다. 결함의 정의가 게임마다 바뀌므로, 통과 기준을 먼저 한 문장으로 쓰고 시작한다.