QA 플레이북¶

우리에겐 QA 전담 인력이 없다. 그래서 전원이 QA를 병행한다 — 각자 맡은 영역을 문서 기반으로 테스트 케이스로 만들어 직접 돌리고, 나온 버그는 Jira "디에듀QA" 프로젝트에 등록해 추적한다. 이 페이지는 배포 전에 무엇을 어떻게 검증할지, 테스트 전략부터 케이스 작성법까지를 한 장에 모은 것이다. 뒤에 나올 알파테스트는 프로덕트팀 전원이 직접 써보고 개발팀(FE1·BE1)이 실시간으로 받쳐주는 식으로 돌린다.

두 축으로 본다¶

테스트를 두 종류로 나눈다. 하나는 기능이 깨졌나를 빠르게 보는 스모크 테스트, 다른 하나는 사용자가 막히나를 보는 알파테스트다. 앞은 코드가 도는지를, 뒤는 사람이 멈칫하는지를 본다 — 둘은 잡는 게 다르다.

축	무엇을 보나	언제
스모크 테스트	핵심 플로우가 깨지지 않는지 빠르게 확인	릴리스 직전
알파테스트	사용자가 기대한 흐름이 막히는 지점(UX·신뢰성)	GA 구축 전·후 2회

어느 쪽이든 발견한 건 재현 절차와 함께 QA tracker(Notion DB)와 Jira 코멘트에 남긴다.

스모크 — 핵심 플로우가 사나¶

인증: 로그인/로그아웃/회원가입 정상, 토큰 만료 시 자동 로그아웃+재발급, 새로고침 시 로그인 유지, 401 시 /login 리다이렉트
스터디룸(선생님): 생성 → 수업노트 작성
스터디룸(학생): 입장 → 수업노트 조회 → 질문 등록
과제(선생님): 생성 → 마감일 설정 / (학생) 제출
온보딩: 회원가입 → 역할 선택 → 프로필 설정
초대 플로우

인증 쪽 항목(토큰 재발급·로그아웃·새로고침 유지 등)이 유독 촘촘한 건, 초기 QA에서 바로 여기서 사고가 났기 때문이다. 한 번 겪은 함정은 회귀 항목으로 박아 둔다.

알파테스트 — 사용자가 막히나¶

알파테스트는 관점이 다르다. "기능이 구현됐나"가 아니라 "사용자가 어디서 멈칫하나"를 찾는다. 비번 찾기·문의·로그아웃·홈 이동 같은 기본 동선이 막히면 우리는 그걸 단순 누락이 아니라 신뢰 손상 리스크로 분류한다.

돌리는 방식은 이렇다. 강사·학생·학부모 역할별로 더미 계정을 써서 E2E로 처음부터 끝까지 써본다. 한 회는 테스트 2일에 정리 1일, 총 2회를 돈다. 프로덕트팀 전원이 직접 체험하고 개발팀(FE1·BE1)이 실시간으로 받친다. 결과물로 역할별 체험 보고서, UX 개선안, Top 이슈 리포트를 남긴다.

체험하면서 다음을 눈여겨본다: - [ ] 계정: 비번 찾기/정보 수정/회원탈퇴 위치를 10초 내 찾는가 - [ ] 네비: 홈/공지/도움말/푸터 동선이 막히지 않는가 - [ ] 문의·지원: 문의하기·FAQ·버그 제보 경로가 노출되는가 - [ ] 피드백: 저장 후 완료 토스트, 입력 오류 사유 표시가 있는가 - [ ] 위치 인지: 현재 페이지·뒤로가기 동작이 예상과 맞는가

시각·반응형·환경¶

기능이 맞아도 화면이 깨지면 사용자는 못 쓴다. 그래서 다음도 같이 본다. 검증은 약 1,000건 규모(스터디룸 50, 룸당 학생 30, 노트 500)의 더미 데이터 위에서 한다.

터치 범위·크기가 충분하고 색 대비가 괜찮은가
모바일에서 폰트·간격이 깨지지 않고, 태블릿 가로세로 전환·팝업 이탈이 없는가
Chrome·Safari·Edge에서 동일하게 동작하고, 확대·축소 시 겹침이 없는가

테스트 케이스는 이렇게 쓴다¶

케이스의 단위는 회원가입·로그인 같은 플로우고, 그 아래에 세부 케이스를 단다. 양식은 Google Sheets 템플릿을 쓰며, "디에듀-로그인 테스트 스위트"가 로그인 플로우를 단위로 두고 세부 케이스를 행으로 나열한 표본이다. 진행 상태는 다섯 단계(Not Started / In Progress / Blocked / Skipped / Closed)로 관리하는데, 서버 다운이나 계정 불가로 Blocked가 걸리면 사유를 메모에 구체적으로 남긴다. 회귀를 추적하려면 어느 빌드에서 테스트했는지가 중요하므로, 테스트 버전 컬럼에 빌드 번호를 반드시 적는다. Notion DB는 테스트 항목·상태·담당자·테스트 버전·수행일·종료일·메모 컬럼으로 구성된다.

피드백은 행동·멈칫·기대를 함께¶

피드백을 쓸 때 "안 됨", "UX 별로임" 같은 모호한 말은 도움이 안 된다. 대신 무엇을 했고, 어디서 멈칫했고, 무엇을 기대했는지를 함께 적는다 — 예를 들어 "노트 저장 후 화면 변화가 없어 저장됐는지 헷갈림 → 완료 토스트 필요"처럼. 기획 의도에 얽매이지 말고, 명세와 다르면 멈춰서 헷갈린 이유를 중심으로 기록한다.

검증할 때 지키는 것¶

QA를 돌릴 때 몇 가지를 못 박아 둔다. 테스트는 반드시 더미 계정으로만 한다(실계정 금지) — 더미 계정 비밀번호 같은 값은 원본 테스트 계정 문서에만 있다(SENSITIVE). API 에러나 지연이 나면 새로고침으로 덮지 말고 상태를 그대로 보존해 Jira 코멘트로 남긴다. 그리고 앞서 말했듯, 기본 동선이 막히는 건 누락이 아니라 신뢰 문제라 곧장 P0로 올린다.

검증에 쓰는 도구는 버그 티켓을 다루는 Jira "디에듀QA", 테스트 진행을 추적하는 QA tracker(Notion DB), 케이스 작성용 Google Sheets 템플릿, 역할별 더미 계정이다. 접근 경로는 tools-accounts에 있다.