원문 캡처 · hitest.ai
원문 캡처 · hitest.ai

기능을 배포하기 전 모든 것을 확인하기 어렵다면, 고객이 제품에 기대하는 핵심 여정 몇 가지부터 정하고 결과를 검증하는 편이 낫다. 이 가이드는 혼자 SaaS를 개발하는 사람을 위해 출시 범위를 정하고, 테스트 결과와 남은 위험을 기록하는 방법을 설명한다.

이 가이드는 가상의 프로젝트 관리 SaaS를 예로 든다. 실제 제품에서는 고객이 만드는 대상에 맞춰 프로젝트를 보고서, 예약, 캠페인, 문서 또는 테스트 실행으로 바꾸면 된다.

[고객이 의지하는 약속부터 정한다](https://hitest.ai/blog/how-to-test-saas-solo-developer#start-with-the-promises-customers-depend-on)

제품이 고객에게 제공하는 약속 세 가지를 적는다. 예시 SaaS라면 새 사용자가 워크스페이스와 첫 프로젝트를 만들 수 있고, 기존 고객이 프로젝트를 수정해 나중에 저장된 변경 사항을 확인할 수 있으며, 워크스페이스 소유자가 의도한 권한으로 팀원을 초대할 수 있다는 약속이 될 수 있다.

이 약속들은 테스트 범위를 정하는 출발점이다. 랜딩 페이지가 정상적으로 열려도 세 가지 약속이 모두 지켜지지 않을 수 있다. 추가 테스트는 문제가 생겼을 때의 결과, 기능 사용 빈도, 변경 중인 영역을 고려해 고른다. 드물게 바꾸는 결제 기능이 자주 쓰이는 꾸미기 설정 기능보다 결과가 중대하다면, 결제 기능을 더 꼼꼼히 확인할 수 있다. 이를 위해 수치로 된 위험 계산식을 만들 필요는 없다.

각 약속마다 시작 계정과 데이터, 수행할 동작, 확인할 결과를 정한다. 자동화부터 시작하는 대신 이런 결정을 먼저 내리면 복잡성을 더하기 전에 빠진 조건을 발견할 수 있다. 성공적인 클릭은 중간 과정일 뿐이다. 고객이 의도한 결과를 확인해야 테스트가 끝난다.

[작은 테스트 묶음으로 시작한다](https://hitest.ai/blog/how-to-test-saas-solo-developer#build-a-small-starting-suite)

다음은 시작할 때 고려할 수 있는 테스트다. 다섯 가지면 모든 SaaS에 충분하다는 뜻은 아니다.

여정시작 조건확인할 결과
새 사용자 활성화워크스페이스가 없는 새 계정사용자가 워크스페이스와 첫 프로젝트를 만든다
기존 사용자 접근저장된 프로젝트가 있는 기존 멤버로그인한 뒤 올바른 워크스페이스와 프로젝트가 나타난다
생성 및 수정생성 권한이 있는 멤버저장된 필드가 새로고침하고 다시 열어도 유지된다
권한 경계기존 프로젝트가 있는 뷰어 계정뷰어가 읽을 수 있지만 권한 없는 변경 사항은 저장할 수 없다
유료 접근(제공하는 경우)결제 샌드박스의 계정선택한 구매에 맞는 제품 접근 권한이 부여된다

서로 다른 실패를 막아주는 테스트를 추가한다. 같은 양식의 유사한 입력 사례 열 가지는 검증 코드 가까이에서 확인하는 편이 나을 수 있다. 반면 초대를 수락하는 여정은 다른 시스템들이 함께 작동하는지 확인한다.

테스트하지 않은 항목도 기록한다. 내보내기 기능을 확인하지 않았다면 그 공백을 적어 둔다. 그래야 테스트가 모두 통과했다는 사실을 전체 기능을 빠짐없이 점검했다는 뜻으로 오해하지 않는다.

[깨끗한 상태에서 고객 여정을 따라간다](https://hitest.ai/blog/how-to-test-saas-solo-developer#walk-one-journey-from-a-clean-starting-point)

프로젝트 생성 흐름을 예로 들면, 격리된 테스트 워크스페이스의 전용 계정으로 시작한다. 실행마다 고유한 프로젝트 이름을 사용해 오래된 기록이 테스트를 우연히 통과시키지 않도록 한다.

  • 로그인한 뒤 선택된 워크스페이스를 확인한다.
  • 프로젝트 생성 양식을 연다.
  • 고유한 이름과 필수 항목을 입력한다.
  • 제출하고 새 프로젝트가 나타나는지 확인한다.
  • 페이지를 새로고침하고 같은 프로젝트를 찾는다.
  • 프로젝트를 열어 저장된 필드가 입력값과 일치하는지 확인한다.

네 번째 단계에서 성공 알림을 확인하는 것은 유용하지만, 데이터가 새로 읽혀도 남아 있다는 뜻은 아니다. 이 예시에서는 여섯 번째 단계가 완료 조건이다.

정리 작업의 범위도 명확히 정한다. 테스트 실행에서 만든 기록만 삭제하거나, 자체 픽스처 절차로 전용 워크스페이스를 초기화한다. 고객 데이터가 섞인 공간은 테스트 데이터로 쓰기 적절하지 않다.

[세부 규칙은 코드 가까이에서 확인한다](https://hitest.ai/blog/how-to-test-saas-solo-developer#put-detailed-rules-near-the-code)

브라우저 테스트는 인터페이스, 인증, 백엔드, 저장소가 맞물리는 지점을 확인하는 데 유용하다. 다만 하나의 규칙만 겨냥한 테스트보다 실패 원인을 파악하기 어려울 수 있다.

양식에 여러 입력 검증 조합이 있다면, 가능할 때 컴포넌트나 서비스 계층에서 해당 규칙을 확인한다. 브라우저에서는 양식이 실제 저장 작업과 연결되고 결과를 올바르게 보여주는지 확인하는 여정을 남긴다.

이는 Playwright의 테스트 지침이 강조하는 사용자 관점의 접근과 맞닿아 있다. 해당 지침은 테스트 상태를 서로 독립적으로 유지할 것도 권한다. 전담 QA 담당자 없이 테스트 묶음을 관리해야 할 때 특히 중요하다.

프레임워크, 수동 체크리스트, AI 브라우저 도구 중 무엇을 쓰든 완료 조건은 같아야 한다.

[테스트를 진행 중인 릴리스에 연결한다](https://hitest.ai/blog/how-to-test-saas-solo-developer#attach-testing-to-the-release-you-are-making)

핵심 고객 여정 테스트와 현재 변경 사항에 따른 추가 테스트, 두 묶음으로 나눈다. 권한을 바꾼다면 역할과 워크스페이스 관련 항목을 더한다. 푸터 문구를 고친 경우라면 보통 더 좁은 범위로 확인하면 된다.

테스트 결과와 함께 환경, 배포된 버전을 기록한다. 어제 스테이징에 배포된 버전에서 테스트를 통과했더라도 오늘의 릴리스 후보가 정상 작동한다는 근거가 되지는 않는다.

테스트가 실패하면 제품, 설정, 테스트 자체 중 어디에서 문제가 생겼는지 확인한다. 조사하는 동안 관찰된 실패를 그대로 기록한다. 원래 질문에 답하지 않은 채 통과할 때까지 반복 실행해서는 안 된다.

계정이 없거나 서비스 제공자를 사용할 수 없어 실행하지 못한 테스트는 통과가 아니라 차단된 테스트다. 이를 조용히 통과 처리하지 말고 출시 결정에 드러내야 한다.

[검사 절차를 반복할 수 있게 만든다](https://hitest.ai/blog/how-to-test-saas-solo-developer#make-the-routine-repeatable)

릴리스 노트 옆에 다음 항목을 간단히 기록한다.

  • 변경 사항: 이번 릴리스가 어떤 고객 행동에 영향을 줄 수 있는가?
  • 핵심 테스트: 이 버전에서 어떤 필수 여정을 실행했는가?
  • 추가 테스트: 관련된 어떤 행동을 더 확인했는가?
  • 근거: 결과, 스크린샷, 재현 절차는 어디에 있는가?
  • 남은 위험: 무엇이 실패했거나 차단됐으며, 무엇을 테스트하지 않았는가?
  • 결정: 이유와 함께 출시할지, 수정할지, 범위를 줄일지 정한다.

HiTest는 실제 브라우저에서 정의된 여정을 실행할 수 있다. 정확한 테스트 사례 하나부터 시작하고 테스트 계정을 선택한 뒤, 반복 계획으로 사례를 묶기 전에 실행 결과를 검토한다. 서비스 계층의 검증과 픽스처 관리는 각각 해당 작업을 담당하는 도구에 맡긴다.

첫 공개 릴리스 전에는 출시 전 체크리스트를 활용한다. 정기적으로 배포하기 시작하면 변경 사항에 따른 회귀 테스트를 참고해 매번 새로운 근거가 필요한 항목을 정한다.

[상황에 맞는 다음 테스트를 고른다](https://hitest.ai/blog/how-to-test-saas-solo-developer#choose-the-next-check-for-your-situation)

이 창업자 테스트 시리즈는 SaaS 제품 개발 과정의 여러 시점을 다룬다.