[짧QA] 15장. 기능 QA에서 데이터(Data)를 무시하면 반드시 사고가 난다

기능 QA를 하다 보면
이런 말을 종종 듣게 된다.

“기능은 정상인데요?”
“화면도 문제 없고요.”

그런데도
문제가 발생한다.

• 보상이 중복 지급되거나
• 진행도가 갑자기 초기화되거나
• 특정 유저만 이상한 상태에 빠진다

이때 문제의 원인은
대부분 기능이 아니다.

데이터다.

---

기능 QA를
화면 단위로만 이해하면
데이터는 항상 뒤로 밀린다.

• 보상은 나왔으니까 OK
• 값은 들어갔으니까 OK
• 다음 화면으로 갔으니까 OK

하지만 QA가 진짜 봐야 할 것은
“보였다”가 아니라
**“어디에, 어떤 형태로, 어떤 값이 남았는가”**다.

---

데이터는
기능의 결과물이 아니다.

데이터는
기능의 흔적이다.

• 이 기능이 실행되었다는 증거
• 이 상태가 유지된다는 근거
• 이 선택이 되돌릴 수 없다는 기록

QA가 기능을 테스트하면서
데이터를 보지 않는다는 것은
결과를 확인하지 않는 것과 같다.

---

예를 들어 보자.

퀘스트 완료 기능이 있다.

• 조건 충족
• 완료 버튼 클릭
• 보상 지급

기능 테스트만 보면
문제 없다.

하지만 QA는
여기서 반드시 데이터를 본다.

• 퀘스트 완료 플래그는 언제 저장되는가
• 보상 지급과 완료 플래그는 동시에 처리되는가
• 중간에 실패하면 어느 쪽이 남는가

이 질문에 답하지 못하면
이런 문제가 생긴다.

“보상은 받았는데 퀘스트가 다시 떠요.”
“퀘스트는 완료됐는데 보상이 없어요.”

이 문제는
기능 테스트로는
절대 잡히지 않는다.

---

기능 QA에서
데이터를 무시하면
문제가 항상 늦게 터진다.

• 재접속 이후에
• 다음 날 접속했을 때
• 다른 콘텐츠를 진행한 뒤에

그래서 이런 말이 나온다.

“그때는 괜찮았어요.”

맞다.
그때는 괜찮았을 수 있다.

데이터는
시간을 두고 문제를 만든다.

---

숙련된 QA는
기능을 테스트할 때
항상 데이터 흐름을 같이 본다.

• 이 값은 언제 생성되는가
• 이 값은 어디에서 참조되는가
• 이 값은 어떤 트리거로 변경되는가
• 이 값이 꼬이면
  어떤 기능들이 영향을 받는가

이 질문을 하지 않으면
QA는
기능만 보고 시스템은 보지 못한다.

---

데이터 QA가 어려운 이유는
눈에 보이지 않기 때문이다.

버그는
화면에 나타난다.

데이터 문제는
증상으로만 나타난다.

• 갑자기 진행이 막히거나
• 특정 조건에서만 이상해지거나
• 유저마다 결과가 달라진다

이 증상만 보고
기능을 의심하면
원인은 계속 엇나간다.

---

그래서 기능 QA에서
데이터를 본다는 말의 진짜 의미는 이것이다.

“이 기능이
어떤 데이터를 만들고,
그 데이터가
어디까지 영향을 미치는가.”

이 관점이 없으면
QA는
같은 문제를
다른 기능에서
계속 다시 잡게 된다.

---

데이터는
상태(State)의 실체다.

• 상태가 꼬였다는 말은
  데이터가 꼬였다는 뜻이고
• 재현이 안 된다는 말은
  데이터 경로를 놓쳤다는 뜻이다

그래서
상태·트리거·경계값 이야기가
결국 데이터로 귀결된다.

이 연결을 이해하지 못하면
QA는
항상 증상만 쫓는다.

---

정리하자면 이렇다.

기능 QA는
화면을 확인하는 일이 아니다.

기능 QA는
데이터가 어떻게 생성되고,
어떻게 남고,
어떻게 다시 사용되는지를
끝까지 따라가는 일이다.

데이터를 보지 않는 QA는
항상 이렇게 말하게 된다.

“왜 이런 문제가 생겼는지 모르겠다.”

데이터를 보는 QA는
문제가 터지기 전에
이미 그 경로를 알고 있다.

이 차이가
기능 QA의 수준을 가른다.