시간을 정한 탐색 테스트

탐색을 질문으로 시작합니다

정형 사례는 합의된 입력과 기대 결과를 반복하기 좋습니다. 그러나 사용자가 오류를 고친 뒤 다시 제출하거나 마우스 없이 이동하는 흐름은 표의 한 행만 읽어 놓칠 수 있습니다. 탐색 테스트는 실행하며 배우고 다음 시도를 조정하는 활동입니다. 무작위로 클릭하는 시간이 아니라 관찰할 위험을 질문으로 좁히는 시간입니다. 이번에는 가입 오류 후 복구와 입력 방법의 차이를 중심으로 탐색합니다.

탐색 목표인 charter는 대상·행동·위험을 담습니다. “가입을 봅니다”보다 “빈 입력 거절 뒤 이메일을 채워 같은 폼에서 다시 가입할 수 있는지 확인합니다”가 실행 선택에 도움이 됩니다. 이미 알려진 길이 결함만 반복해서 보고서 수를 늘리지 않습니다. 이전 cases를 기본 지도처럼 사용하되 표 밖에서 발견한 상태와 질문은 탐색 노트에 추가합니다. 새 기대값이 합의되지 않았다면 질문으로 구분합니다.

20분을 나누어 관찰합니다

이번 시간 상자는 20분입니다. 처음 3분에 데이터 초기화와 목표를 확인하고, 12분에 입력·키보드·복구 흐름을 시도하며, 마지막 5분에 증거와 다음 질문을 정리합니다. 시간 제한은 결함이 하나도 없으면 실패라는 압박이 아닙니다. 정해진 위험에 집중하고 종료 시점에 확인한 범위를 설명하기 위한 장치입니다. 중간에 새 위험을 찾으면 남은 시간과 중요도를 보고 다음 세션으로 넘길 수 있습니다.

관찰마다 시작 상태, 행동, 기대, 실제, 다음 확인을 적습니다. defects/exploration.json은 charter·timeboxMinutes·observations·excluded를 갖습니다. observations의 topic은 keyboard, empty, double-submit, recovery 네 가지입니다. 실제 실행한 항목은 observed로, 실행하지 않은 항목은 not-run으로 씁니다. not-run에 기대 문장을 실제 결과처럼 복사하면 수행 범위를 부풀린 기록이 됩니다.

처음 상태는 데이터 초기화 버튼과 회원 수 0으로 확인합니다. 가입 성공 후 돌아왔을 때 이전 이메일이 남아 있으면 두 번째 제출은 중복 조건입니다. 따라서 성공·중복·초기화 뒤 성공을 구분해서 기록합니다. 화면 새로고침은 메모리 서버 데이터 초기화와 같지 않습니다. 단순히 브라우저를 새로 열었다는 설명만으로 회원이 없었다는 사전 조건을 대신하지 않습니다.

키보드와 빈 입력을 별도 관찰합니다

keyboard에서는 이메일 입력에 초점을 두고 Tab으로 비밀번호·닉네임·가입 버튼 순서를 따라갑니다. Shift+Tab으로 되돌아갈 수 있는지, 현재 초점이 보이는지 확인합니다. 유효 합성 입력을 채운 뒤 Enter로 제출하고 완료 안내와 이동 화면을 관찰합니다. 클릭 가입이 성공해도 키보드 제출은 별도 행동입니다. 키 입력 순서와 출발 초점을 적어야 다른 사람이 같은 경로를 따라갈 수 있습니다.

초점이 어디로 갔는지 기억으로 쓰지 않고 각 이동에서 테두리와 활성 요소를 확인합니다. 입력 도구나 브라우저 설정 때문에 Tab 대상이 달라질 수 있으므로 브라우저 버전을 적습니다. 화면 캡처만으로 이동 순서는 전달되지 않아 행동 기록이 필요합니다. 이벤트 처리 구현 원리는 더 읽기에서 살펴보고, 여기서는 사용자 행동과 결과를 비교하는 관찰에 집중합니다.

empty에서는 유효 비밀번호와 닉네임을 두고 이메일만 비웁니다. 기대는 이메일 필수 안내와 새 회원 미생성입니다. 이번 폼은 브라우저 기본 입력 검증을 끄고 앱 응답을 관찰하도록 제공됩니다. 요청 자체가 발생하지 않았다면 브라우저 검증과 서버 검증을 구분해 기록해야 합니다. 빈 값과 공백 문자열은 같은 모양으로 보여도 입력 조건이 다르므로 입력을 따옴표와 길이로 나타냅니다.

중복 클릭과 오류 복구를 구별합니다

double-submit에서는 유효한 고유 이메일을 준비하고 가입 버튼을 빠르게 두 번 누릅니다. 회원 수만 보지 말고 요청이 몇 번 나갔는지와 버튼 처리 중 상태도 관찰합니다. 화면은 처리 동안 버튼을 비활성화하고 서버는 중복 이메일을 거절하지만, 이것이 동시 요청 안전성을 증명하는 것은 아닙니다. 이번 앱은 동기화된 메모리 저장소이며 실제 분산 환경이나 데이터베이스 경합은 확인하지 않습니다.

첫 요청이 끝난 뒤 같은 이메일로 다시 누른 행동은 동시에 두 번 누른 행동과 다릅니다. 두 동작의 시간을 구별하지 않으면 재현자가 다른 시도를 하게 됩니다. 성공 후 가입으로 돌아가기 버튼을 눌러 같은 이메일로 제출하면 중복 안내를 확인할 수 있습니다. 중복 응답은 기대한 거절이므로 제품 실패로 기록하지 않습니다. 새로운 회원 생성이 두 번 된 증거가 있을 때 저장 규칙의 위반을 보고합니다.

recovery에서는 빈 이메일을 제출해 거절된 다음 다른 필드를 유지하고 이메일만 고칩니다. 버튼이 다시 활성화되는지, 안내가 새 응답으로 바뀌는지, 회원 수가 1로 늘어나는지 봅니다. 거절 자체는 기대 동작이지만 거절 후 수정할 수 없다면 별도 복구 문제입니다. API 응답이 정상이어도 화면이 오래된 오류를 유지할 수 있으므로 안내와 데이터 관찰을 함께 적습니다.

노트에서 사실과 추측을 분리합니다

“가입 버튼의 이벤트가 두 번 등록된 듯합니다”는 원인 가설입니다. “한 번 누르고 요청 두 개와 회원 수 증가를 관찰했습니다”는 사실입니다. QA가 소스 원인을 미리 확정하면 다른 가능성을 가리는 보고가 됩니다. 노트의 actual에는 관찰을, next에는 요청 수 재확인이나 초기화 반복 같은 다음 행동을 적습니다. 비교 기준은 기존 인수 기준과 추가 계약에서 가져옵니다.

이번 자동 검사는 노트의 구조와 네 관찰 주제, 상태 및 필수 필드가 있는지 확인합니다. UI가 실제로 움직였는지 판단하지 않습니다. 완성본은 브라우저 미실행을 not-run으로 명시한 제출 형식 예시입니다. 자신의 목표가 수동 탐색 수행이라면 로컬 화면에서 직접 실행한 뒤 실제 값과 브라우저 정보를 갱신해야 합니다. 형식 PASS를 수동 테스트 완료라고 보고하지 않습니다.

Node.js 검사에서 AssertionError가 나오면 기대한 문서 규칙과 실제 노트 내용을 비교합니다. JSON의 쉼표나 따옴표가 틀리면 SyntaxError가 먼저 나고 관찰 검사까지 도달하지 못합니다. 오류 파일명과 줄을 확인하고 문서를 고칩니다. 검사 코드의 조건을 약하게 바꾸면 빠진 관찰을 찾을 수 없게 됩니다. 이 레슨에서는 앱 소스나 테스트 대신 노트를 편집합니다.

종료 기록이 다음 탐색을 만듭니다

20분이 끝나면 발견·보류 질문·제외 범위를 짧게 묶습니다. 탐색 중 심각한 증상을 보았다면 다른 행동을 추가하기보다 초기화 후 그 증상이 다시 나오는지 확인할 다음 세션을 잡습니다. 결함이 없어도 어떤 상태와 입력 방법을 확인했는지 기록하면 가치가 있습니다. “문제 없음” 한 문장은 실행 범위와 잔여 위험을 알려 주지 못합니다.

최종 노트를 읽는 동료가 어떤 행동을 실제로 했는지와 어떤 행동을 앞으로 해야 하는지 구별할 수 있어야 합니다. 이 모듈에서는 로그인·프로필 기능, 접근성 전체 기준, 실제 네트워크 단절 복구는 제외합니다. 제외 근거를 적고 관련 요구사항을 지우지 않습니다. 다음 레슨으로는 관찰에서 합의와 어긋난 사실을 골라 재현 가능한 보고서로 넘깁니다.