[짧QA] 22장. 업데이트 QA는 ‘기존 기능 확인’이 아니다

업데이트 QA를 이야기하면
이런 이야기가 들려온다.

“기존 기능만 다시 보면 되죠.”
“변경된 부분 위주로 확인하면 되잖아요.”

이 말들은
효율적으로 들린다.
그리고 대부분의 사고는
이 말에서 시작된다.

업데이트는
기능을 조금 바꾸는 일이 아니다.

업데이트는
이미 쌓여 있던 모든 상태 위에
새로운 조건을 얹는 일이다.

---

업데이트 QA가 어려운 이유는 단순하다.

• 기존 데이터가 있고
• 기존 상태가 있고
• 기존 유저 행동 패턴이 있다

이 위에
새 코드와 새 규칙이 올라간다.

문제는
이 조합이
테스트 환경에서는
절대 그대로 재현되지 않는다는 점이다.

---

업데이트 QA에서
가장 흔한 착각은 이것이다.

“신규 기능은 정상입니다.”

신규 기능이 정상이어도
문제는 발생한다.

왜냐하면
대부분의 업데이트 이슈는
신규 기능이 아니라
기존 것과의 충돌에서 발생하기 때문이다.

---

예를 들어 보자.

기존 퀘스트 구조 위에
신규 보상 시스템이 추가되었다.

• 신규 유저는 문제 없다
• 테스트 계정도 문제 없다

하지만
기존 유저에게서
이런 문제가 나온다.

• 이미 완료한 퀘스트가 다시 뜬다
• 보상이 중복 지급된다
• 진행도가 꼬인다

이건
기능 문제가 아니다.

업데이트가 기존 상태를
어떻게 해석했는지의 문제다.

---

업데이트 QA에서
QA가 가장 먼저 해야 할 질문은 이것이다.

• 이 업데이트는
  기존 데이터를 어떻게 처리하는가
• 이전 상태를
  그대로 유지하는가, 변환하는가
• 변환 과정에서
  예외는 없는가

이 질문을 하지 않으면
업데이트 QA는
표면 확인으로 끝난다.

---

업데이트는
한 번만 적용되지 않는다.

• 핫픽스
• 마이너 패치
• 이벤트 업데이트
• 대형 업데이트

이 변화들이
누적된다.

그래서 업데이트 QA는
항상 이렇게 질문해야 한다.

• 이 변경은
  다음 업데이트에 어떤 영향을 주는가
• 되돌릴 수 있는가
• 중간 버전을 건너뛰면
  문제가 생기지 않는가

이 질문이 없으면
프로젝트는
스스로 퇴로를 막는다.

---

업데이트 QA에서
테스트 환경이
항상 위험한 이유가 있다.

테스트 환경은
깨끗하다.

• 데이터가 정리되어 있고
• 상태가 단순하며
• 유저 히스토리가 없다

실제 라이브 환경은
절대 그렇지 않다.

QA는
이 간극을
머릿속으로 채워야 한다.

---

그래서 숙련된 QA는
업데이트 QA에서
이런 테스트를 만든다.

• 오래된 계정
• 중간에 이탈했다 돌아온 계정
• 특정 이벤트를 경험한 계정

이 계정들은
문제를 만든다기보다
문제를 숨기지 않는다.

---

업데이트 QA에서
또 하나 중요한 개념이 있다.

되돌릴 수 없는 변화다.

• 데이터 구조 변경
• 상태 값 통합
• 보상 로직 변경

이 변화는
한 번 적용되면
되돌릴 수 없다.

QA는
이 지점을
반드시 표시해야 한다.

• 여기서 문제 생기면
  롤백이 불가능하다
• 여기서 꼬이면
  수동 복구가 필요하다

이 경고는
QA의 역할이다.

---

업데이트 QA는
“문제 없었습니다”로 끝나면 안 된다.

QA가 남겨야 할 것은
이것이다.

• 어떤 상태에서 위험한지
• 어떤 데이터가 영향을 받는지
• 어떤 유저가 가장 먼저 겪을지

이 정보가 있어야
운영은 대응할 수 있다.

---

정리하자면 이렇다.

업데이트 QA는
기존 기능을 다시 보는 일이 아니다.

업데이트 QA는
과거와 현재가
어디서 충돌하는지를
찾아내는 일이다.

이 관점을 놓치는 순간,
업데이트는
가장 큰 비기능 리스크가 된다.