답변.

비즈니스 로직의 수동 테스트는 애플리케이션의 구현된 기능이 고객이나 분석가가 설명한 비즈니스 요구사항 및 사용 시나리오에 부합하는지 확인하는 데 목적이 있습니다.

질문의 역사

IT 제품의 발전과 함께 비즈니스 로직의 복잡성이 증가했습니다. 애플리케이션은 분기 시나리오, 조건 및 예외 상황을 포함하기 시작했으며, 자동화된 테스트는 항상 고유한 사용자 사례를 포함하지 않았습니다. 수동 테스트는 필요한 논리를 실제 고객의 문제에 "적용"할 수 있게 해주었습니다.

문제

대부분의 경우 함정은 테스트 담당자가:

실제 사용자 시나리오를 무시하고 오로지 문서에만 의존하는 경우;
모든 예외를 포함하지 않는 경우;
비즈니스 규칙 간의 복잡한 종속성을 간과하는 경우입니다.

해결책

비즈니스 로직의 질 높은 수동 테스트를 위해서는 다음과 같은 절차를 따라야 합니다:

분석가/고객과 비즈니스 요구사항을 명확히 하고 논의합니다;
유효한 및 무효한 입력 데이터 조합에 주의를 기울이면서 사용자 시나리오(user stories)를 작성합니다;
비즈니스 프로세스 내의 경계 및 예외 상황을 확인합니다;
버그뿐만 아니라 누락된 요구사항이나 불일치도 문서화합니다.

주요 특징들:

세부 사항에 대한 주의: 비즈니스 로직의 사소한 부정확성이 심각한 손실로 이어질 수 있습니다.
고객과의 상호작용: 논란이 되는 부분에 대한 피드백을 받는 것이 중요합니다.
모든 대안 경로의 테스트: 전형적인 시나리오뿐만 아니라 비전형적인 시나리오도 테스트해야 합니다.

함정 질문들.

비즈니스 로직을 테스트하는 데 있어 테스트 문서 및 요구사항에 전적으로 의존할 수 있나요?

아닙니다. 문서가 애플리케이션의 모든 행동 측면을 포괄하지 않는 경우가 많으며, 특히 복잡한 분기 시나리오에서 그렇습니다. 추가적으로 요구 사항 소유자에게 세부 사항을 명확히 하고 탐색적 테스트를 통해 시스템을 조사하는 것이 중요합니다.

비즈니스 로직의 모든 가능한 부정적인 시나리오를 반드시 테스트해야 하나요?

네, "올바른" (긍정적인) 시나리오만 테스트하는 것은 잘못된 입력, 사용자 오류 또는 비즈니스 규칙 위반으로 발생할 수 있는 치명적인 오류를 놓칠 수 있습니다.

테스트 단계를 형식적으로 증명하는 것만으로 비즈니스 로직이 올바르게 구현되었다고 주장할 수 있나요?

아닙니다. 테스트 케이스를 형식적으로 이행하는 것만으로는 모든 비즈니스 로직이 올바르게 작동한다고 보장할 수 없으며, 조건 및 시나리오 간의 상관관계를 검토하고 사용자 경험 및 비즈니스의 실제 기대에 부합하는지 평가하는 것이 중요합니다.

전형적인 오류 및 안티 패턴

비즈니스와 소통하지 않고 요구사항만을 기반으로 하는 것
부정적인 시나리오의 부족한 커버리지
비표준 또는 겹치는 조건을 무시하는 것

실제 사례

부정적인 케이스

테스트 담당자는 문서에 엄격히 따라 고객에게 세부 사항을 명확히 하지 않았습니다. 은행 애플리케이션의 서비스 활성화에 대한 기본 시나리오만 테스트했습니다.

장점:

릴리스 요구사항의 빠른 커버리지
명확한 테스트 경로

단점:

밤에 서비스 활성화 시 발생하는 오류나 클라이언트의 유효하지 않은 상태에서 문제를 발견하지 못함
프로덕션에서 문제 발견 후 재작업이 필요한 태스크 반환

긍정적인 케이스

테스트 담당자는 비즈니스 분석가와 적극적으로 소통하며 모든 형식적인 시나리오뿐만 아니라 경계 조건이 포함된 레퍼런스 케이스도 테스트했습니다 (예: 주말 동안 서비스 가용성 부족).