Saas 플랫폼에서의 배포 테스트

Saas 형태의 플랫폼이 많아지다 보니, 테스트 전략도 조금씩 변해야 하는것 같다.
잊어버리지 않고 전략을 잘 구상하기 위해 간단히 정리해 보자.

1. Smoke Test와 Sanity Test 차이 (SaaS 플랫폼 기준)

목적	시스템이 "기본적으로" 동작하는지 빠르게 확인	특정 기능이나 버그 수정이 제대로 동작하는지 확인
범위	광범위하고 얕음 (전체 시스템 핵심 기능)	좁고 깊음 (수정/추가된 부분 중심)
시기	빌드 후 가장 처음	기능 추가/수정 이후 빠른 확인 단계
질문 형태	"이 빌드 배포 가능한가?"	"이 수정 정상적으로 반영됐는가?"
실패 시	전체 테스트 중단	추가 세부 테스트 보류

 

• Smoke Test: SaaS 서비스가 전체적으로 켜지고, 로그인/회원가입/대시보드 진입 정도는 되는지 정도의 수준
• Sanity Test: 예를 들면 로그인 API 수정 후, 로그인+로그아웃 기능만 빠르게 돌려보는 정도의 수준

2. SaaS 플랫폼용 테스트 전략 및 구성 제안

Smoke Test 전략 (배포 직후 돌릴 것)

• 핵심 기능만 빠르게 검증: 로그인, 대시보드 진입, 주요 API 응답 여부
• 빠른 피드백을 위해 API 테스트 중심
• UI 테스트는 "페이지 로딩", "로그인 성공" 정도만 최소화
• 구성:
  • API: 서버 헬스 체크 (/health), 인증 API, 메인 리소스 API
  • UI: 홈 → 로그인 → 대시보드 진입 확인

Sanity Test 전략 (수정사항 있을 때 돌릴 것)

• 변경된 기능 위주로 집중적으로 확인
• API와 UI 둘 다 테스트
• 케이스는 변경 범위에 따라 유동적으로 생성
• 구성:
  • API: 수정된 API만 집중 (예: 로그인 리뉴얼이면 로그인 API만)
  • UI: 변경된 화면 흐름만 확인 (예: 로그인 페이지 변경시 → 로그인 화면 → 로그인 후 화면 흐름)

 

더불어, 요즘은 QA 영역이 테스트 자동화까지 구축 하는 흐름이라 Smoke, Sanity의 자동화 기능을 추가해 보자면,

3. API 자동화  vs UI 자동화 분리 방법

API 자동화:

• Smoke: 빌드 성공 직후, 배포 완료 직후 빠르게 전체 주요 API를 검증
• Sanity: 변경된 API만 골라서 추가로 테스트
• 도구: Postman (Collection Runner), Python (Requests + pytest), JavaScript (newman, Playwright API Testing)

UI 자동화:

• Smoke: 로그인 → 대시보드 진입까지 최소 경로만 자동화
• Sanity: 변경된 페이지, 컴포넌트만 빠르게 자동화
• 도구: Playwright, Cypress, Selenium