안녕하세요. 라이프스타일 플랫폼인 디플롯 서비스를 전담하고 있는 QA 엔지니어 콩🫘입니다.
QA엔지니어로 일을 하다 보면 다양한 환경을 경험할 수 있습니다. 각기 다른 환경을 겪다 보면 때로는 게임 속에서 퀘스트를 풀어나가는 과정같다는 생각이 들 때가 있는데요. 이번 포스트에서는 제가 경험한 여러 퀘스트 중 하나를 이야기해보려 합니다.
당신은 품질 전담 인력이 없는 팀에 혈혈단신 홀로 합류하게 되었다. 이 때 가장 먼저 할 일은?
- 당장 눈앞에 있는 작업부터 테스트한다.
- 기능을 하나하나 확인하기 전 서비스 전체 흐름을 먼저 익힌다.
- 자동화 시스템을 먼저 만들고 시작한다.
여러분의 선택은 무엇인가요? 사실 정답이 있는 문제는 아니었습니다(찡끗).
왜냐하면 팀의 상황, 서비스의 성격, 그리고 리소스 조건에 따라 모두 정답이 될 수 있으니까요.
품질 담당이 전무한 디플롯 개발팀에 1인 QA 체제로 합류한 후, 제가 중점적으로 고려한 것은 세 가지였어요.
왜 해야하는지
판단 기준은 무엇인지
지금 우리 팀에 필요한 프로세스인지
무엇을 했는지가 아니라 왜 그렇게 했는지에 초점을 맞춰 ‘품질 관리’에 대해 함께 고민하고 체계를 만들어간 과정을 공유드리려 합니다. 품질 관리 체계가 없거나 리소스가 부족한 QA 조직의 실무자분들에게 도움이 되길 바랍니다. 🫢🫢
STEP 1. 서비스 익히기 - 단순 기능이 아닌 사용자 관점에서
새롭게 합류한 QA 엔지니어로서 가장 먼저 한 일은 도구를 고르는 것도, 테스트 케이스를 만드는 것도 아니었어요.
‘이 서비스는 어떤 흐름으로 움직이는가?’
즉, 서비스를 사용자 관점에서 이해하고 따라가 보는 것이 먼저였습니다. 그래야 어떤 문제가 사용자 경험에 치명적인 영향을 줄지 판단할 수 있으니까요. 🤔
그리고 사용자 관점에서 파악한 흐름을 기준으로 해피패스를 정의했습니다.
사람들이 이커머스 서비스를 이용하는 이유는 무엇일까요? 당연히 구매 하기 위해서겠지요?
'구매'라는 목적을 달성하기 위한 해피패스는 이렇습니다.
앱/웹 실행 → 로그인 → 상품 탐색 → 상품 상세 진입 → 장바구니 담기/바로구매 → 주문서
이를 뿌리로 삼아 해피패스의 각 단계를 세분화했어요. 그리고 마지막으로 우선순위 기준을 설정했는데요, 바로 사용자 비중과 리스크입니다.
검증 항목은 0순위, 1순위, 2순위로 나누었습니다.
가장 먼저 확인해야 할 중요 항목은 0순위였습니다. 1순위는 무조건 수행하는 기본적 테스트 범위이고, 2순위는 리소스 상황에 따라 유동적으로 수행 여부를 판단했습니다.
예를 들어, 로그인 기능이라면
- 이메일 로그인
- 카카오 로그인
- 네이버 로그인
- Apple 로그인
네 가지 로그인 수단 중 어떤 걸 선택하더라도 로그인되어야 서비스를 이용할 수 있습니다. 그래서 이 경우 전부 해피패스로 간주합니다. 단, 리소스가 한정적이기 때문에 사용자 점유율과 장애 리스크를 기준으로 카카오 로그인을 0순위로 가장 먼저 검증하고, 나머지 수단은 1순위로 설정했습니다.
이렇게 테스트 대상에 사용자 점유율과 장애 리스크, 두 가지 기준을 우선순위로 설정해 관리했더니 제한된 리소스로도 핵심 기능의 안정성을 보장할 수 있었습니다.
STEP 2. 기반 다지기 - 부딪히기 전에 기초부터
고객이 일상을 건강하고 아름답게 가꿀 수 있도록 끊임없는 에너지와 영감을 제공하는 올리브영에서는 라이프스타일 커머스 플랫폼 "디플롯"을 함께 운영하고 있습니다. 국내 뷰티&헬스 트렌드 리딩 플랫폼을 넘어 고객에게 더 다양한 웰니스 경험을 선사하기 위함인데요, 올리브영 앱과는 완전히 분리된 별도의 서비스로 운영되고 있습니다. 🙃 서비스 구조도 다르고, 유입량과 트래픽, 인시던트가 미치는 비즈니스 임팩트도 전혀 다르죠. 그렇기 때문에 디플롯 서비스에 맞는 QA 기준이 필요했습니다!
✅ 테스트 환경을 분리하고 정의했습니다.
개발을 위한 DEV 환경은 있었지만, 디플롯 서비스에서는 개발과 자체 테스트가 동시에 진행하고 있었어요.
그래서 검증 중에 이슈가 발생해도 원인을 정확히 파악하기 어려웠습니다. 테스트 결과 역시 신뢰하기 어려운 경우가 있었지요.
그래서 QA 전용 환경을 새로 구성했습니다. 개발자가 자체 테스트를 마친 작업만 QA 환경에 반영해 검증하는 흐름을 만들었어요.
검증을 위한 환경이 따로 만들어져서 안정된 테스트가 가능해졌습니다! 테스트 일정 또한 예측 가능한 범위로 운영할 수 있었습니다.
✅ 이슈 티켓의 우선순위 기준을 만들었습니다.
이슈 티켓의 우선순위 기준이 필요했던 가장 큰 이유는, 서비스에서 또는 프로젝트 진행 중 발견된 이슈를 명확하게 판단하기 위해서였습니다. 무엇까지 수정하고, 어디부터 다음 배포로 넘길 수 있을지를 구분해야 했어요. 🤔
왜냐구요? PO, 개발, 디자인, QA. 모두가 같은 기준 위에서 이슈의 우선순위를 판단하고 조율할 수 있어야 하니까요!
프로젝트의 QA를 진행하기 위해 팀에서 정의한 예시를 보여드릴게요. 이슈의 영향도, 발생 범위, 재현 빈도를 기준으로 우선순위를 정했습니다. 실전에서는 아래 사진처럼 사용되었어요!
심각도(Severity)와 우선순위(Priority)를 함께 고려해 정의해두니 팀 전체가 같은 언어로 이슈를 판단하고 결정할 수 있게 됐습니다.
STEP 3. 흐름 만들기 - 언제 테스트하고, 어떻게 종료할 것인가
리소스가 한정된 상황에서 ‘테스트를 한다’는 기준만으로는 제품의 품질을 보증하기가 어렵습니다.
그래서 테스트를 언제 시작하고, 어떻게 종료하며, 어떤 기준으로 sign-off 할지를 정의했어요.
✅ 테스트 시작 조건을 정의했습니다.
테스트를 단순히 “개발 완료”만으로 시작하면 여러 문제가 발생할 수 있습니다.
(다들 한 번씩 겪어보셨을 거 같네요 코쓱…)
- ❗UI 작업이나 디자인 검토가 끝나지 않은 상태라 테스트 도중 요구사항이 변경될 수 있습니다.
- ❗배포가 완료되지 않은 상태라 기능이 아직 동작하지 않는데도 이를 이슈로 오인할 수 있습니다.
- ❗개발자의 자체 테스트가 진행되지 않았다면 기본 동작 오류가 반복해서 발견되기도 합니다.
그래서 아래처럼 테스트 시작 조건을 설정했습니다.
✔️ 개발, PO, 디자인 담당자의 자체 테스트가 완료되었는가?
✔️ 테스트 환경에 작업이 배포되었는가?
- BE : 테스트 서버 배포 완료
- FE : 테스트 서버 배포 완료
- APP : 테스트 빌드 버전 공유 완료
이렇게 최소한의 조건을 명확히 하고, 반복 테스트나 불필요한 이슈 등록을 배제했어요. 그렇게 늘 신뢰할 수 있는 기준 위에서 검증을 시작할 수 있었습니다.
✅ 테스트 종료 조건을 정의했습니다.
테스트를 마쳤다고 판단하는 기준이 명확하지 않으면 혼란이 시작됩니다. 검증 단계인지, 완료인지, 혹은 특정 기능의 테스트만 완료된 건지, 함께 일하는 모두가 혼란스러울 수 있어요. 🤔🤔🤔
특히 서버 작업이 포함된 경우 버전 간의 호환성이나 돌발 상황으로 인한 롤백에 대한 대응까지 고려해야 하죠.
그래서 우리는 아래 조건을 모두 충족한 경우에만 테스트가 종료된 것으로 판단하도록 기준을 정했습니다!
✔️ 테스트 케이스 또는 체크리스트 수행이 100% 완료되었는가?
✔️ 탐색적 테스팅 수행이 완료되었는가?
✔️ 하위 호환 테스트 및 롤백 테스트가 수행되었는가? (서버 작업이 있는 경우)
- 하위 호환 테스트 : 서버 ON 상태에서 앱 또는 FE 이전 버전이 정상 동작하는지 확인
- 롤백 테스트 : 서버 OFF 상태에서 앱 또는 FE 작업 버전이 정상 동작하는지 확인
테스트 케이스 수행 외에 탐색적 테스팅까지 완료 조건에 추가한 이유는! 실제 운영 환경에서 발생할 수 있는 예외 상황까지 확인하기 위함입니다.
(사용자들은 문서화된 테스트 케이스대로만 행동하진 않으니까요 ㅎㅅㅎ)
단순히 즉흥적으로 눌러보는 애드혹 테스팅이 아니었습니다. 사전에 목적을 설정하고 실제 사용자의 흐름을 따라가는 탐색적 테스팅이 리스크 확인에 알맞다고 판단했어요!
완료 기준을 통해 QA 담당자 뿐만 아니라 팀 전체가 테스트 누락 없이 수행 범위를 명확히 확인할 수 있었습니다.
✅ sign-off 기준을 정의했습니다.
테스트가 종료되었다고 해서 곧바로 배포할 수 있는 건 아닙니다.
배포는 단순히 코드를 반영하는 작업이 아니라 이 기능을 사용자에게 제공해도 된다는 팀의 합의이니까요!
발견된 치명적인 이슈가 아직 남아있거나, 배포 후 돌발 상황에 대한 대응 방안이 준비되지 않았다면 “테스트가 완료되었다”는 사실만 기준으로 배포해선 안 되겠지요?
그래서 우리는 아래 조건을 모두 충족한 경우에만 sign-off 상태로 판단하기로 했습니다.
✔️ 테스트 종료 조건을 충족했는가?
✔️ 테스트 결과가 팀 내부에 공유되었는가?
✔️ 발견된 이슈가 우선순위에 따라 처리되었는가?
- 매우 높음 / 높음 → 반드시 배포 전 수정
- 보통 / 낮음 / 매우 낮음 → 프로젝트 구성원과 협의 후 처리 여부 결정
✔️ 롤백 플랜이 논의되었는가?
그 결과 배포 전의 판단이 감이 아닌 기준에 따라 이뤄질 수 있었고, 팀 전체가 품질 상태를 함께 바라보며 결정을 내릴 수 있었습니다.
품질을 지킨다는 것의 의미
품질을 지킨다는 건 무엇일까요?
사실 아직도 저한테는 명확히 이것입니다!라고 말하기 어려운 주제예요. 🫣 하지만 한 가지 분명한 건, 단순히 테스트를 수행하는 것만으로는 부족하다는 점입니다.
테스트가 의미있게 작동하려면 그 테스트가 언제, 무엇을, 어떤 기준으로 수행돼야 하는지를 정하는 과정이 꼭 있어야 한다고 생각해요.
위 과정들을 통해 우리는 서비스에 맞는 QA 기준을 세웠고, 불확실한 판단 없이 팀원들 모두 같은 기준 위에서 품질을 바라보고 있답니다.
앞으로 더 나은 문화를 만들어갈 수 있도록 노력하겠습니다.
글 읽어주셔서 감사합니다. 🙇
