고객 작업을 중심으로 커버리지 구성
서비스 찾기, 검색, 상품 추가, 예약, 로그인, 도움 요청, 결제 등 가치를 만드는 경로와 결과를 나열하세요. 각 항목에 대해 모양이 바뀌거나 실패할 수 있는 구성요소를 명명하세요: 내비게이션, 필터, 카드, 표, 이미지, 배너, 폼, 드로어, 포함된 위젯 등. 테스트 대상은 현재 휴대폰 모델 목록이 아니라 콘텐츠가 제약되는 너비입니다. 각 브레이크포인트 바로 아래, 그 지점, 바로 위에서 테스트하세요.
좁은 및 중간 너비 전화기, 태블릿 유사 너비, 노트북, 넓은 데스크톱, 그리고 작업이 바뀌는 경우 가로(landscape)를 포함하세요.
긴 제목, 빈 결과, 검증 오류, 가격 배지, 전체 주소, 긴 라벨 등 존재하는 상태를 사용하세요.
리플로우, 가독성, 확대(줌)를 증명
페이지에 적절한 viewport 설정이 있는지 확인한 다음 페이지 수준의 가로 스크롤을 찾으세요. 고정 이미지, 넓은 입력 필드, 음수 마진, 오프캔버스 패널, 배너 등이 일반적 원인입니다. W3C의 WCAG 2.1 Reflow 기준은 320 CSS 픽셀에 해당하는 너비에서의 세로 스크롤 가능한 콘텐츠를 설명하며, 여기에는 400% 줌에서 1280픽셀 뷰포트도 포함됩니다. 해당 기준이 범위에 있다면 실제 확대 시나리오를 테스트하세요. 지도, 비디오, 데이터 표는 2차원 레이아웃이 필요할 수 있지만 그 스크롤은 구성요소 내부로만 제한하고 주변 페이지는 리플로우되게 하세요.
테스트한 모든 경계에서 헤더, 메인 콘텐츠, 푸터, 고정 바(sticky bar), 대화상자, 오류 요약을 점검하세요.
좁은 화면에 맞게 정보를 재구성하되 요구사항, 가격 세부사항, 도움 경로를 조용히 제거하지 마세요.
콘텐츠와 폼에 스트레스 주기
콘텐츠 작업은 CSS 릴리스 없이도 반응형 실패를 일으킬 수 있습니다. 승인된 가장 긴 제목, 여러 배지, 누락된 이미지, 선택된 필터, 큰 법적 고지, 브라우저 자동완성으로 채워진 필드를 테스트하세요. 열이 쌓일 때 읽기 순서와 키보드 순서가 여전히 합리적인지 확인하세요. 작은 기기에서 실제 폼을 완료해 보세요: 컨트롤을 열고, 오류를 정정하고, 제출하세요. 제3자 위젯은 컨테이너, 동의(consent) 상태, 폰트 및 스타일로 결과를 바꿀 수 있으므로 프로덕션 유사 페이지에서 테스트하세요.
가능한 최대 길이와 조합을 반영하되 QA 증거에 고객 데이터나 결제 정보를 포함하지 마세요.
공지, 채팅, 프로모션, 검증 메시지를 함께 열어보세요; 어느 것도 주요 동작이나 포커스된 필드를 가려서는 안 됩니다.
모든 입력 경로를 실행
큰 화면이 반드시 마우스를 보장하지는 않고, 작은 화면이 터치만을 보장하지는 않습니다. hover 미디어 기능은 주요 입력이 편리하게 hover 가능한지를 테스트하므로 hover는 보조적 향상이어야지 동작이나 설명에 대한 유일한 경로가 되어서는 안 됩니다. 데스크톱에서의 키보드와 포인터 사용, 터치 기기에서의 탭과 스크롤, 관련된 혼합 입력 기기를 테스트하세요. 콤팩트한 닫기 버튼, 스tepper, 칩, 달력, 아이콘 동작을 검토하세요. WCAG 2.2 Target Size (Minimum)는 24 x 24 CSS 픽셀의 목표 크기를 규정하며 간격 및 인라인 링크를 포함한 정의된 예외가 있습니다. 이는 범위와 예외가 있는 기준이지 모든 24픽셀 제어가 모두에게 동일하게 쉬운 약속은 아닙니다.
Tab 키로 페이지를 이동하세요. 포커스는 가시적이어야 하고 합리적 순서를 따르며 메뉴와 대화상자에 예측 가능하게 진입·종료해야 합니다.
필수적인 호버 노출은 포커스, 탭 또는 가시적 컨트롤로도 접근 가능하게 하고, 첫 번째 탭에서 혼란스러운 동작이 발생하지 않게 하세요.
제약 환경에서 자산과 성능 검증
이미지가 컨테이너에 맞더라도 기기에 잘못된 파일일 수 있습니다. 미디어가 컨테이너 안에 유지되는지, 필요한 경우 레이아웃 공간을 예약하는지, 유용한 크롭을 보존하는지, 적절한 후보(source)를 요청하는지 확인하세요. srcset과 sizes는 브라우저가 제공된 이미지 소스들 중에서 선택할 정보를 주지만 특정 요청을 보장하지는 않습니다. DevTools의 스로틀링은 문제를 조기에 찾아내는 데 유용하지만 CPU와 네트워크 제어는 개발 컴퓨터를 기준으로 한 시뮬레이션입니다. 핵심 여정은 실제 기기와 연결에서 재확인하세요. 폰트, 히어로 미디어, 캐러셀, 클라이언트 측 작업, 제3자 스크립트로 인한 지연, 이동(shift), 또는 탭 차단을 검사하세요.
경로, 뷰포트, 실제 또는 시뮬레이션 연결, 느려지거나 불안정해진 항목을 캡처하고 유사한 조건을 비교하세요.
안전한 경우 테스트 빌드에서 비필수 임베드를 지연시켜 핵심 작업이 여전히 사용 가능한지 확인하세요.
사전 예방적 가동 시간(uptime) 작업으로 수정
Status Is UP의 관점에서 반응형 준비성은 사전 예방적 가동 시간 최적화입니다: 사용자 차단 기기 경로를 식별하고 원인을 수정하며 수리 증명을 하고 재발을 방지하세요. 이는 모니터링 경보가 모든 레이아웃이나 상호작용 결함을 판단할 수 있다는 주장과는 다릅니다. 작업 영향도와 도달 범위에 따라 우선순위를 정하세요. 배포 전에는 인접 너비와 변경된 여정을 실제 하드웨어에서 테스트하세요. 공용 내비게이션, 스타일, 스크립트, 결제 또는 통합 변경에는 롤백 계획을 세우세요. 릴리스 후에는 검증 단계를 반복하고 증거를 변경 기록에 첨부하세요.
경로, 기기 또는 뷰포트, 방향, 입력, 상태, 기대 결과, 실제 결과 및 적절히 편집한 캡처를 명시하세요.
경로 단위의 우회보다 구성요소, 레이아웃 규칙, 토큰 또는 이미지 전달 수정을 선호하세요; 예외에는 소유자와 제거 계획을 부여하세요.