스모크 테스트로 빌드 수락 기준 세우기
스모크 테스트의 목적과 샌티티 테스트 차이, 자동화 흐름, 이커머스 테스트 케이스 및 CI/CD 운영 원칙을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
빌드를 더 깊게 검증하기 전에 확인할 것
스모크 테스트는 새 빌드나 릴리스가 핵심 기능을 정상적으로 수행할 수 있는지 빠르게 확인하는 예비 테스트 기법이다. 하드웨어에 전원을 넣었을 때 연기가 나지 않으면 기본 동작은 가능하다고 보는 데서 이름이 유래했다.
목적은 단순하다. 치명적인 결함이 있는 빌드를 초기에 걸러내고, 통과 가능성이 없는 대상에 심층 테스트 리소스를 쓰지 않기 위해서다. 소프트웨어 품질 보증에서 가장 앞단의 방어선 역할을 한다.
보통 스모크 테스트는 10~30분 안에 끝나도록 구성한다. 전체 시스템을 폭넓게 훑되, 개별 기능을 깊이 파고들지는 않는다. 반복 실행하기 쉬워 매일 또는 새 빌드마다 수행할 수 있고, CI/CD 파이프라인에도 연결하기 적합하다.
샌티티 테스트와 구분하는 기준
두 테스트 모두 짧은 시간 안에 상태를 판단한다는 점에서 혼동되기 쉽다. 하지만 스모크 테스트는 빌드 자체를 받아들일지 확인하고, 샌티티 테스트는 특정 변경이나 버그 수정이 적용됐는지를 확인한다.
| 특성 | 스모크 테스트 | 샌티티 테스트 |
|---|---|---|
| 목적 | 기본 기능이 작동하는지 확인 | 특정 변경사항이나 버그 수정이 제대로 적용되었는지 확인 |
| 실행 시점 | 빌드 수락 전 | 빌드 수락 후 |
| 범위 | 넓지만 얕음(광범위한 영역) | 좁지만 깊음(특정 영역) |
| 테스트 케이스 | 사전 정의된 테스트 스크립트 | 임시적, 집중적 테스트 |
| 자동화 정도 | 높음 | 중간~낮음 |
핵심 사용자 흐름을 중심으로 설계하기
테스트 대상은 시스템이 실패했을 때 비즈니스에 큰 영향을 주는 기능부터 정한다. 그다음 각 기능의 가장 기본적인 긍정 경로(happy path)를 짧은 시나리오로 만든다.
자동화 단계에서는 Selenium, JUnit, TestNG, Cypress 등의 도구를 선택하고 CI/CD 파이프라인과 연결한다. 실행 일정을 정해 두고 결과 알림을 받으면, 실패한 빌드가 다음 테스트 환경이나 생산 환경으로 넘어갈 가능성을 줄일 수 있다.
시스템이 바뀌면 스모크 테스트도 함께 바뀌어야 한다. 더 이상 핵심이 아닌 테스트는 제거하고, 새 핵심 기능에는 검증 시나리오를 추가한다.
웹 애플리케이션에서 확인하는 흐름
로그인, 주요 화면 접근, 데이터 로드, 기본 CRUD, API 응답, 기본 사용자 시나리오는 웹 애플리케이션 스모크 테스트에서 우선 확인할 수 있는 흐름이다.
자동화 도구를 고르는 범위
웹 애플리케이션에는 다양한 브라우저에서 자동화할 수 있는 Selenium, 모던 웹 애플리케이션용 E2E 프레임워크인 Cypress, Node.js 기반 크로스 브라우저 솔루션인 TestCafe를 사용할 수 있다.
API 영역에서는 Postman, Java 기반 REST API 테스트 라이브러리인 REST-assured, SOAP 및 REST API 테스트 도구인 SoapUI가 선택지다. 모바일 앱은 Appium, Android UI 테스트 프레임워크인 Espresso, iOS 앱 테스트 프레임워크인 XCTest로 자동화할 수 있다.
CI/CD 통합에는 Jenkins, 코드 저장소와 통합된 GitHub Actions, 클라우드 기반 CI/CD 서비스인 CircleCI를 활용할 수 있다.
이커머스 서비스에서 우선 확인할 항목
이커머스 플랫폼에서는 서비스가 열리고 홈페이지가 로드되는지부터 본다. 서버 응답 시간은 예를 들어 3초 미만인지 검증할 수 있다.
이후 로그인과 로그아웃, 비밀번호 재설정 링크를 확인한다. 상품 검색, 카테고리 네비게이션, 상품 상세 페이지 로드도 기본 흐름에 포함된다. 장바구니에서는 상품 추가·제거와 수량 조정을, 결제 단계에서는 체크아웃 페이지 접근과 테스트 모드의 간단한 결제 시뮬레이션을 확인한다.
Selenium으로 기본 경로 검증하기
아래 예시는 홈페이지, 로그인, 상품 검색, 장바구니 추가 흐름을 검증하는 Python Selenium 테스트다.
import unittest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
class EcommerceSmoke(unittest.TestCase):
def setUp(self):
self.driver = webdriver.Chrome()
self.driver.maximize_window()
self.driver.get("https://example-ecommerce.com")
def test_homepage_loads(self):
"""홈페이지 로드 테스트"""
self.assertIn("Example Ecommerce", self.driver.title)
def test_login(self):
"""로그인 기능 테스트"""
self.driver.find_element(By.ID, "login-button").click()
WebDriverWait(self.driver, 10).until(
EC.presence_of_element_located((By.ID, "login-form"))
)
self.driver.find_element(By.ID, "username").send_keys("test@example.com")
self.driver.find_element(By.ID, "password").send_keys("test123")
self.driver.find_element(By.ID, "submit-login").click()
WebDriverWait(self.driver, 10).until(
EC.presence_of_element_located((By.ID, "user-profile"))
)
profile_element = self.driver.find_element(By.ID, "user-profile")
self.assertTrue(profile_element.is_displayed())
def test_search_functionality(self):
"""상품 검색 기능 테스트"""
search_box = self.driver.find_element(By.ID, "search-input")
search_box.send_keys("smartphone")
self.driver.find_element(By.ID, "search-button").click()
WebDriverWait(self.driver, 10).until(
EC.presence_of_element_located((By.CLASS_NAME, "product-item"))
)
products = self.driver.find_elements(By.CLASS_NAME, "product-item")
self.assertTrue(len(products) > 0)
def test_add_to_cart(self):
"""장바구니 추가 기능 테스트"""
# 제품 페이지로 이동
self.driver.get("https://example-ecommerce.com/product/12345")
add_button = self.driver.find_element(By.ID, "add-to-cart")
add_button.click()
WebDriverWait(self.driver, 10).until(
EC.text_to_be_present_in_element((By.ID, "cart-count"), "1")
)
cart_count = self.driver.find_element(By.ID, "cart-count").text
self.assertEqual(cart_count, "1")
def tearDown(self):
self.driver.quit()
if __name__ == "__main__":
unittest.main()
빠른 피드백을 유지하는 운영 방식
스모크 테스트는 테스트 케이스를 최소한으로 유지해야 실행 시간이 길어지지 않는다. 복잡한 시나리오는 회귀 테스트로 보내고, 스모크 테스트에는 핵심 기능만 남긴다.
수동 실행은 시간이 들고 오류 가능성도 있어 자동화된 테스트를 CI/CD 파이프라인에 통합하는 방식이 적합하다. 또한 판단이 모호하지 않도록 단정문(assertions)이나 검증 로직으로 성공·실패 기준을 명확히 정해야 한다.
실패 시 즉시 알림을 받고 상세 로그와 스크린샷을 남기면 원인 파악이 빨라진다. 이런 흐름은 초기 결함 발견에 따른 수정 비용 감소, 기본 기능의 빠른 검증에 따른 개발 사이클 가속화, 불필요한 심층 테스트 방지로 이어진다.
이 테스트만으로 확인할 수 없는 영역
스모크 테스트는 표면적인 기능을 확인하므로 복잡한 결함을 발견하기 어렵다. 모든 사용자 시나리오나 엣지 케이스를 포함하지도 않는다.
성능, 확장성, 보안 관련 문제는 별도의 전문 테스트가 필요하다. 테스트 환경과 실제 프로덕션 환경의 차이에서 발생하는 문제 역시 스모크 테스트만으로는 충분히 드러나지 않을 수 있다.
스모크 테스트는 회귀 테스트, 통합 테스트, 성능 테스트 등과 함께 품질 보증 전략 안에 배치할 때 제 역할을 한다.