Regression testing workflow: 위험이 먼저 릴리스를 안정적으로 유지하는지 확인

Source: Dev.to

Workflow shown: 위험‑우선 회귀 범위 지정 → 골든‑패스 기준선 → 목표 탐색 → 증거‑기반 결과.
Example context: PC Game Pass (Windows)에서 Sworn을 실제 사례로만 사용했습니다.
Build context: PC Game Pass 빌드 1.01.0.1039에서 테스트되었습니다.
Scope driver: 외부 변경 신호로 공개된 SteamDB 패치 노트를 사용했습니다 (플랫폼 간 동등성은 가정하지 않음).
Outputs: 라인‑별 결과, 세션 타임스탬프, 증거가 포함된 버그 티켓을 포함한 회귀 매트릭스.

변경 후 안정성을 검증하기 위해 시간‑제한된 Sworn(PC) 패스 동안 사용된 회귀 테스트 흐름.

회귀 테스트 범위: 검증한 내용과 이유

이 문서는 Sworn의 자체 주도 포트폴리오 회귀 테스트를 PC Game Pass (Windows) 빌드 1.01.0.1039를 사용해 1주일 동안 단독으로 진행한 결과를 기반으로 합니다.

범위는 변경 기반이며 위험 기반이었습니다:

• 골든‑패스 안정성 (launch → play → quit → relaunch)
• 저장‑후‑계속 무결성
• 핵심 메뉴
• 오디오 정상 여부
• 입력 인계
• 상위 패치 노트에서 제안된 부작용 탐지

Steam 및 Game Pass 동등성 주장은 하지 않습니다.

회귀 테스트란 (실제로)

저에게 회귀 테스트는 간단합니다: 변경 후에 기존 동작이 여전히 유지되는가?

• “모든 것을 다시 테스트한다”는 것이 아닙니다.
• “우리가 하는 일이라 체크리스트를 실행한다”는 것이 아닙니다.

회귀 테스트는 설계상 선택적입니다. 커버리지는 위험에 따라 결정됩니다:

1. 가장 영향을 받았을 가능성이 높은 것은 무엇인가?
2. 깨졌을 때 가장 큰 비용이 드는 것은 무엇인가?
3. 빌드가 신뢰받기 위해 반드시 안정적으로 유지되어야 하는 것은 무엇인가?

회귀 테스트 결과: 증거가 있는 pass/fail 결과

• 명확한 결과: pass 또는 fail.
• 증거와 반복 가능한 검증에 의해 뒷받침됨.
• 의견 없음, “vibes” 없음.

Source: …

회귀 테스트를 위한 골든‑패스 스모크 베이스라인

나는 매 회귀 사이클을 반복 가능한 골든‑패스 스모크로 시작한다. 이는 낭비되는 시간을 방지해 주기 때문이다. 베이스라인이 불안정하면, 더 깊은 테스트는 잡음에 불과하다.

이번 Sworn 패스에서는 베이스라인 라인이 BL‑SMOKE‑01이었다:

cold launch → main menu → gameplay → quit to desktop → relaunch → main menu

또한 이 흐름 동안 오디오 끊김을 빠르게 확인하는 간단한 청취 검사를 포함한다.

“일부 시스템은 절대적으로 깨질 수 없다. 이런 시스템은 더 깊은 테스트에 시간을 들이기 전에 매 빌드마다 반드시 확인해야 한다.”
— Conrad Bettmann, QA Manager (Rovio Entertainment)

왜 회귀 테스트에서 기준선 안정성이 중요한가

골든 경로는 가장 일반적인 플레이어 동작(시작, 재생, 종료, 재개)을 포함합니다. 이러한 동작이 불안정하면, 관련 없는 결함으로 가장하는 연쇄적인 실패가 발생합니다.

회귀 테스트 범위: 변경 신호와 위험

이 프로젝트에서는 SteamDB 패치 노트를 외부 오라클로 사용했습니다:

SWORN 1.0 Patch #3 (v1.0.3.1111), 13 Nov 2025

이는 해당 변경 사항이 PC Game Pass에 존재한다고 가정한 것이 아닙니다. 대신, 패치 노트를 변경 신호로 활용하여 Game Pass 빌드에서 부작용을 탐색할 위치를 결정했습니다. 내부 접근 권한이 없고, 스튜디오 데이터도 없으며, 플랫폼에 대한 변경 로그도 없을 때 유용합니다.

무엇이 어디서 변경되었는지를 알면, 가치 있는 결과를 찾기 어려운 광범위한 검사를 수행하는 대신 영향을 받은 영역에 회귀 테스트를 집중할 수 있습니다. 일반적으로 단일 소스에 의존하기보다 여러 오라클을 혼합하는 것이 가장 좋습니다.

“외부 오라클은 내부 문서가 없을 때 위험 기반 회귀 테스트를 추진하는 실용적인 방법입니다.”
— Conrad Bettmann, QA Manager (Rovio Entertainment)

회귀 결과: 통과 vs. 해당 없음 (증거 포함)

• SteamDB 메모에 음악 끊김 방지 수정이 언급되어 있어, 오디오 런타임 프로브(STEA‑103‑MUSIC)를 실행하고 전투, 일시정지/재개, 레벨 로드 전반에 걸쳐 음악 연속성을 확인했으며 – 통과.
• SteamDB는 또한 대화 볼륨 슬라이더를 언급합니다. Game Pass 빌드에서는 해당 제어가 존재하지 않아, 검사 결과를 해당 없음으로 기록하고 부재 증거(STEA‑103‑AVOL)를 제시했습니다.

내 회귀 매트릭스 구조

내 Regression Matrix 라인은 감사 가능하도록 작성됩니다. 각 라인에는 다음이 포함됩니다:

1. 직접 검사
2. 부수 효과 검사(해당되는 경우)
3. 명확한 결과
4. 증거 링크

이렇게 하면 결과를 검토 가능하게 유지하고 “괜찮은 것 같다”는 보고를 방지합니다.

예시 매트릭스 라인

Save‑and‑Continue 회귀 테스트: 앵커, 분위기가 아니라

Save‑and‑Continue 흐름은 실패가 간헐적으로 보일 수 있기 때문에 고전적인 회귀 위험 영역입니다. 모호성을 줄이기 위해 앵커를 사용해 검증합니다.

이번 패스 (BL‑SAVE‑01)에서 저는 다음을 앵커했습니다:

• Room splash name – Wirral Forest
• Health bucket – 60/60
• Weapon type – sword
• Start of objective text

그 후 menu Continue 후와 full relaunch 후에 해당 앵커들을 검증했습니다.

Outcome: pass – 앵커가 전체 세션 S2 동안 일치했습니다.

Why anchors make regression results repeatable

“Continue worked” is not useful if someone else cannot verify what you resumed into. Anchors turn “seems fine” into a repeatable verification result.

회귀 테스트를 위한 QA 증거: 내가 캡처하는 내용과 이유

회귀 테스트에서는 증거가 중요합니다. 각 검증마다 다음과 같은 항목을 캡처합니다:

모든 증거는 공유 폴더에 저장되고 회귀 매트릭스에 링크되어, 누구든지 기억이나 주관적 설명에 의존하지 않고 결과를 감사할 수 있도록 합니다.

증거 가이드라인

• 비디오 클립 – 입력, 타이밍, 결과를 함께 보여줍니다 (흐름 및 오디오 확인에 이상적).
• 스크린샷 – UI 상태, 메뉴 존재/부재, 버그 명확성을 지원합니다.
• 세션 타임스탬프 – 긴 녹화를 스크러빙하지 않고도 검증을 검토 가능하게 유지합니다.
• 환경 노트 – 플랫폼, 빌드, 입력 장치, 클라우드 저장 활성화 여부.

증거가 무엇을 했는지, 무엇이 일어났는지, 그리고 무엇이 일어나야 했는지에 답하지 못한다면, 그것은 증거가 아닙니다.

회귀‑테스트 예시 (from the Sworn pass)

예시 회귀 버그: Defeat 오버레이가 Stats 화면을 가림 (SWOR‑6)

Bug: [PC][UI][Flow] Defeat overlay blocks Stats; Continue starts a new run (SWOR‑6)

• Expectation: Defeat 후 Continue 를 누르면 전체 Stats 화면이 전면에 표시되고 플레이어 확인을 기다립니다.
• Actual: Defeat 화면이 전면에 남아 있고, Stats 가 로딩 아이콘과 함께 그 아래에 렌더링된 뒤 자동으로 새로운 런이 시작됩니다. 결과 – Stats 를 검토할 수 없습니다.
• Repro rate: 3/3 (진행 검증 S2 중 관찰되고 전용 재테스트 S6 에서 재확인됨).

패치‑노트 탐색 예시: 음악 연속성 확인 (STEA‑103‑MUSIC)

SteamDB 노트에 음악 끊김을 수정했다는 언급이 있어 STEA‑103‑MUSIC 를 실행했습니다:

• Test: 전투 전환을 포함한 10 분 런타임, 그리고 일시정지/재개와 레벨 로드를 추가했습니다.
• Outcome: Pass – 해당 전환들 동안 음악이 끊기지 않고 연속되었습니다 (S3).

증거 기반 “해당 없음” 예시: 누락된 Dialogue Volume 슬라이더 (STEA‑103‑AVOL)

SteamDB 노트에 Dialogue Volume 슬라이더가 있다고 언급했지만, Game Pass 빌드의 Audio 메뉴에는 Master, Music, SFX 만 표시되었습니다.

• Outcome: Not applicable (증거로 부재 확인) (STEA‑103‑AVOL, S4).
• 이는 파리티를 억지로 만들지 않고 매트릭스를 정직하게 유지하기 위함입니다.

접근성 이슈를 알려진 클러스터로 기록 (새 빌드가 없어 재테스트 불가)

Day 0 (S0) 에 온보딩 접근성 이슈를 알려진 클러스터 (B‑A11Y‑01: SWOR‑1, SWOR‑2, SWOR‑3, SWOR‑4) 로 캡처했습니다.

• 해당 주에 새로운 빌드가 없었기 때문에 회귀 재테스트는 not applicable 이었으며, 새로운 빌드가 존재할 때까지 적용되지 않았습니다.
• 이는 암시가 아니라 명시적으로 기록되었습니다.

결과 스냅샷 (투명성을 위해)

이 백업 패스에서 매트릭스가 기록한 내용:

• 8 통과
• 1 실패
• 1 해당 없음
• 1 알려진 접근성 클러스터가 Day 0에 캡처되었으며 재테스트를 위한 최신 빌드가 없습니다

카운트는 맥락을 제공하기 위한 것이며, 기사 내용의 초점은 아닙니다.

회귀 테스트 요점 (위험, 증거, 검증)

• 회귀 테스트는 변경 기반 검증이며, “모두 다시 테스트”가 아니다.
• 반복 가능한 골든‑패스 기준선은 불안정한 빌드에 시간을 낭비하는 것을 방지한다.
• 외부 패치 노트를 위험 신호로 활용할 수 있으며, 플랫폼 동등성을 가정할 필요는 없다.
• 앵커는 진행 상황 및 이력 검증을 신뢰할 수 있고 반복 가능하게 만든다.
• 해당 없음은 증거가 뒷받침될 경우 유효한 결과이며, 단순히 무시해서는 안 된다.
• 통과 결과도 증거가 필요하다, 왜냐하면 그것도 주장에 해당하기 때문이다.

Source:

Regression‑Testing FAQ (manual QA)

Is regression testing just re‑testing old bugs?
아니요. 회귀 테스트는 변경 후에도 기존 동작이 여전히 정상인지 확인하는 것이며, 버그가 기록된 여부와 관계없이 이전에 정상 작동하던 시스템을 포함합니다.

Do you need to re‑test everything in regression?
아니요. 효과적인 회귀 테스트는 선택적으로 수행됩니다. 범위는 기능 수가 아니라 변경 사항과 위험도에 따라 결정됩니다.

How do you scope regression without internal patch notes?
공개 패치 노트, 이전 빌드, 관찰된 동작 등을 오라클로 활용하고, 플랫폼 동등성을 가정하지 않음으로써 외부 변화 신호를 이용합니다.

What’s the difference between regression and exploratory testing?

• Regression: 변경 후 알려진 동작을 검증합니다.
• Exploratory: 알려지지 않은 위험과 새로운 실패 모드를 탐색합니다.
  두 테스트는 서로 보완하지만 답하는 질문이 다릅니다.

Is a pass result meaningful in regression testing?
예. 통과는 여전히 주장에 해당하므로, 회귀 테스트가 통과했을 경우 증거를 제시해야 하며 단순히 체크박스만 체크해서는 안 됩니다.

When is “not applicable” a valid regression outcome?
테스트 중인 빌드에 해당 기능이 존재하지 않고, 그 부재가 증거로 확인된 경우입니다. 이를 명시적으로 기록하는 것이 동등성을 가정하거나 체크를 생략하는 것보다 더 정직합니다.

증거 및 사례 연구 링크

• (워크북 탭에 대한 링크 추가: Regression Matrix, Sessions Log, Bug Log)
• (증거 클립에 대한 링크 추가)

이 dev.to 게시물은 회귀 워크플로에 집중합니다. 사례 연구 링크는 워크북 탭 및 증거 클립으로 연결됩니다.