답변.

질문 배경:

스모크 테스트( "연기 테스트")는 시스템 빌드 후 기능이 작동하는지 빠르게 확인하는 방법으로 등장했습니다. 그 목표는 중요한 기능들이 작동하고 애플리케이션이 원래 더 깊은 검사를 위한 준비가 되어 있는지를 확인하는 것입니다. 수동 테스트에서 스모크 테스트는 일반적으로 새로운 버전의 제품을 배포한 직후에 수행됩니다.

문제:

주요 어려움은 제한된 시간과 정말로 중요한 검사를 선택해야 할 필요성입니다. 종종 테스터는 너무 많은 것을 검사하여 자원을 낭비하거나 비판적인 사항을 놓치는 경우가 있어 릴리스에 "구멍"이 포함될 수 있습니다.

해결책:

올바른 스모크 테스트 조직은 가장 중요한 사용자 흐름을 아우르는 엄격히 최소한의 시나리오 세트를 선택하는 데 있습니다. 이러한 검사는 명확하고 빠르며 재현 가능해야 합니다. 예를 들어:

- 사용자가 시스템에 성공적으로 로그인
- 주요 기능을 수행할 수 있는지 확인하기 (예: 구매하기)
- 결제 및 확인 받기

주요 특징:

스모크 테스트는 생명선 역할을 하는 기능만을 포함합니다.
빠른 수행이 가능하며 잦은 릴리스 시에 중요합니다.
모든 시나리오는 사전에 승인된 체크리스트에 따라 수동으로 수행됩니다.

함정 질문들.

스모크 테스트를 회귀 테스트의 완전한 대체로 간주할 수 있습니까?

아니요, 스모크 테스트는 주요 기능들의 "작동 - 비작동"에만 중점을 둡니다. 심각하지만 명백하지 않은 버그를 찾기 위해서는 항상 완전한 회귀 테스트가 필요합니다.

하나의 스모크 테스트라도 통과하지 못했을 경우 어떻게 해야 합니까? 테스트를 계속 진행해야 하나요?

아니요, 추가 테스트는 의미가 없습니다. 팀은 문제를 보고하고, 버그가 수정될 때까지 릴리스가 차단됩니다.

스모크 테스트에 엣지 케이스 시나리오 검사를 포함해야 합니까?

아니요, 스모크 테스트는 엣지 케이스를 검사하기 위한 것이 아닙니다. 이는 주요 기능의 작동 가능성을 확인하기 위한 것입니다.

일반적인 실수와 안티 패턴

작동 가능성에 중요하지 않은 과도한 테스트를 수행함.
스모크 테스트에 대한 문서 없으며(테스터가 모든 것을 머릿속에 기억함)
"보고서 작성"을 위해 명백한 문제를 무시함.

실제 사례

부정적 사례

스모크 테스트가 중요하지 않은 기능을 포함하는 광범위한 체크리스트를 기반으로 수행되었습니다. 시간이 많이 소요되어 릴리스가 반나절 지연되었습니다.

장점:

몇 가지 명백하지 않은 버그를 발견함.

단점:

릴리스 지연
중요하지 않은 확인에 자원과 시간을 낭비함.

긍정적 사례

스모크 테스트는 가장 중요한 시나리오에만 집중했습니다. 차단 버그를 빠르게 발견하고 팀에 보고하여 릴리스가 수정될 때까지 중단되었습니다.