대부분의 QA 엔지니어가 핵심 기술을 실천하지 못하는 이유 — 그리고 Mutation Testing이 이를 바꾸는 방법

Source: Dev.to

소프트웨어 개발자로 성장하고 싶다면 LeetCode, HackerRank, Codewars와 같은 수천 개의 문제, 명확한 점수 체계, 그리고 집착하게 만드는 연속 기록이 있습니다. 코드를 작성하고, 그 코드가 통과하거나 통과하지 않으며, 그 과정을 통해 배우게 됩니다.

하지만 QA 엔지니어, 즉 버그를 찾는 실제 역량을 향상시키고 싶다면 어떻게 해야 할까요?

테스트 설계 기법에 관한 블로그 글을 읽고, ISTQB 교과 과정을 공부하고, 개인 프로젝트에 테스트를 작성하면서 스스로가 나아지고 있다고 기대할 수 있습니다. 그러나 명확한 피드백 루프가 없고, “당신의 솔루션이 50개 중 47개의 테스트 케이스를 통과했습니다”와 같은 기준도 없습니다. 실제로 중요한 것, 즉 실제 버그를 잡아내는 테스트를 작성하는 능력이 향상되고 있는지 알 방법이 없습니다.

그 격차를 메우기 위해 뮤테이션 테스트가 고안되었습니다.

LeetCode 연습의 문제점

LeetCode는 자신이 하는 일에 있어 훌륭합니다. 알고리즘적 사고, 자료구조 활용 능력, 그리고 압박 속에서 올바른 구현을 작성하는 능력을 훈련시켜 줍니다.

하지만 그것은 QA 업무와는 다릅니다.

QA 엔지니어가 calculate_discount(price, customer_tier) 같은 함수와 마주했을 때, 구현하는 것이 목표가 아닙니다. 목표는 다음을 생각하는 것입니다:

• 여기서 어떤 문제가 발생할 수 있을까?
• 어떤 엣지 케이스가 존재할까?
• 구현이 전제하고 있는 가정은 무엇이며, 그 가정이 깨질 가능성은?

그리고—아주 중요한—그 실패를 잡아낼 테스트를 작성하는 것입니다.

LeetCode는 사양을 제공하고 이를 통과하라고 요구합니다. QA 업무는 구현을 제공하고 이를 깨뜨리는 것을 요구합니다.

이 두 가지는 근본적으로 다른 인지적 기술입니다:

합성 연습을 한다고 해서 분석 능력이 향상되는 것은 아닙니다. 그럼에도 불구하고, 수년간 “LeetCode 연습”이 기술 역량을 강화하고자 하는 QA 엔지니어에게 기본 조언으로 제시되어 왔습니다.

실제 변이 테스트가 무엇인가

변이 테스트는 작고 의도적인 변경—즉 변이(mutants)—을 정상 동작하는 코드에 주입하는 기법입니다. 그런 다음 테스트 스위트가 각 변이에 대해 실행됩니다:

• 테스트가 버그를 잡아내면 해당 변이는 죽은(killed) 것으로 간주됩니다.
• 테스트가 모두 통과하면 변이는 **생존(survives)**하게 되며, 이는 테스트 스위트가 실제 결함을 놓쳤다는 의미입니다.

점수는 죽은 변이 비율(kill ratio) 로 나타냅니다:

Kill Ratio = Killed Mutants / Total Mutants

• 100 % 죽은 변이 비율 → 주입된 모든 버그가 잡혔음.
• 40 % 죽은 변이 비율 → 대부분의 버그가 탐지되지 않고 넘어감.

이는 QA 엔지니어에게 테스트 효율성에 대한 객관적이고 반복 가능한 측정값을 제공하며, 이전에는 없던 지표입니다.

변이는 무작위이거나 파괴적인 변경이 아닙니다. 미묘하고 그럴듯한 결함—개발자가 실제로 도입할 수 있는 종류—을 의미합니다. 일반적인 변이 예시는 다음과 같습니다:

• > 를 >= 로 바꾸기 (오프‑바이‑원)
• 조건문에서 and 를 or 로 교체하기
• 경계 검사 제거하기
• return True 를 return False 로 바꾸기
• 계산에서 + 를 - 로 바꾸기

이러한 각각은 실제 운영 시스템에서 나타난 버그입니다. 변이 테스트는 이러한 버그를 잡아낼 수 있는 테스트 작성을 강제합니다.

빠른 예시

원본 구현

def calculate_discount(price: float, customer_tier: str) -> float:
    """
    Apply discount based on customer tier.
    - 'gold': 20% discount
    - 'silver': 10% discount
    - All others: no discount
    Returns the final price after discount.
    """
    if customer_tier == 'gold':
        return price * 0.80
    elif customer_tier == 'silver':
        return price * 0.90
    else:
        return price

삽입된 돌연변이

# MUTANT: Changed 0.80 to 0.90 (gold tier gets silver discount)
def calculate_discount(price: float, customer_tier: str) -> float:
    if customer_tier == 'gold':
        return price * 0.90   # <-- mutation here
    elif customer_tier == 'silver':
        return price * 0.90
    else:
        return price

돌연변이는 미묘합니다. 함수는 여전히 실행되어 숫자를 반환하지만, 골드 고객에게 잘못된 할인을 적용합니다—피곤한 개발자가 쉽게 도입할 수 있는 버그입니다.

돌연변이를 놓치는 약한 테스트

def test_gold_discount():
    result = calculate_discount(100, 'gold')
    assert result < 100          # Too vague — just checks that some discount happened

이 테스트는 돌연변이에 대해 통과하므로, 돌연변이가 생존합니다.

돌연변이를 잡아내는 강력한 테스트

def test_gold_discount():
    result = calculate_discount(100, 'gold')
    assert result == 80.0       # Exact expected value — catches the wrong discount

이 테스트는 돌연변이에 대해 실패하므로, 돌연변이가 제거됩니다.

이것이 변이 테스트입니다: 코드를 실행할 수 있는지 여부만 테스트하는 것이 아니라, 테스트가 올바른 동작과 잘못된 동작을 구분할 수 있는지를 테스트하는 것입니다.

이것이 당신의 경력에 중요한 이유

QA 인터뷰가 테스트하는 정확한 스킬을 훈련합니다

대부분의 QA 인터뷰에서는 결국 다음과 같은 질문을 합니다:

• “이 함수는 어떻게 테스트하시겠습니까?”
• “로그인 폼에 대해 어떤 테스트 케이스를 작성하시겠습니까?”

그들이 실제로 묻고 싶은 것은: 대립적으로 생각할 수 있나요? 이 기능이 실패할 수 있는 방법을 식별할 수 있나요?

뮤테이션 테스트 연습은 바로 이것을 훈련시킵니다. 변형된 코드에 대해 반복적으로 테스트를 작성하고, 킬 비율이 상승하거나 하락하는 모습을 보면서 다음에 대한 직관을 기르게 됩니다:

• 실제로 중요한 테스트 케이스는 무엇인지
• 단순히 잡음에 불과한 테스트는 무엇인지

몇십 개의 문제를 풀고 나면 사양에 대해 전혀 다른 시각으로 생각하게 됩니다. 경계, 연산자 가정, 놓치기 쉬운 엣지 케이스들을 파악하게 되죠. 이것이 바로 면접관이 찾는 엔지니어—성공을 검증하는 것뿐만 아니라 실패를 예측할 수 있는 엔지니어—입니다.

왜 변이 테스트가 QA 엔지니어에게 게임 체인저인가

의도적으로 연습해 보지 않으면 기술을 입증하기 어렵습니다.

객관적인 지표를 제공합니다

QA에서 지속적으로 직면하는 과제 중 하나는 기술을 정량화하기 어렵다는 점입니다.

• 라인 커버리지는 대리 지표가 좋지 않다는 것이 널리 알려져 있습니다.
• 테스트 수는 그 자체만으로는 의미가 없습니다.
• “지난 분기에 버그 47개를 찾았다”는 팀이나 회사 간에 적용하기 어렵습니다.

킬 비율은 다릅니다. 이는 중요한 것, 즉 테스트가 결함을 잡아내는지와 직접 연결됩니다.

변이 테스트 과제에서 지속적으로 90 % 이상 킬 비율을 달성할 수 있는 QA 엔지니어는 실질적인 역량을 입증한 것입니다. 이 수치는 타이핑 속도나 API 문법을 얼마나 잘 외우는지를 측정하는 것이 아니라, 실패에 대해 얼마나 잘 생각하는지를 나타냅니다.

검증 가능한 포트폴리오를 구축합니다

대부분의 QA 포트폴리오 조언은 모호합니다:

• “오픈소스에 기여하기.”
• “테스트가 포함된 개인 프로젝트 작성하기.”

이러한 제안은 괜찮지만, 채용 담당자가 평가하기 쉬운 증거를 제공하지는 않습니다.

변이 테스트 점수는 다릅니다. 이는 객관적이고 재현 가능하며 구체적입니다. 95 % 킬 비율을 달성한 과제를 짧은 테스트 설계 접근 설명과 함께 해결하면, 역량에 대한 구체적인 증거가 됩니다.

‘효과적인 테스트를 잘 작성한다’고 말하는 것과 실제로 보여줄 수 있는 것의 차이입니다.

직접 해보세요

연습을 시작하고 싶다면, SDET Code 가 바로 이를 위해 만든 플랫폼입니다. 회원가입 없이도 세 가지 과제를 시도할 수 있습니다—사이트를 열고 pytest를 작성하기만 하면 됩니다. 이 플랫폼에는 난이도별로 339개의 과제가 있으며 모두 변이 테스트에 초점을 맞추고 있습니다.

• 모든 것이 WebAssembly를 사용해 브라우저에서 실행됩니다(설정이나 설치 필요 없음).
• AI 코치가 원할 때 테스트 설계에 대한 피드백을 제공합니다.
• 시작은 무료입니다.

목표는 개발자를 위한 LeetCode와 동일합니다—명확한 피드백이 있는 의도적인 연습 환경—하지만 QA 엔지니어가 실제로 필요로 하는 역량을 중심으로 구축되었습니다.

큰 그림

QA 분야에는 역량 측정 문제가 있습니다. 우리는 테스트 원칙에 대해 이야기하지만, 실제로 이를 연습하고 명확한 피드백을 받을 수 있는 환경을 만들기 어렵습니다.

변이 테스트가 QA의 모든 문제를 해결하는 것은 아닙니다. 이는 테스트 효율성의 한 차원에 초점을 맞춘 하나의 도구입니다. 그러나 오랫동안 존재해 온 공백을 메웁니다: QA 작업의 핵심 적대적 사고 능력을 객관적인 점수와 함께 반복 가능한 환경에서 연습할 수 있는 방법을 제공합니다.

• 주당 1시간을 변이 테스트 문제에 투자하면 한 달 안에 테스트 설계에 대한 사고 방식이 달라질 것입니다.
• 패턴이 내재화됩니다.
• 에지 케이스가 자동적으로 처리됩니다.

이것이 의도적인 연습이 하는 일입니다. QA 엔지니어들은 오랫동안 정당하게 적절한 연습 환경을 요구해 왔습니다.

이 글은 “QA 엔지니어를 위한 변이 테스트” 시리즈의 Part 1입니다. Part 2에서는 경계값 변이와 체계적인 커버리지 전략 개발에 대해 다룰 예정입니다.