SaaS는 데이터가 중요한 서비스입니다. 사용자가 데이터를 실수 없이 관리하게 하려면 생성(Create), 조회(Read), 수정(Update), 삭제(Delete)의 플로우가 간단하고 명료해야 합니다.

제가 SaaS 서비스의 디자인 하면서 고려했던 CRUD의 플로우를 정리해보았습니다.
HR 서비스를 제공하였던 서비스라, HR 데이터를 예시로 들었습니다.

 * 생성
   * 생성 버튼이 잘 보이도록 화면에 배치해야 합니다.
   * 데이터를 생성하려면 필수/선택이 무엇인지 구분해주어야 합니다.
   * 생성 후 저장했을 때 저장된 데이터가 어디에서 조회되는지 표시해주어야 합니다.
 * 조회
   * 정렬 또는 필터를 사용해서 원하는 데이터를 효율적으로 조회할 수 있도록 해야 합니다. (예: 생성순 정렬 또는 이름 순 정렬 / 부서 또는 직책으로 필터링)
   * 타이포그래피 원칙을 따라 시각적 위계가 있는 정보 전달을 해야 합니다.
 * 수정
   * 수정에는 두 가지 방법이 있습니다.
     * 덮어씌워지는 데이터
       * 최신 상태만 중요한 정보 (예: 연락처 정보)
         * 현재 값을 인풋 필드에 미리 채워 보여줍니다.
         * 수정 후 저장 시 덮어쓰기 경고 알림 등을 띄워줍니다.
     * 히스토리로 쌓이는 데이터
       * 변경 이력이 중요한 정보 (예: 급여 이력, 직책 변경)
         * 현재 값과 함께 이전 이력을 타임라인 형태로 표시합니다.
         * 새 항목 추가와 기존 항목 수정을 명확히 구분하는 UI 제공합니다.
         * 변경 사유 입력 필드 추가로 히스토리의 맥락 제공합니다.
 * 삭제
   * 삭제에도 두 가지 방법이 있습니다.
     * Soft delete
       * 직원 정보
         * 퇴사한 직원의 기록을 완전히 삭제하지 않고 비활성화
         * 이력 추적 및 감사 목적으로 유용
     * Hard Delete
       * 영구 삭제임을 명확히 경고
       * 삭제 전 확인 알럿에서 영구적인 조치임을 강조
       * 중요한 데이터의 경우, 추가 인증 단계 요구 (예: '확인했습니다' 문구 입력)

데이터 관리용 대시보드를 디자인할 때 테이블, 카드, 리스트 등 반복적인 UI 요소를 자주 사용하게 되어 ’내가 정말 디자인을 하고 있는 걸까?’라는 의문이 들 수 있습니다.
하지만 CRUD(생성, 읽기, 수정, 삭제) 각 단계의 흐름을 고려하여 상황에 적합한 정보를 제공하고 사용자의 실수를 방지하는 방안을 깊이 고민하다 보면, 단순한 UI 구성을 넘어 UX까지 고려하게 되고 개발자와의 소통도 더욱 원활해지는 것 같습니다

CRUD 디자인

스타트업에서 QA 프로세스를 체계적으로 구축하고 제품의 완성도를 높이는 것은 쉽지 않은 과제입니다.

회사에서는 개발된 기능을 개발 서버에서 테스트했지만, 실제 서버 배포 후 예상치 못한 버그로 인해 고객 문의가 급증하는 경우가 종종 발생했습니다.

개발 속도가 가속화되고 더 많은 기능을 구현해야 하는 상황에서 QA의 중요성이 점점 더 부각되었습니다.

QA 전담 인력을 바로 채용하기는 어려워, QA담당자로 재직중인 지인의 도움을 받아 QA 프로세스를 학습하게 되었습니다.

아래는 제가 전수받은 QA 프로세스입니다.
QA 전문가분들께서 이 내용을 읽게 되신다면, 개선이 필요한 부분 댓글로 알려주세요!

--------------------------------------------------------------------------------------

1️⃣ 릴리즈 일정이 정해지면 기획 리뷰 진행

2️⃣ 신규 기능에 대한 TC(Test case) 작성
테스트 케이스 작성은 가장 시간이 많이 소요되는 단계입니다. 이 과정에서는 사용자 인터페이스(UI)의 모든 세부적인 동작을 빠짐없이 문서화해야 합니다.

예를 들어, 드롭다운 메뉴가 선택 시 제대로 펼쳐지는지와 같은, 당연해 보이는 기능까지도 꼼꼼히 기록해야 합니다.

TC 작성 방법
 1. 화면의 depth 정의: 해당 케이스를 확인하기 위한 정확한 위치를 적어주기
1 depth: 화면명 (로그인 페이지, 설정 페이지, 모달 등)
2 depth: 페이지 내 영역 (GNB, LNB 등)
3 depth: 컴포넌트 (버튼, 인풋 등)
4 depth: 드롭다운 등 컴포넌트의 하위 (필요하다면 작성)

 2. TC 타이틀 적기: '무엇을 확인하고자 하는지'를 적습니다.
    * 예: 버튼 작동 여부 확인
    * 동일한 TC 타이틀이 있다면 괄호로 몇 개의 중복 TC가 있는지 개수를 적어줍니다.
      * 예: 버튼 작동 여부 확인(3)
 3. 사전 조건 작성: 이 TC를 확인하기 위해 충족되어야 하는 조건이 있다면 적어줍니다.
    * 예: 권한, 스위치 on/off 여부
 4. 절차 작성: TC를 확인하기 위해 실행되어야 하는 절차를 적습니다.
    * 예: 1. 필터 클릭 2. 필터 변경
 5. 기대 결과 작성: 절차를 완료하면 수행되어야 하는 액션을 적습니다. 기획의도가 포함됩니다.
    * 예: 설정한 필터로 테이블 필터링 됨
 6. 우선순위 작성: P0,P1,P2,P3 순으로 비즈니스 관점에서 중요 정도로 선택합니다. (우선순위 정의는 기억이 잘 나지 않아 perplexity에게 물어봐 작성했습니다.)
P0 (최고 우선순위)
- 즉각적인 조치가 필요한 가장 중요한 작업
- 시스템 전체에 영향을 미치는 심각한 문제
- 제품 출시를 지연시킬 수 있는 수준의 중요도
- 예: 앱이 실행 즉시 충돌하는 경우

P1 (높은 우선순위)
- P0 다음으로 중요하며 빠른 해결이 필요한 작업
- 주요 기능의 오작동 또는 많은 사용자에게 영향을 미치는 문제
- 일반적인 업무 일정 내에서 긴급하게 처리해야 함

P2 (중간 우선순위)
- 중요하지만 즉각적인 조치가 필요하지 않은 작업
- 소수의 사용자에게 영향을 미치는 minor한 기능 오류
- 다른 이슈들과 함께 우선순위를 고려하여 처리

P3 (낮은 우선순위)
- 긴급하지 않고 중요도가 낮은 작업
- 일상적인 업무의 일부로 처리 가능한 수준
- 장기적인 목표에 기여하는 작업

 7. 결과 작성
    * 결과를 PASS,FAIL,N/A중 하나를 선택합니다. (N/A는 환경적인 요인으로 케이스 확인이 불가할때 기입합니다.)
 8. Bug ticket no. 작성
    * 노션이나 지라 등 버그 이슈를 취합하는 툴의 링크를 입력합니다.
 9. 코멘트 (필요시 작성)
추가적으로 고려할 수 있는 사항:
- 테스트 환경 (예: 브라우저, 운영체제, 디바이스 등)
- 테스트 데이터
- 테스트 수행자
- 테스트 일자

3️⃣ QA일정 확정
QA일정 확정 후 릴리즈 일정을 확정합니다.

4️⃣ dev서버 테스트
TC 테스트 & 리그레이션 테스트 (이전에 고쳤던 버그가 발생하지는 않는지)

5️⃣스테이지서버 테스트
dev 서버에서 버그 픽스 후, 스테이지서버에 올려 실서버와 동일한 환경에서 테스트를 진행합니다.

6️⃣ 잔존이슈 확인
이전에 픽스한 버그가 또 발생하지는 않는지 확인합니다.

7️⃣ 사인오프
공식적으로 QA가 완료되었다는 것을 공유합니다.

8️⃣ 릴리즈 테스트
실서버 릴리즈 후에는 모든 테스트 케이스(TC)를 확인하기보다는, 주요 기능과 기획 의도에 부합하는 핵심적인 테스트에 집중합니다

9️⃣ QA종료

--------------------------------------------------------------------------------------

이 QA 프로세스를 적용하면서 우리는 이전에 발견하지 못했던 숨겨진 버그들을 찾아낼 수 있었습니다.

특히 여러 화면에서 공통으로 사용되는 컴포넌트의 경우, 새로운 기능 개발로 인해 기존 기능이 영향을 받아 오작동하는 사례를 발견할 수 있었습니다.

테스트 케이스(TC) 작성은 시간과 노력이 많이 드는 작업이지만, 완성 후 QA를 수행할 때는 마치 숨은그림찾기를 하는 것 같이 흥미로웠습니다.

만약 여러분의 제품이 릴리즈 후 예상치 못한 버그로 고민하고 계시다면, 이 글에서 소개한 QA 프로세스가 도움이 되길 바랍니다.

아래 링크에서 테스트 케이스 예시를 확인하실 수 있습니다. 필요하시다면 참고해 주세요.

https://docs.google.com/spreadsheets/d/1KdvBIpkZy778CgN1Fiux3yPMMA1goZySMXZxii6Tkrk/edit?gid=0#gid=0

재직자

윤여익

김하은

UX/UI 디자이너

박승주

주식회사 자버 세일즈 매니저

연제원

개발

추강현

주식회사 자버 마케팅 인턴

김규연

FE developer

자버