2026년 주소 양식 테스트: 40개 항목 QA 체크리스트

먼저 모든 필드, 그 목적, 저장 한도, 필수 여부를 적어 두세요. 이 체크리스트의 결함 중 절반은 그 표 없이는 평가할 수 없습니다. "양식이 내 주소를 거부했다"는 어느 필드가 왜 거부했는지 알기 전까지는 실행 가능한 정보가 아니기 때문입니다.

제약은 전역이 아니라 국가별이어야 합니다. 우편번호 최대 길이를 10으로 하나로 정하면 대부분 국가에는 맞지만 아일랜드는 공백 포함 8자라 깨지고, 도시 최대 길이를 전역 30으로 정하면 실제 이름이 많이 잘립니다. 넉넉한 한도를 설정하고 한 시장을 기준으로 고른 길이가 아니라 국가 패턴으로 검증하세요.

국가를 변경하면 지역을 초기화하고, 우편번호 필드의 레이블을 바꾸고, 키보드와 패턴을 변경하고, 오래된 검증 상태를 지워야 합니다. 전형적인 버그는 미국으로 전환한 뒤에도 캐나다 주가 선택된 채로 남아, 유효해 보이지만 불가능한 값 조합으로 제출되는 것입니다.

홍콩과 아랍에미리트에는 우편번호가 없으므로 필드는 선택 사항이 되어야 하고 레이블에 그렇게 표시해야 합니다. 일본은 주소 순서가 반대이므로, 양식은 필드를 현지 순서로 제시하거나 서구식 순서를 기대한다는 점을 분명히 해야 합니다. 양방향 전환을 테스트하고, 검증 오류가 이미 표시된 후의 국가 전환도 테스트하세요.

형식은 blur 시 검증하고, 필수 필드는 제출 시 검증하며, 값이 유효해지는 즉시 오류를 지우세요. 키 입력마다 검증하면 우편번호를 입력하는 도중인 사용자를 괴롭히고, 제출 시에만 검증하면 사용자가 안내 없이 한 번에 여섯 개의 오류를 발견하게 됩니다.

검증 대신 제출 버튼을 비활성화하지 마세요. 설명 없는 비활성 버튼은 주소 양식에서 가장 흔한 접근성 불만입니다. 사용자는 무엇이 빠졌는지 알 수 없고 스크린 리더가 변경을 알리지 않을 수 있기 때문입니다. 버튼은 활성 상태로 두고, 제출하게 한 뒤 각 필드로 연결되는 요약을 표시하세요.

오류 메시지는 어느 필드가 잘못되었는지, 허용되는 형식은 무엇인지, 어떻게 고치는지를 말해야 합니다. "유효하지 않은 주소"는 세 가지 모두 실패합니다. "우편번호는 5자리여야 합니다. 예: 97205"는 통과합니다. 형식이 특이한 국가의 경우 사용자는 정규식을 읽지 않으므로 패턴 대신 예시를 포함하세요.

오류는 필드 옆에 두고, 양식이 길면 상단 요약에도 두세요. aria-describedby로 연결하고 입력에 aria-invalid를 설정하세요. 제출 시 첫 번째 잘못된 필드로 포커스를 이동하거나, 요약이 상호작용 가능하면 요약으로 이동하세요. 시각적으로만이 아니라 스크린 리더로 테스트하세요.

붙여넣기는 형식 버그가 드러나는 지점입니다. 사용자가 줄바꿈 없는 공백이 포함된 "K1A 0B1"을 붙여넣거나 전체 주소를 1행에 붙여넣습니다. 양식은 trim하고 알려진 구분자를 정규화하며 내부 공백을 보존해야 합니다. ZIP+4나 네덜란드 코드에서 하이픈을 제거해서는 안 되고, 정당하게 대소문자가 섞인 도시 이름을 대문자로 바꿔서도 안 됩니다.

자동 완성은 올바른 토큰 이름에 달려 있습니다. address-line1, address-line2, 도시에는 address-level2, 지역에는 address-level1, postal-code, country를 사용하고, 단일 행 필드에 street-address를 재사용하지 마세요. 정말 여러 줄 주소 블록인 경우가 아니면 안 됩니다. 모바일에서 숫자 키보드에는 보통 하이픈이 없으므로 inputmode="numeric"으로 입력한 ZIP+4나 네덜란드 코드는 완성할 수 없게 됩니다. 패턴이 구분자를 허용하는 곳에서는 inputmode="text"를 사용하세요.

모든 필드에 대해 경계값과 경계값보다 한 글자 더 긴 값을 테스트하세요. 잘림은 거부보다 나쁩니다. 사용자는 성공적으로 제출했다고 보지만 저장된 값은 잘못되기 때문입니다. 데이터베이스 컬럼이 50자인데 양식이 100자를 허용하면, 결함은 긴 입력에서만 나타나며, 이는 수작업 픽스처에 절대 포함되지 않는 바로 그런 경우입니다.

비ASCII 문자를 테스트하세요: 악센트 문자, O Connell의 아포스트로피, 프랑스 거리 이름의 하이픈, 독일 거리 이름의 에스체트, 오른쪽에서 왼쪽으로 쓰는 문자. 값이 API, 데이터베이스, CSV 내보내기, 인쇄 레이블을 거쳐 왕복되는지 확인하세요. 인코딩 버그는 종종 아무도 테스트하지 않는 내보내기 단계에서만 나타납니다.

모든 필드에는 입력과 프로그래밍 방식으로 연결된 보이는 레이블이 필요합니다. 플레이스홀더 텍스트는 레이블이 아닙니다. 입력 시 사라지고 일관성 없이 읽히기 때문입니다. 주소 필드를 legend가 있는 fieldset으로 묶고, 국가 및 지역 선택을 키보드로 조작할 수 있게 하고 type-ahead를 제공하세요.

오른쪽에서 왼쪽으로 쓰는 로케일의 경우 개별 입력이 아니라 컨테이너에 dir을 설정하여 구두점과 오류 아이콘이 올바른 위치에 유지되게 하세요. 번역된 레이블이 200퍼센트 확대에서 넘치지 않는지, 오류 요약이 나타날 때 읽히는지 확인하세요. 이는 접근성 감사에서 비용을 청구하는 결함을 잡아내는 저렴한 점검입니다.

체크리스트를 모든 변경 시 실행되는 작은 자동화 팩으로 바꾸세요. 스무 개의 케이스가 실패 집합을 커버합니다: 주요 시장의 유효 및 무효 케이스 각각 하나, 캐나다, 영국, 독일, 일본, 브라질, 홍콩, UAE 각각 하나, 경계 길이, 비ASCII 도시, 줄바꿈 없는 공백이 포함된 붙여넣기 값, 오류 후 국가 전환.

각 케이스를 독립적이고 시드되게 유지하세요. 리터럴 문자열이 아니라 결과의 형태를 검증하고, 무효 케이스의 경우 보이는 오류 텍스트를 검증하세요. 오류 문구 회귀는 실제 회귀이기 때문입니다. 이 정도 규모의 팩은 몇 초 안에 실행되며 위에서 설명한 결함의 대다수를 잡아냅니다.