[기획] 9.사용성 테스트 1/3

목차

1. 사용성 테스트 개요 2. 사용성 테스트 프로세스    01. 사용성 테스트 과정    02. 유용성을 위한 웹 인터페이스 3. 사용성 테스트 계획서 작성    01. 사용성 테스트 계획서 항목

 

1. 사용성 테스트 개요

사용성 테스트는 유저가 사이트를 사용하는 패턴을 직접 관찰하면서, 더 나은 사이트를 만들기 위한 단 서를 찾아내는 과정이다.
사용성 테스트는 일반적으로 프로젝트의 초반에 하는 것이 훨씬 효과적이다. 문제점을 발견했을 때 쉽 계 개선할 수 있기 때문이다. 또한 프로젝트의 진행 단계와 함께 반복적으로 이루어져야 하는 작업이기 도 하다. 그러나 굳이 한꺼번에 많은 사람을 투입할 필요는 없다.

최고의 유저빌리티(usalbilitsy) 전문가로 꼽히는 제이콥 닐슨(jakoh Nielsen) 박사의 실험 결과 그래 프인 (그림 9-1을 보자. 이미 세 사람만 테스트를 해도 사이트에서 발견할 수 있는 전체 문제점의 70% 가량을 찾아낼 수 있다. 흥미로운 것은 한 명만 테스트를 해도, 전체의 25%에 달하는 문제점을 찾아 낼 수 있다는 점이다. 방법론에 얽매여 테스트를 포기하기보다 단 한 명을 테스트한다 하더라도 일단 시도해 보면서 올바른 방향을 찾아가는 것이 더 나은 사이트를 만드는 지름길이다.
따라서 사용성 테스트를 완료하고 그 결과를 새로운 사이트 기획에 반영하여 좀더 사용자 중심적인 사 이트를 만들 수 있어야 한다.

사용성 테스트를 시작하고자 한다면 다음과 같은 사항을 숙지한 후 시작하자.

① 사용성 테스트는 되도록 일찍하는 것이 문제점을 찾아내고 수정하기 편하다.
② 모든 사람이 개발 일정을 조정할 필요가 없다.
③ 가능한 소규모로 테스트하라. 소규모로 간단하게 해야만 자주 할 수 있다. 자주 테스트하면서 조금씩 사이트를 업그레이드할 수 있는 방향을 찾는다.
④ 웹 제작 실무자들이 모두 함께 본다. 사용자들을 직접 눈으로 관찰하다 보면 각자의 분야에 응용할 수 있는 동기를 가져올 수 있다.
⑤ 개발팀의 논쟁 시간과 실수를 방지하여 재개발에 들이는 시간만큼만 할애하는 것을 목표로 하라.
⑥ 사용성 테스트 후 발생된 여러 결과 중 중요한 문제점, 몇 가지에 집중하는 것이 좋다.
⑦ 발견한 문제점은 즉시 고친다.
⑧ 결론이 나지 않는 경우, 의사결정의 수단으로도 사용해도 좋다.

 

2. 사용성 테스트 프로세스

쓸모없는 사이트를 만들어 거액의 비용을 날리는 것보다 사용성 테스트를 진행해서 사용자가 진정으로 원하는 사이트를 만드는 것이 더 효율적이다. 하지만 실제 테스트를 진행하려고 하면, 막상 어떻게 해 야 하는 것인지 막막해지기도 한다. 한편, 결과 분석을 위해 여러 가지 통계 지식 등도 필요하며, 테스 트용 실험실이 필요하다는 내용이 등장해 시작할 엄두를 내지 못하기도 한다.

그러나 한번 시도해보면 더 많은 것을 얻을 수 있고, 생각했던 것보다 어렵지 않다는 것도 알게 될 것이다.

01. 사용성 테스트 과정

사용성 테스트의 진행 과정은 다음과 같이 7단계를 거친다.
•1단계: 테스트 정의
•2단계: 태스크(task) 정의
• 3단계: 방법론 정의
• 4단계: 테스트 프로세스 정의
• 5단계: 테스트
•6단계: 결과 요약
• 7단계: 개선안 반영

태스크(ask): 웹 사이트에서 유저가 완수해야 하는 '일'이다. 예를 들어, 회원 가입, 구매, 티켓 예약, 뉴스레터 신청, 검색 등 유저가 완수해야 하는 과업을 말한다.

 

1단계	2단계	3단계	4단계	5단계	6단계	7단계
테스트 정의	태스크 정의	방법론 정의	테스트프로세스정의	테스트	결과 요약	개선안반영

[사용성 테스트 프로세스]

 

우선 사용성 테스트에 대한 개념을 도입하고, 그 필요성에 대해 제작팀 내의 공감대가 형성되는 것이 중요하다. 그리고 어떠한 부분에 대해서 테스트를 진행할지 테스트 목적을 분명히 정의한다.
테스트의 목적이 정의되면 테스트할 때 진행해 볼 만한 태스크(ask)들을 정리해본다. 사용성 테스트를 통해 얻고자 하는 내용이 무엇인지 생각해보고, 태스크를 통해서 얻을 수 있어야 한다.
다음은 테스트를 준비하는 단계다. 먼저, 스케줄을 잡고 테스트할 사람들을 모은다. 평균적으로 5명~6 명 정도의 테스터를 모집하게 되는데, 테스터들에게는 신선한 테스트 결과를 위해 내용에 대해서 철저 히 비밀에 부치기로 하는 것이 좋다.

테스트 진행에는 다음과 같은 문제가 있다.

① 방해받지 않는 공간에서 테스트를 진행해야 한다.
② 테스트하는 사람뿐만 아니라 다른 제작 구성원들이 이 진행 과정을 쉽게 볼 수 있어야 한다.
8 컴퓨터 1세트, 마이크, 비디오, 녹화용 테이프, 컨버터, TV 모니터 등과 같은 장비와 설치가 필요하다.

 

위 문제점이 해결되면 테스트 진행을 실행하면 된다. 한 사람당 1시간~2시간 사이에서 진행하는 것이 좋다. 2시간 이상을 넘어가게 되면 테스트하는 사람도 피곤함을 느끼게 된다.
사용성 테스트를 수행할 때 주의할 점은 다음과 같다.
① 중립적인 태도를 취한다.
② 테스트 담당자의 개인적인 의견이나 감정을 유저에게 표현하거나 강요하지 않는다.
③ 테스터가 제대로 임무를 수행하지 못하더라도 인내심을 가지고 지켜본다.
테스트가 끝나면 모든 참가자들의 테스트 결과를 정리해야 한다. 태스크 수행결과 및 관찰결과 요약, 참가자 면담 등의 내용을 취합해 리포트를 작성한다. 결과를 정리할 때 정말 중요한 부분들은 너무나 명백하게 드러나서 굳이 분석조차 필요없는 경우도 많다.

 

전문가에 의해 이론과 경험을 근거로 하여 일련의 규칙들을 만들어 놓고 평가 대상 사이트가 그러한 규칙들을 얼마나 잘 지키고 있는가를 확인하는 평가 방법을 '휴리스틱 분석(Heuristic Analysis)'이라고 한다. 닐슨 (Nielsen, 1993년)이 컴퓨터 소프트웨어 개발자들을 위해 제시한 다음의 10가지 원칙이 아마도 그 좋은 예가 될 수 있을 것이다. ① 단순하고 자연스러운 대화를 기본으로 하라. ② 사용자의 언어로 이야기하라. ③ 사용자의 메모리 로드(Memoy Loao)를 최소화하라. ④ 일관성(consistency)을 유지하라. ⑤ 피드백(feedback)을 제공하라. ⑥ 출구(exi)를 분명하게 표시하라. ⑦ 지름길(shortcu)을 추가적으로 제공하라. ⑧ 에러를 방지하라. ⑨ 에러 발생 시 유용한 에러 메시지를 제공하라. ⑩ 도움말 및 설명서를 제공하라. 닐슨의 휴리스틱이 좀더 원론적이고 일반적인 컴퓨터 소프트웨어 개발 과정을 위한 것인데 반해, 아래 제시된 패 로우(Pearow, 2000년)의 휴리스틱 10개 항목은 특별히 웹 사이트 평가를 염두에 두고 만들어진 것이다. 상당 부분에 있어서 닐슨의 휴리스틱과 일치됨을 알 수 있다. ① 시스템 상태를 가시화하라(visibility of system status). ② 현실의 자연스러운 상황에 가깝도록 만들어라(match the system to the real world). ③ 사용자의 통제권과 자유를 보장하라(user control and freedom). ④ 인터페이스의 일관성을 제고하고 표준화를 이루라(consistency and standards). ⑤ 오류를 방지하라(error protection). ⑥ 회상보다는 인식에 의존하는 구성을 하라(recognition rather than recal). ⑦ 사용의 유연성과 효율성을 제고하라(lexibilty and eficiency of use). ⑧ 최소한의 디자인을 사용해 미학적으로 구성하라(aesthelic and minimalist design. ⑨ 사용자가 오류를 인식하고, 진단하며, 벗어날 수 있도록 도움을 주라help users (ecopnze, diagnose, and recover from errors). ⑩ 도움말 및 설명서를 제공하라(help and documentation.