답변.

비기능 테스트는 시스템이 비즈니스 기능을 수행하는지 여부뿐만 아니라 사용성(usability), 성능, 보안, 적응성 및 접근성(accessibility)과 같은 매개변수에 대한 검사를 포함합니다.

문제의 역사: 테스트의 초기 발전 단계에서 "작동/미작동"에만 초점을 맞췄다면, 경쟁과 제품 품질에 대한 요구가 증가함에 따라 편의성, 작업 속도, 장애인을 위한 접근성와 같은 부가적인 매개변수에 대한 관심이 커졌습니다. 이는 비기능 테스트의 발전에 영향을 미쳤습니다.

문제: 테스터는 종종 비기능 매개변수를 수동으로 형식화하고 평가하는 방법을 모릅니다. 주관성이 발생합니다: 한 사용자가 편리하다고 생각하는 것이 다른 사용자에게는 불편할 수 있습니다. 명확한 체크리스트와 기준의 부재는 상황을 악화시킵니다.

해결책: 테스터는 다음을 수행해야 합니다:

접근성을 위한 WCAG 또는 사용성을 위한 ISO 9241과 같은 표준 및 권장 사항을 사용합니다.
텍스트와 배경 간의 대비를 확인하는 색상 분석기, 접근성을 확인하는 스크린 리더 시뮬레이터와 같은 특별한 도구를 적용합니다.
사용자 경험, 내비게이션, 요소의 가독성을 검토하기 위한 체크리스트를 개발합니다.
다양한 경험을 가진 실제 사용자들을 초청하여 사용자 테스트를 진행합니다.

주요 특징:

준비된 테스트 케이스뿐만 아니라 "실제 사용자 시나리오"로 작업합니다.
발견된 비기능 문제를 최대한 구체적으로 문서화해야 합니다.
분석을 위해 외부 도구를 사용하는 능력을 익혀야 합니다(예: Lighthouse, Axe, NVDA, JAWS, Color Contrast Analyzer).

의도된 질문.

자동화 테스트를 사용하더라도 사용성 테스트를 수동으로 수행할 필요가 있습니까?

아니요. 사용자 경험은 매우 주관적이며 많은 측면은 수동 분석이나 실제 사용자와의 상호작용을 통해서만 드러날 수 있습니다.

자동 스캐너만으로 접근성을 확인하는 것이 충분합니까?

아니요. 자동 검사로는 일반적으로 20–30%의 문제만 드러납니다. 나머지는 수동 상호작용을 통해서만 발견됩니다: 키보드 내비게이션 검사, 스크린 리더로 읽기 등입니다.

고객 중 장애인이 없더라도 접근성을 테스트해야 합니까?

네. 법률, 품질 표준 및 제품 개발 전망은 높은 접근성을 요구합니다. 게다가 일부 사용자는 일시적인 제한(예: 부상)을 가질 수 있습니다.

일반적인 오류 및 반패턴

비기능 요구사항에 대한 과소평가로 인한 무시.
표준에 대한 언급 없이 결과 문서화.
"불편하다" 또는 "편리하지 않다"와 같은 모호한 문구로 버그 설명.

실생활 사례

부정적인 사례

테스터가 버튼의 레이블과 낮은 대비를 간과했습니다: 색각 장애가 있는 사용자는 텍스트를 볼 수 없었습니다.

장점:

테스트 시간을 절약했습니다.

단점:

사용자 불만이 증가하고 지원 요청이 늘어났으며, 평판 손실이 발생했습니다.

긍정적인 사례

테스터가 무료 도구를 사용하여 대비를 확인하고 접근성 체크리스트를 작성했습니다.