수동 QA (품질 보증)사용자 인터페이스 테스터

수동 테스트 과정에서 비기능적 결함(예: 성능 문제, 사용자 인터페이스 편의성 또는 접근성 문제)을 식별하고 문서화하는 방법은 무엇입니까?

Hintsage AI 어시스턴트로 면접 통과

답변

질문의 배경:

비기능적 측면의 테스트는 심지어 논리적으로 완벽한 기능도 일부 사용자에게 불편하거나 느리거나 접근할 수 없다는 것이 명백해짐에 따라 시작되었습니다. 이러한 결함은 자동으로 감지하기 어려우므로 수동 테스트 담당자는 여기서 중요한 역할을 합니다.

문제:

테스트 담당자는 종종 기능성에만 집중하고 성능, 유용성 및 접근성을 무시합니다. 비기능적 결함은 공식화하고 설명하기가 어렵고, 그 주관성 때문에 명확한 평가를 받기 어렵습니다.

해결책:

테스트 중 비기능적 검사를 위해 시간 을 따로 할애하는 것이 중요합니다. 성능 테스트를 위해 반응 시간을 기록하고(예: 스톱워치 사용), 유용성 테스트를 위해 불편사항을 기술하고 예를 제시하며, 접근성을 위해 체크리스트나 도구를 사용하십시오(예: 스크린 리더 포함).

주요 특징:

  • 수용 기준을 명확히 수립해야 합니다.
  • 평가 결과는 종종 주관적이므로 보고서의 근거가 중요합니다.
  • 모든 유사 결함이 릴리스 전에 수용될 수 있는 것은 아니며 일부는 치명적입니다.

헛갈리게 하는 질문들.

모든 비기능적 결함은 테스터에 의해 버그 리포트로 기록되어야 합니까?

항상 그런 것은 아닙니다. 문제가 주관적일 경우, 팀과 논의하고 개선 요청(feature request)으로 기록하는 것으로 충분할 때도 있습니다.

테스터가 성능 메트릭을 설정해야 합니까?

요구 사항이나 사양서에 명시되지 않은 경우에만 해야 합니다. 그렇지 않으면 그에 의존해야 합니다.

비기능적 테스트를 위한 특별한 소프트웨어나 도구가 반드시 필요합니까?

아니요, 기본적인 검사는 수동으로 수행할 수 있습니다(예: 수동 측정 및 체크리스트를 통한 접근성 분석).

일반적인 오류 및 안티 패턴

  • 비기능적 기준 무시.
  • 측정 가능한 증거 없는 주관적인 보고서.
  • 너무 일반적이거나 모호한 버그 제목 및 설명.

실제 사례

부정적인 사례

테스터가 카탈로그 페이지 로딩 시간이 10초 이상 걸린다는 것을 발견했지만 “아마 모두 그렇겠지”라고 생각하여 버그를 제출하지 않았습니다.

장점:

  • 논란이 되는 티켓으로 팀을 피곤하게 하지 않았습니다.

단점:

  • 사용자 경험이 감소하고, 고객이 실망하여 문제를 경영진이 불만제로 알게 되었습니다.

긍정적인 사례

테스터가 카탈로그 페이지가 첫 진입 시 12초가 걸린다는 것을 자세히 기록하고, 스톱워치 스크린샷을 첨부하며 가능한 최적화 방법을 제안했습니다.

장점:

  • 팀은 문제에 대한 객관적인 설명을 얻어 신속하게 진단할 수 있었습니다.

단점:

  • 이러한 버그를 형식화하는 데 더 많은 시간이 소요됩니다.