변수 찾아내기 — 숨어 있는 변수와 대참사

개념

변수는 입력 필드만이 아니다

모듈 3의 동등분할·페어와이즈는 명시적인 입력값(폼 필드, API 파라미터)을 변수로 다뤘다. 하지만 시스템에 영향을 주는 변수는 훨씬 많다 — 대부분 아무도 "이것도 변수다"라고 의식하지 않는 것들이다.

숨은 변수가 대참사를 만드는 방식

숨은 변수 하나만으로는 잘 안 터진다. 문제는 두세 개가 동시에 겹칠 때다.

예: "장바구니에 상품이 100개 이상 담긴 상태"(데이터 양)에서, "네트워크가 느릴 때"(네트워크 조건) 결제를 시도하면, 타임아웃 처리가 잘못되어 중복 주문이 생긴다.

이런 결함은 명세 기반 기법으로는 설계하기 거의 불가능하다 — 애초에 "장바구니 100개"와 "느린 네트워크"를 동시에 변수로 지정한 요구사항 자체가 없기 때문이다. 탐색적 테스팅이 실시간으로 여러 조건을 조합해보는 과정에서만 발견된다.

찾는 방법: "지금 이 순간, 내가 의식 못 하고 있는 게 뭐지?"

숨은 변수를 찾는 가장 실용적인 방법은, 탐험 중간중간 스스로에게 묻는 것이다 — "지금 이 상황에서, 평소와 다른 게 있다면 뭘까?" 예를 들어 "오늘은 평소보다 화면을 확대해서 보고 있다", "이 계정은 3년 전에 만든 오래된 계정이다", "지금 시간이 자정을 막 넘겼다" 같은 것들을 의식적으로 떠올려본다.

실무에서 왜 필요한가

숨은 변수로 인한 결함은 실무에서 "재현이 안 되는" 형태로 나타나는 경우가 많다(다음다음 레슨에서 다룬다) — 왜냐하면 재현을 시도하는 사람이 그 숨은 변수를 그대로 맞추지 못하기 때문이다. QA가 "오늘 뭔가 평소와 달랐던 게 있나?"를 습관적으로 점검하면, 이런 결함을 처음부터 더 잘 잡거나, 최소한 재현 조건을 더 정확히 좁힐 수 있다.

실습 과제

과제 1 — 숨은 변수 브레인스토밍 (12분)

"동영상 스트리밍 재생" 기능에 대해 숨은 변수를 최소 8개 브레인스토밍한다. (힌트: 기기, 네트워크, 계정 상태, 콘텐츠 자체의 특성 등을 생각해본다.)

과제 2 — 조합해서 대참사 상상하기 (10분)

과제 1에서 찾은 변수 중 2개를 골라, 두 개가 동시에 겹치면 어떤 결함이 생길 수 있을지 상상해 시나리오를 적는다.

자가 체크리스트

• 명시적 변수와 숨은 변수의 차이를 예시로 구분할 수 있다
• 숨은 변수 두세 개가 겹쳐서 결함이 되는 방식을 설명할 수 있다
• "지금 평소와 다른 게 뭘까?"라는 질문으로 숨은 변수를 스스로 찾아낼 수 있다
• 숨은 변수로 인한 결함이 왜 재현하기 어려운 형태로 나타나는지 설명할 수 있다

흔한 실수

• 숨은 변수를 명시적 변수와 똑같이 취급해 전부 테스트 케이스로 만들려고 한다. 숨은 변수는 조합이 무한대에 가까워, 명세 기반처럼 전부 케이스화하는 건 불가능하다. 탐험하며 발견하는 대상으로 다루는 게 현실적이다.
• 결함을 발견하고도 "어떤 숨은 변수 때문이었는지" 기록하지 않는다. 나중에 재현하거나 원인을 분석할 때 이 기록이 결정적인 단서가 된다.
• 자기 자신의 환경(브라우저, 기기, 계정 상태)을 변수로 인식하지 못한다. 테스터 본인의 평소 설정이야말로 가장 자주 간과되는 숨은 변수다.

참고 자료

• Elisabeth Hendrickson, Explore It! — 숨은 변수(Hidden Variable) 개념을 정리한 장
• James Bach, "Heuristics of Software Testability" — 변수와 관찰 가능성에 대한 심화 자료