[짧QA] 17장. 기능 QA를 망치는 가장 흔한 착각들

기능 QA를 오래 하다 보면
이상하게 반복되는 장면들이 있다.

QA 개인의 역량과는 상관없이
같은 실수가
같은 형태로 되풀이된다.

이 장은
그 실수들을 나열하기 위한 장이 아니다.

왜 그 실수가 생기는지,
그리고 어디서부터 QA가 흔들리는지를
정리하기 위한 장이다.

---

착각 1. 기능 QA는 많이 할수록 좋다

기능 QA를 처음 맡으면
대부분 이렇게 생각한다.

“최대한 많이 테스트해야 한다.”

이 생각 자체가
완전히 틀린 것은 아니다.
문제는 이 생각이
QA의 기준이 되는 순간이다.

테스트의 양이 늘어날수록
QA가 놓치는 것은
테스트 대상이 아니라
판단의 밀도다.

많이 테스트하는 QA보다
위험한 지점을 정확히 고르는 QA가
프로젝트에 더 큰 가치를 만든다.

---

착각 2. 기능은 기능 단위로 끝난다

기능 QA를
버튼 단위, 화면 단위로 나누는 순간
QA는 시스템을 잃는다.

• 이 버튼은 어떤 상태에서만 눌려야 하는가
• 이 화면은 이전 어떤 기능의 결과인가
• 이 기능의 실패는 어디까지 영향을 미치는가

이 질문이 빠지면
기능 QA는
항상 부분만 본다.

기능은
항상 다른 기능의 결과이자 원인이다.

이 연결을 놓치는 순간,
QA는
같은 문제를
다른 화면에서 다시 만난다.

---

착각 3. 정상만 확인해도 기능 QA는 충분하다

정상 흐름을 확인하는 것은
기능 QA의 출발점이지
목표가 아니다.

정상만 확인한 기능 QA는
항상 이렇게 끝난다.

“정상입니다.”

하지만 QA가 책임져야 하는 것은
정상이 아니라
정상이 무너질 때의 결과다.

정상 흐름을 이해하지 못하면
예외는 보이지 않는다.
그리고 예외를 보지 못한 QA는
언제나 늦는다.

---

착각 4. 상태는 개발이 알아서 관리한다

상태(State)를
개발 영역이라고 생각하는 순간,
QA는 가장 중요한 것을 놓친다.

기능은 눈에 보이지만,
상태는 눈에 보이지 않는다.

그래서 더 위험하다.

• 재현이 어렵고
• 특정 조건에서만 발생하며
• 시간이 지난 뒤에 터진다

상태를 보지 않는 기능 QA는
항상
“왜 이 타이밍인지 모르겠다”고 말한다.

그 이유는 단순하다.
상태를 본 적이 없기 때문이다.

---

착각 5. 트리거와 경계값은 부가적인 테스트다

트리거와 경계값을
‘여유 있으면 보는 것’으로 두는 순간,
기능 QA는
표면 테스트로 전락한다.

• 어떤 행동이 상태를 바꾸는가
• 어디서 가능이 불가능으로 바뀌는가

이 질문은
기능 QA의 중심이다.

트리거와 경계값을 보지 않는 QA는
항상
“그럴 줄 몰랐다”는 말을 하게 된다.

QA의 역할은
놀라는 것이 아니다.
예상하는 것이다.

---

착각 6. 데이터는 나중에 보면 된다

데이터를
기능 QA 이후 단계로 미루는 순간,
문제는 반드시 늦게 터진다.

• 오늘은 괜찮았는데
• 내일은 안 되고
• 특정 유저만 겪는다

이 모든 문제의 중심에는
데이터가 있다.

기능 QA에서
데이터를 보지 않는다는 것은
결과를 확인하지 않는 것과 같다.

---

착각 7. 로그는 개발자 영역이다

로그를 보지 않는 QA는
언제나
“추정”으로 말한다.

로그를 보는 QA는
“근거”로 말한다.

이 차이는
QA의 신뢰를 결정한다.

로그는
개발자의 무기가 아니다.

로그는
QA가 시스템과
같은 언어로 대화할 수 있게 해주는
유일한 도구다.

---

여기까지가
기능 QA를 망치는
가장 흔한 착각들이다.

이 착각들의 공통점은 하나다.

기능을 ‘보는 일’과
기능을 ‘해석하는 일’을
같은 것으로 착각한다는 점이다.

---

PART 2 전체를
한 문장으로 정리하면 이렇다.

기능 QA는
기능을 테스트하는 일이 아니다.

기능 QA는
기능이 만들어낼 결과를
예측 가능하게 만드는 일이다.

• 정상 흐름을 이해하고
• 상태를 추적하며
• 트리거와 경계를 확인하고
• 데이터와 로그로 근거를 남긴다

이 흐름이 하나라도 빠지는 순간,
기능 QA는
확인 작업으로 돌아간다.