------------------------------------------------------------
1. 사용성 테스팅(Massive and Rapid Usability Testing)
가. 사용성 테스팅의 정의
나. Rapid Usbility Testing
다. Massive Usability Testing vs. Rapid Usability Testing
2. 사용성 테스팅 계획(개발 수명주기에서의 사용성 테스팅)
가. 사용성 테스팅은 언제 수행하나요?
3. 참가자 선정
가. 사용성 테스팅에 얼마나 많은 참가자가 적당한가?
나. 사용성 테스팅에서 사용자란 누구인가?
4. 사용성 테스팅 수행
가. 사용자 테스팅
- 사용자 테스팅 소개
- 테스트 과제와 시나리오 작성
- 관찰실
- 테스트 진행
- 회고 그리고 보고서
- 체크리스트
- 사용자 테스팅의 장점과 단점
나. 카드 소팅
다. 소원의 나무
5. 정리(?)
------------------------------------------------------------
사용자 테스트를 진행하기 위해서 반드시 필요한 것이 테스트 과제와 시나리오입니다.
테스트 과제란 참가자들이 해보고 싶어하는 것을 말합니다. 즉, 사용자가 테스트 대상 제품을 통해 하고 싶어하는 일을 뜻합니다.
테스트 시나리오란 이러한 테스트 과제를 수행하기 위해 알아야 하는 상황을 담은 글을 말합니다.
예를 들어, 온라인 서점이 테스트 대상이라고 한다면
테스트 과제는
1. 책 검색하기
2. 장바구니에 책 담기
3. 구매하기
4. 취소하기
5. 배송 추적 하기
등이 될 것입니다.
테스트 시나리오는 위의 과제들을 수행하기 위해 알아야할 상황을 만들어 주는 것입니다.
예를 들면,
'당신은 중간고사 과제를 제출하기 위해 OOO 서적을 구매해야 합니다. OOO 서적을 구매 후 배송 추적을 해보시기 바랍니다.'
와 같이 작성해 주시면 됩니다.
이러한 테스트 과제와 시나리오는 작성하는 방법에 정답은 없습니다.
우선은 마음을 차분히 가라앉히신 후에 종이를 꺼내고 펜을 쥐시기 바랍니다.
그리고 당신이 테스트해야할 제품에서 가장 중요한 일을 5~10개 정도 적어보시기 바랍니다.
여기서 주의해야할 점은 당신이 또는 제품을 개발한 관련 이해관계자들이 원하는 일, 계획했던 일이 아닌 사용자들이 하고 있는 일을 골라내야한다는 것입니다.
이것은 간단한 일 같지만 생각처럼 쉽지 않습니다.
제품을 상세하게 생각하지 말고 좀 더 큰 범위로 생각하여 진행하시는 것이 좋습니다.
테스트 대상 제품의 상세 기능 목록을 참고하지 마시고 테스트 대상 제품을 큰 범위로 표현하고 그러한 제품을 사용자들이 사용하고자 할 때 무엇을 하고 싶을지를 생각해 보시기 바랍니다.
예를 들어, 여러분이 '미리내'라는 온라인 서점을 테스트 대상으로 하신다고 가정을 한다면 이 온라인 서점에는 기획자가 구상한 수많은 기능들이 있을 겁니다.
검색, 장바구니, 내 책장, 배송 추적, 구매하기, 반품하기 등등..
그러한 기능들을 생각하지 마시고 큰 범위인 온라인 서점이라고 표현하신 뒤, 온라인 서점을 사용자들이 이용한다면 가장 중요한 일이 무엇일지를 생각하시기를 바랍니다.
온라인 서점이라고 한다면
역시 검색, 구매 정도가 가장 중요한 일일 것입니다. 리뷰나 평점 등도 책을 선택하는 데 있어 중요할 수도 있습니다.
이렇게 과제 리스트를 작성하셨다면 주변의 동료들에게 '온라인 서점'을 사용한다면 어떤 걸 하고 싶은지 물어보시고 작성한 과제 리스트와 비교해 보시기 바랍니다.
많은 과제들이 중복되어 있을 것입니다. 그러한 과제들이 서로 중요하다고 동의하는 과제들입니다.
그렇게 과제 리스크가 결정되고 나면 그러한 과제들 중 어떤 과제를 실제로 테스트 할지를 결정해야 합니다.
테스트 시간은 한정되어 있기 때문에 모든 과제를 진행하기는 어렵습니다.
테스트 시간을 1시간으로 한다면 일반적으로 실제 과제가 수행되는 시간은 35분 전후가 됩니다.
과제 리스트의 각각의 과제들을 수행하는데 걸리는 시간을 감안하여 실제 수행할 과제를 선택하시기 바랍니다.
그리고 선정된 과제 이외의 과제들은 선정된 과제를 예상보다 일찍 끝내는 참가자들을 위해 예비로 가지고 계시면 됩니다.(버리시면 안됩니다.)
최종적으로 과제 리스트를 결정하실 때 아래와 같은 사항을 한번 더 확인해 보시기 바랍니다.
1. 정말로 중요한 과제인가?
온라인 서점이라면 책을 검색하고 결제하는 것이 가장 중요한 과제입니다. 사용자들이 해당 과제를 수행하지 않을 경우 제품 자체를 사용할 수 없는 가장 중요한 과제를 선정하시기 바랍니다.
2. 이전에도 사용자들이 불편을 호소했던 것인가?
이전에 사용성 테스팅을 진행하여 개선이 된 제품 또는 기존의 제품에서 업그레이드 또는 업데이트 된 제품의 경우에 이전부터 사용자들이 불편을 호소했던 부분들을 과제로 선택하시기 바랍니다.
고객 지원 부서나 웹 서비스의 경우 사용자들의 로그는 그러한 부분들을 찾는 데 유용한 데이터입니다.
3. 사용자들이 불편을 겪을 것이라고 의심되는 부분인가?
완전히 새로운 제품을 처음 사용성 테스팅을 진행하는 것이라면 사용자들이 문제를 겪을 수 있을 것이라고 의심되는 것을 포함시킬 수 있습니다.
하지만 이러한 과제는 선정에 있어서 조심할 필요가 있습니다. 과제 선정 시 특정 이해관계자의 의견을 대변하는 과제 등을 선정하지 않도록 하셔야 합니다.
마지막으로 위의 주의 사항보다 더 중요한 사항이 있습니다.
바로 테스트를 진행하는 진행자의 관점이 가미되어서는 안된다는 것입니다. 어떤 특정한 목적을 가지고 과제와 시나리오가 작성되어서는 안됩니다.
진행자는 어떤 목적으로 특정 사용성 문제가 부각될 수 있도록 테스트를 진행하고 그렇게 하기 위해 과제를 만들어 낼 수 있습니다.
예를 들어 '다음 만화속 세상'의 웹에서 볼 수 있는 웹툰과 모바일 페이지에서 볼 수 있는 웹툰은 동일하지 않습니다.
특정 웹툰은 모바일 페이지에서 볼 수 없습니다.
그런데 만약 과제가 그러한 특정 웹툰을 검색하거나 보는 것으로 작성된다면 어떻게 될까요?
사용자는 테스트 중간에 큰 혼란에 빠질 것이고 꽤 많은 시간동안 서비스되지 않는 웹툰을 찾기 위해 악전고투를 벌이게 될 것입니다. 그리고 이것은 관찰자들에게 아주 선명하게 각인될 것입니다.
그렇다면 이런 과제를 만들어도 되는 것일까요? 만들면 안되는 것일까요?
그것은 과제의 목표가 무엇이냐에 따라 다를 수 있습니다.
사용자가 웹에서 보던 웹툰을 이동 중에서 모바일 단말기에서 보기를 원하는 것이 진정으로 원하는 기능이라면 이런 과제를 선정할 수도 있습니다.
하지만 이런 기능이 사용자에게는 매우 사소하지만 진행자가 특정 목적을 위해 이런 과제를 선정한다면 그것은 문제가 있는 것이고 이런 과제를 선정해서는 안되는 것입니다.
만약 후자라면 테스트 결과와 진행 자체의 신뢰성에 엄청난 타격을 입게 되고 회사와 조직은 추후 사용성 테스팅을 추진해야할 동기를 잃어버리게 되고 결국 많은 것을 잃게 될 것입니다.
비슷한 경우로 과제 선정시에는 테스트 환경에 대해서도 고민할 필요가 있습니다.
예를 들어 온라인 뱅킹에 대한 사용성 테스트를 진행할 때 파이어폭스에서 진행해야할까요? 인터넷 익스플로러에서 진행해야할까요?
국내 대다수의 금융 기관은 인터넷 익스플로러만을 지원하므로 인터넷 익스플로러에서 진행해야하는 것일까요?
만약 사용자가 파이어폭스만을 이용하는 사용자라면 어떨까요?
이 경우에도 사용자들이 파이어폭스를 많이 이용한다면 진행할 수도 있습니다. 하지만 웹 접근성을 부각시키기 위해 진행자가 의도적으로 사용성 테스트를 파이어폭스로 진행한다면 어떻게 될까요?
어떤 웹서비스들은 반드시 인터넷 익스플로러에서만 동작하지 않는 경우도 있습니다. 특정 게시판이 특정 브라우저에서만 기능하지 않는 결함이 있다고 했을 때 그 결함을 강조하기 위해서 진행자가 일부러 특정 브라우저에서 사용성 테스트를 수행한다면 어떻게 될까요?
즉, 사용성 테스트 과제는 얼마든지 진행자의 의도에 따라 변형될 수 있으며, 그러한 경우에 외부에서 그러한 점을 인식하고 문제를 제기하는 것은 쉽지 않다는 것입니다.
테스트 과제는 전적으로 사용자의 관점에서 선정되어야 하고 객관적이어야 합니다.
사람이 하는 일이기 때문에 100% 객관적일수는 없겠지만 그래서 테스트 과제는 매우 조심해서 선정되어야 합니다.
이렇게 최종 과제 리스트를 작성하셨다면 이제 시나리오를 작성하셔야 합니다.
시나리오에는 참가자가 맡게 될 배역과 동기, 해야 할 일 그리고 약간의 설명을 담으시면 됩니다.
시나리오는 거창하게 쓸 필요 없이 과제를 해야하는 상황(~ 하십시오.)과 필요한 정보(아이디, 비밀번호, 카드 번호 등등)만 담고 있으면 됩니다.
한가지 주의할 점은 시나리오에 제품의 기능을 지칭하는 단어나 그러한 기능을 유추할 수 있는 단어는 배제해야 합니다. 되도록 일반적인 단어를 사용하시기 바랍니다.
예를 들어
'책을 장바구니에 넣고 결제 버튼을 선택하십시오.'
는 잘못된 시나리오입니다.
'책을 구매해 보시기 바랍니다.'
가 적합한 시나리오입니다.
그리고 약어나 특정 도메인에서 사용되는 전문 용어 역시 사용하지 마시기 바랍니다.
테스트 시나리오는 명료하고, 애매모호하지 않고, 이해 가능한 문장으로 구성되어야 합니다.
마지막으로 테스트 시나리오를 사용자가 수행할 때 주의해야할 사항으로는
검색 기능에 대한 사용성을 테스트 하는 것이 아니라면 사용자가 검색 기능을 사용하지 못하도록 하는 것이 좋습니다.
여기서 검색이란 도움말 등을 참고하지 못하도록 하는 것이 좋다는 의미입니다. 어떤 기능을 사용하기 위해서 특정 단어의 의미를 검색하거나 기능에 대한 도움말을 검색하지 못하도록 하시기 바랍니다.
그리고 다른 제품이나 서비스 또는 다른 사이트로 이동하지 않도록 주의를 기울이셔야 합니다.
이렇게 테스트 과제와 시나리오 정해진 후에는 정해진 시나리오에 대하여 파일럿 테스트를 수행하시기 바랍니다.
파일럿 테스트는 스스로도 할 수 있으며, 주변의 누군가에게 도움을 요청할 수도 있습니다. 친구나 가족도 좋습니다.
파일럿 테스트는 작성된 시나리오를 다른 사람들이 정확하게 이해하고 해당 작업을 수행하는지 확인하는 목적으로 진행합니다.
즉, 시나리오가 분명하고, 완전하고 모호하지 않는지 확인하는 것입니다.
때문에 실제 테스트처럼 긴 시간을 들일 필요 없이 짧은 시간동안 빠르게 수행하시면 됩니다.
이러한 파일럿 테스트는 실제 테스팅이 수행되기 2~3일 전에 수행하시면 됩니다. 그리고 테스팅을 진행할 제품도 이 시간에 맞춰서 준비가 끝나야 합니다.
테스트 과제와 테스트 시나리오의 작성을 다시 한번 더 정리하면
1. 테스트 대상에서 가장 중요한 일을 5~10개를 적는다.
2. 동료 검토를 한다.
3. 테스트 시간을 고려하여 과제를 선정한다.
4. 사용자가 테스트를 일찍 끝냈을 때를 대비하여 예비 과제를 준비한다.
5. 각각의 과제에 대하여 시나리오를 작성한다.
6. 시나리오 파일럿 테스트를 수행한다.
7. 파일럿 테스트에서 나온 문제를 수정하여 최종 시나리오를 확정한다.
로 정리할 수 있습니다.
이렇게 확정된 시나리오는 큼지막한 카드(A4 절반 크기 정도)에 잘 보일 수 있도록 인쇄를 해서 준비하시면 됩니다.
인쇄를 하실 때에는 시나리오 번호 등은 인쇄 하지 않으셔도 됩니다.
테스트 시나리오는 각각이 독립되도록 구성되어야 하므로 번호는 의미가 없습니다. 실제 테스트를 수행하는 현장에서는 참가자의 반응에 따라 완전히 새로운 테스트 과제와 시나리오를 즉흥에서 만들어야 할 수도 있습니다.
테스트 현장은 통제가 되지 않기 때문에 진행자는 모든 시나리오를 알고 있어야 하며, 사용자의 반응에 따라 적절한 과제와 시나리오를 제시할 수 있도록 준비하셔야 합니다.
필요하다면 전체 시나리오가 적힌 종이를 준비하시는 것도 좋습니다.
이제 테스트 과제와 시나리오가 준비되었습니다.
다음으로는 관찰실의 구성과 준비에 대해서 다루도록 하겠습니다.
1. 사용성 테스팅(Massive and Rapid Usability Testing)
가. 사용성 테스팅의 정의
나. Rapid Usbility Testing
다. Massive Usability Testing vs. Rapid Usability Testing
2. 사용성 테스팅 계획(개발 수명주기에서의 사용성 테스팅)
가. 사용성 테스팅은 언제 수행하나요?
3. 참가자 선정
가. 사용성 테스팅에 얼마나 많은 참가자가 적당한가?
나. 사용성 테스팅에서 사용자란 누구인가?
4. 사용성 테스팅 수행
가. 사용자 테스팅
- 사용자 테스팅 소개
- 테스트 과제와 시나리오 작성
- 관찰실
- 테스트 진행
- 회고 그리고 보고서
- 체크리스트
- 사용자 테스팅의 장점과 단점
나. 카드 소팅
다. 소원의 나무
5. 정리(?)
------------------------------------------------------------
사용자 테스트를 진행하기 위해서 반드시 필요한 것이 테스트 과제와 시나리오입니다.
테스트 과제란 참가자들이 해보고 싶어하는 것을 말합니다. 즉, 사용자가 테스트 대상 제품을 통해 하고 싶어하는 일을 뜻합니다.
테스트 시나리오란 이러한 테스트 과제를 수행하기 위해 알아야 하는 상황을 담은 글을 말합니다.
예를 들어, 온라인 서점이 테스트 대상이라고 한다면
테스트 과제는
1. 책 검색하기
2. 장바구니에 책 담기
3. 구매하기
4. 취소하기
5. 배송 추적 하기
등이 될 것입니다.
테스트 시나리오는 위의 과제들을 수행하기 위해 알아야할 상황을 만들어 주는 것입니다.
예를 들면,
'당신은 중간고사 과제를 제출하기 위해 OOO 서적을 구매해야 합니다. OOO 서적을 구매 후 배송 추적을 해보시기 바랍니다.'
와 같이 작성해 주시면 됩니다.
이러한 테스트 과제와 시나리오는 작성하는 방법에 정답은 없습니다.
우선은 마음을 차분히 가라앉히신 후에 종이를 꺼내고 펜을 쥐시기 바랍니다.
그리고 당신이 테스트해야할 제품에서 가장 중요한 일을 5~10개 정도 적어보시기 바랍니다.
여기서 주의해야할 점은 당신이 또는 제품을 개발한 관련 이해관계자들이 원하는 일, 계획했던 일이 아닌 사용자들이 하고 있는 일을 골라내야한다는 것입니다.
이것은 간단한 일 같지만 생각처럼 쉽지 않습니다.
제품을 상세하게 생각하지 말고 좀 더 큰 범위로 생각하여 진행하시는 것이 좋습니다.
테스트 대상 제품의 상세 기능 목록을 참고하지 마시고 테스트 대상 제품을 큰 범위로 표현하고 그러한 제품을 사용자들이 사용하고자 할 때 무엇을 하고 싶을지를 생각해 보시기 바랍니다.
예를 들어, 여러분이 '미리내'라는 온라인 서점을 테스트 대상으로 하신다고 가정을 한다면 이 온라인 서점에는 기획자가 구상한 수많은 기능들이 있을 겁니다.
검색, 장바구니, 내 책장, 배송 추적, 구매하기, 반품하기 등등..
그러한 기능들을 생각하지 마시고 큰 범위인 온라인 서점이라고 표현하신 뒤, 온라인 서점을 사용자들이 이용한다면 가장 중요한 일이 무엇일지를 생각하시기를 바랍니다.
온라인 서점이라고 한다면
역시 검색, 구매 정도가 가장 중요한 일일 것입니다. 리뷰나 평점 등도 책을 선택하는 데 있어 중요할 수도 있습니다.
이렇게 과제 리스트를 작성하셨다면 주변의 동료들에게 '온라인 서점'을 사용한다면 어떤 걸 하고 싶은지 물어보시고 작성한 과제 리스트와 비교해 보시기 바랍니다.
많은 과제들이 중복되어 있을 것입니다. 그러한 과제들이 서로 중요하다고 동의하는 과제들입니다.
그렇게 과제 리스크가 결정되고 나면 그러한 과제들 중 어떤 과제를 실제로 테스트 할지를 결정해야 합니다.
테스트 시간은 한정되어 있기 때문에 모든 과제를 진행하기는 어렵습니다.
테스트 시간을 1시간으로 한다면 일반적으로 실제 과제가 수행되는 시간은 35분 전후가 됩니다.
과제 리스트의 각각의 과제들을 수행하는데 걸리는 시간을 감안하여 실제 수행할 과제를 선택하시기 바랍니다.
그리고 선정된 과제 이외의 과제들은 선정된 과제를 예상보다 일찍 끝내는 참가자들을 위해 예비로 가지고 계시면 됩니다.(버리시면 안됩니다.)
최종적으로 과제 리스트를 결정하실 때 아래와 같은 사항을 한번 더 확인해 보시기 바랍니다.
1. 정말로 중요한 과제인가?
온라인 서점이라면 책을 검색하고 결제하는 것이 가장 중요한 과제입니다. 사용자들이 해당 과제를 수행하지 않을 경우 제품 자체를 사용할 수 없는 가장 중요한 과제를 선정하시기 바랍니다.
2. 이전에도 사용자들이 불편을 호소했던 것인가?
이전에 사용성 테스팅을 진행하여 개선이 된 제품 또는 기존의 제품에서 업그레이드 또는 업데이트 된 제품의 경우에 이전부터 사용자들이 불편을 호소했던 부분들을 과제로 선택하시기 바랍니다.
고객 지원 부서나 웹 서비스의 경우 사용자들의 로그는 그러한 부분들을 찾는 데 유용한 데이터입니다.
3. 사용자들이 불편을 겪을 것이라고 의심되는 부분인가?
완전히 새로운 제품을 처음 사용성 테스팅을 진행하는 것이라면 사용자들이 문제를 겪을 수 있을 것이라고 의심되는 것을 포함시킬 수 있습니다.
하지만 이러한 과제는 선정에 있어서 조심할 필요가 있습니다. 과제 선정 시 특정 이해관계자의 의견을 대변하는 과제 등을 선정하지 않도록 하셔야 합니다.
마지막으로 위의 주의 사항보다 더 중요한 사항이 있습니다.
바로 테스트를 진행하는 진행자의 관점이 가미되어서는 안된다는 것입니다. 어떤 특정한 목적을 가지고 과제와 시나리오가 작성되어서는 안됩니다.
진행자는 어떤 목적으로 특정 사용성 문제가 부각될 수 있도록 테스트를 진행하고 그렇게 하기 위해 과제를 만들어 낼 수 있습니다.
예를 들어 '다음 만화속 세상'의 웹에서 볼 수 있는 웹툰과 모바일 페이지에서 볼 수 있는 웹툰은 동일하지 않습니다.
특정 웹툰은 모바일 페이지에서 볼 수 없습니다.
그런데 만약 과제가 그러한 특정 웹툰을 검색하거나 보는 것으로 작성된다면 어떻게 될까요?
사용자는 테스트 중간에 큰 혼란에 빠질 것이고 꽤 많은 시간동안 서비스되지 않는 웹툰을 찾기 위해 악전고투를 벌이게 될 것입니다. 그리고 이것은 관찰자들에게 아주 선명하게 각인될 것입니다.
그렇다면 이런 과제를 만들어도 되는 것일까요? 만들면 안되는 것일까요?
그것은 과제의 목표가 무엇이냐에 따라 다를 수 있습니다.
사용자가 웹에서 보던 웹툰을 이동 중에서 모바일 단말기에서 보기를 원하는 것이 진정으로 원하는 기능이라면 이런 과제를 선정할 수도 있습니다.
하지만 이런 기능이 사용자에게는 매우 사소하지만 진행자가 특정 목적을 위해 이런 과제를 선정한다면 그것은 문제가 있는 것이고 이런 과제를 선정해서는 안되는 것입니다.
만약 후자라면 테스트 결과와 진행 자체의 신뢰성에 엄청난 타격을 입게 되고 회사와 조직은 추후 사용성 테스팅을 추진해야할 동기를 잃어버리게 되고 결국 많은 것을 잃게 될 것입니다.
비슷한 경우로 과제 선정시에는 테스트 환경에 대해서도 고민할 필요가 있습니다.
예를 들어 온라인 뱅킹에 대한 사용성 테스트를 진행할 때 파이어폭스에서 진행해야할까요? 인터넷 익스플로러에서 진행해야할까요?
국내 대다수의 금융 기관은 인터넷 익스플로러만을 지원하므로 인터넷 익스플로러에서 진행해야하는 것일까요?
만약 사용자가 파이어폭스만을 이용하는 사용자라면 어떨까요?
이 경우에도 사용자들이 파이어폭스를 많이 이용한다면 진행할 수도 있습니다. 하지만 웹 접근성을 부각시키기 위해 진행자가 의도적으로 사용성 테스트를 파이어폭스로 진행한다면 어떻게 될까요?
어떤 웹서비스들은 반드시 인터넷 익스플로러에서만 동작하지 않는 경우도 있습니다. 특정 게시판이 특정 브라우저에서만 기능하지 않는 결함이 있다고 했을 때 그 결함을 강조하기 위해서 진행자가 일부러 특정 브라우저에서 사용성 테스트를 수행한다면 어떻게 될까요?
즉, 사용성 테스트 과제는 얼마든지 진행자의 의도에 따라 변형될 수 있으며, 그러한 경우에 외부에서 그러한 점을 인식하고 문제를 제기하는 것은 쉽지 않다는 것입니다.
테스트 과제는 전적으로 사용자의 관점에서 선정되어야 하고 객관적이어야 합니다.
사람이 하는 일이기 때문에 100% 객관적일수는 없겠지만 그래서 테스트 과제는 매우 조심해서 선정되어야 합니다.
이렇게 최종 과제 리스트를 작성하셨다면 이제 시나리오를 작성하셔야 합니다.
시나리오에는 참가자가 맡게 될 배역과 동기, 해야 할 일 그리고 약간의 설명을 담으시면 됩니다.
시나리오는 거창하게 쓸 필요 없이 과제를 해야하는 상황(~ 하십시오.)과 필요한 정보(아이디, 비밀번호, 카드 번호 등등)만 담고 있으면 됩니다.
한가지 주의할 점은 시나리오에 제품의 기능을 지칭하는 단어나 그러한 기능을 유추할 수 있는 단어는 배제해야 합니다. 되도록 일반적인 단어를 사용하시기 바랍니다.
예를 들어
'책을 장바구니에 넣고 결제 버튼을 선택하십시오.'
는 잘못된 시나리오입니다.
'책을 구매해 보시기 바랍니다.'
가 적합한 시나리오입니다.
그리고 약어나 특정 도메인에서 사용되는 전문 용어 역시 사용하지 마시기 바랍니다.
테스트 시나리오는 명료하고, 애매모호하지 않고, 이해 가능한 문장으로 구성되어야 합니다.
마지막으로 테스트 시나리오를 사용자가 수행할 때 주의해야할 사항으로는
검색 기능에 대한 사용성을 테스트 하는 것이 아니라면 사용자가 검색 기능을 사용하지 못하도록 하는 것이 좋습니다.
여기서 검색이란 도움말 등을 참고하지 못하도록 하는 것이 좋다는 의미입니다. 어떤 기능을 사용하기 위해서 특정 단어의 의미를 검색하거나 기능에 대한 도움말을 검색하지 못하도록 하시기 바랍니다.
그리고 다른 제품이나 서비스 또는 다른 사이트로 이동하지 않도록 주의를 기울이셔야 합니다.
이렇게 테스트 과제와 시나리오 정해진 후에는 정해진 시나리오에 대하여 파일럿 테스트를 수행하시기 바랍니다.
파일럿 테스트는 스스로도 할 수 있으며, 주변의 누군가에게 도움을 요청할 수도 있습니다. 친구나 가족도 좋습니다.
파일럿 테스트는 작성된 시나리오를 다른 사람들이 정확하게 이해하고 해당 작업을 수행하는지 확인하는 목적으로 진행합니다.
즉, 시나리오가 분명하고, 완전하고 모호하지 않는지 확인하는 것입니다.
때문에 실제 테스트처럼 긴 시간을 들일 필요 없이 짧은 시간동안 빠르게 수행하시면 됩니다.
이러한 파일럿 테스트는 실제 테스팅이 수행되기 2~3일 전에 수행하시면 됩니다. 그리고 테스팅을 진행할 제품도 이 시간에 맞춰서 준비가 끝나야 합니다.
테스트 과제와 테스트 시나리오의 작성을 다시 한번 더 정리하면
1. 테스트 대상에서 가장 중요한 일을 5~10개를 적는다.
2. 동료 검토를 한다.
3. 테스트 시간을 고려하여 과제를 선정한다.
4. 사용자가 테스트를 일찍 끝냈을 때를 대비하여 예비 과제를 준비한다.
5. 각각의 과제에 대하여 시나리오를 작성한다.
6. 시나리오 파일럿 테스트를 수행한다.
7. 파일럿 테스트에서 나온 문제를 수정하여 최종 시나리오를 확정한다.
로 정리할 수 있습니다.
이렇게 확정된 시나리오는 큼지막한 카드(A4 절반 크기 정도)에 잘 보일 수 있도록 인쇄를 해서 준비하시면 됩니다.
인쇄를 하실 때에는 시나리오 번호 등은 인쇄 하지 않으셔도 됩니다.
테스트 시나리오는 각각이 독립되도록 구성되어야 하므로 번호는 의미가 없습니다. 실제 테스트를 수행하는 현장에서는 참가자의 반응에 따라 완전히 새로운 테스트 과제와 시나리오를 즉흥에서 만들어야 할 수도 있습니다.
테스트 현장은 통제가 되지 않기 때문에 진행자는 모든 시나리오를 알고 있어야 하며, 사용자의 반응에 따라 적절한 과제와 시나리오를 제시할 수 있도록 준비하셔야 합니다.
필요하다면 전체 시나리오가 적힌 종이를 준비하시는 것도 좋습니다.
이제 테스트 과제와 시나리오가 준비되었습니다.
다음으로는 관찰실의 구성과 준비에 대해서 다루도록 하겠습니다.
댓글
댓글 쓰기