[소프트웨어 테스팅] 7. 사용성(사용자) 테스팅(Usability(User) Testing)

2022.06.08 - [컴퓨터 공학/0 +소프트웨어 테스팅] - [소프트웨어 테스팅] 6. 고수준 테스팅

[소프트웨어 테스팅] 6. 고수준 테스팅

 

지난 포스팅에서 고수준 테스팅을 다루면서

시스템 테스트에서 사용자 테스팅은 다음 포스팅에서 다룬다고 하였다.

그 내용을 다루어 보도록 하자.!

 

---

 

 

사용성(사용자) 테스팅(Usability(User) Testing)

시스템 테스트의 중요한 범주는 인간 요인 또는 사용성에 대한 문제를 찾으려는 시도이다.

현 시대에 프로그램에서 UX/UI의 역할은 상당히 큰 역할을 하고 있다.

 

 

사용성 테스트의 기초(Usabilty Testing Basics)

최근 소프트웨어 시스템은 일반적으로 광범위한 인간 요인에 대한 연구를 진행 했고, 이전에 진행했던 수많은 프로그램과 시스템들로 부터 혜택을 누리고 있다.

하지만, 인간요인에 대한 분석은 여전히 매우 주관적인 문제 이다.

 

사용성 테스팅 고려사항을 도출하기 위한 질문사항은 다음과 같다.

1. 각 사용자 인터페이스는 지능, 교육환경, 최종 사용자의 환경에 맞게 되어있는가?

2. 프로그램에서 출력하는 것은 의미 있으며, 사용자를 모욕하지 않고, 횡설수설 하지 않는가?

3. 오류 메시지와 같은 오류 진단을 이해하기 위해 컴퓨터 박사 학위와 같은 전문 지식이 필요한가?

예를 들어 EK022A OPEN ERROR ON FILE 'SYSIN' ABEND CODE=102
자신이 설계하는 프로그램을 통제하고 있다면 위와 같은 메시지를 사용자에게 사용해서는 안된다.
TO BE: 알 수 없는 오류가 발생했습니다. 

4. 사용자 인터페이스의 총 집합은 개념적 무결성, 기본 일관성, 문법의 균일, 관례, 의미론, 형식, 스타일, 약어를 나타내는가?

5. 온라인 뱅킹 시스템과 같이 정확도를 요구하는 곳에 충분한 중복 입력 표현은 가능한가?

예를 들어 계좌번호, 고객 이름, 적절한 사람이 계좌 정보에 접근하고 있는지 확인 하기 위해 PIN번호를 요청해야한다.

6. 시스템이 과도한 옵션의 수 또는 사용하지 않을 옵션을 포함하는가?

현대 소프트웨어의 트랜드는 사용자가 사용할 가능성이 높은 것들만 메뉴 선택을 제시하는 것이다.

7. 시스템은 모든 입력에 즉시 응답하는가?

소프트웨어가 원격 시스템에 접근 할때 빈번하게 발생하는 경우인데, 소프트웨어 구성 요소가 합리적인 선택과 사용자의 피드백으로 테스트 되기 때문에 컴포넌트 테스트라고도 한다.

8. 프로그램은 쉽게 사용할 수 있는가?

예를 들어 사용자에게 알리지 않은 상태에서 휴대번호를 구분하는지(01011112222 = 010-1111-2222)

9. 디자인은 사용자의 정확도에 도움이 되고 있는가?

사용자가 입력 또는 옵션을 선택 중에 얼마나 많은 오류를 일으키는지 분석해야 한다.

10. 사용자의 동작이 다음 세션에서도 쉽게 반복 되는가?

소프트웨어 설계가 효율적으로 사용하는 방법을 배우게 하는 형태인지 묻는 것이다.

11. 사용자가 경로 또는 메뉴 선택을 찾는 동안 자신감을 느끼는가?

사용자가 프로그램을 사용할때 자신이 없거나, 스트레스를 받으면 안된다.😥

12. 소프트웨어는 디자인 규약을 지키는가?

사용자 관점에서 소프트웨어 명세에 따른 행동은 어떠한지

 

사용자 기반의 테스트는 기본적으로 블랙박스 테스트 기법이다.

블랙박스 테스트는 프로그램이 명세에 따라 행동하지 않는 상황을 찾는다는 것을 기억하자..!

불편한 사용자 인터페이스 또는 특정 응용프로그램의 사양에 따라 작동하지 않는 것이나 무시한 것 등..

사양에 따라 동작하지 않는 다는 것을 놓친다면 그 개발과정은 실패 한 것이다.

 

사용성 테스트는 설계 결함으로 인한 소프트웨어의 인체 공학적 실수를 발견 해야 한다.

 

 

사용자 테스트 프로세스(Usability Testing Process)

사용성 테스트는 사용자 의견, 애플리케이션에 대한 반응 수집뿐만 아니라 테스트하는 항목의 목록을 분명히 해야한다.

 

모든 사용성 테스트는 계획으로 부터 시작되는데,

각 사용자에게 현실적이고 실제 존재하며 반복적인 활동을 수립해야 한다.

다양하고, 무작위를 통해, 소프트웨어의 모든 측면에서 사용자를 표현하기 위한 테스트 시나리오를 디자인한다.

e.g)

• 개별 고객의 기록을 찾고 수정한다.
• 회사 기록을 찾고 수정한다.
• 새로운 회사 기록을 만든다.
• 선택한 리스트를 프린터로 출력한다.

 

각 테스트 단계에서 사용자가 수행하는 동안 관찰된 결과를 기록한다.

테스트가 끝나면 인터뷰나 설문조사를 통해 문서를 만든다.

추가로 사용자에게 사용자는 같은 정보를 가지고 같은 방법으로 시작하게 되는지 확인해야한다.

일부 사용자가 다른 지시를 받는경우 테스트 결과의 신뢰성이 깨지게 된다.

 

 

테스트 대상 선정(Test User Selection)

완벽한 사용성 테스트 규약은 일반적으로 여러 개의 동일한 사용자 테스트 뿐만 아니라,

여러 사용자를 통한 테스트를 포함한다.

 

왜 동일한 사용자가 중복의 테스트를 수행하는 거지...?

테스트 하고자 하는 부분을 사용자가 기억하게 하는지,

즉 얼마나 많은 사용자가 세션의 진행을 통해 소프트웨어 운영에 대하여 학습하는지 알아보는 것이다.

 

특정 어플리케이션이 사용자가 사용 중인 어플리케이션과 유사할 경우 학습 과정은 매우 빨라 질 수 있다.

사용자가 수용하는 시간이 너무 오래걸리면 상업적인 실패의 원인이 되기도 한다.

따라서 특정 사용자 유형이나 산업에 적절한 소프트웨어는 실제 환경에서 애플리케이션의 유형들을 익숙히 다루는 전문가를 통해 테스트 해야 한다.

반대로, 일반적인 시장을 타겟으로 하는 소프트웨어는 무작위로 선정된 사용자가 테스트 할 수 있다.

 

반응형

 

그러면 도대체 얼마나 많은 사용자가 필요한거야??🤔

https://grapevine9700.tistory.com/412?category=671573 

사용용이성 테스팅에서 테스터 수 by Myers

 

야콥 닐슨이라는 사용성 테스트 전문가의 연구를 바탕으로 다음과 같은 공식을 사용한다.

E = 100*(1 - (1 - L)^n)

E = 발견된 오류의 비율, n = 테스터의 수, L = 테스터에 의해 발견된 사용성 문제의 비율

 

닐슨의 연구에서 얻은 합리적인 L = 31%이며, 다음과 같은 그래프를 얻을 수 있다고 한다.

그래프를 보면 몇가지 재미있는 점이 있는데,

첫번째로 우리가 직관적으로 아는 것과 같이 응용 프로그램의 사용성 오류를 모두 감지 할 수 없는 것이다.
곡선이 100% 수렴하기 때문에, 이론적으로 모든 오류를 발견하는 것은 불가 하다.

두번째로 테스터는 생각보다 소수가 필요하다는 것이다.
그래프를 보면 5명의 테스터는 83%정도의 오류를 감지 할 수 있다.!

 

닐슨은 테스터의 정확한 숫자는 경제적 고려사항과 테스트하고 있는 시스템 유형에 의해 결정된다고 했다.

또한, 다양한 사용자가 각자의 다른 배경과 경험으로 인해, 여러 다른 타입의 에러를 감지할 가능성이 높기 때문에, 개별 테스트 상황에 따라 더 많은 수의 테스터가 필요할 수도 있다.

 

---

 

데이터 수집 방법(Data-Gatehering Methods)

테스트 관리자 또는 관찰자는 여러 방법으로 테스트 결과를 수집 할 수 있다.

 

think-aloud protocol

think-aloud protocol을 사용하면 소프트웨어 사용성 및 애플리케이션 사용자 인식에 대한 우수한 데이터를 얻을 수 있다.

think-aloud protocol는 테스팅 작업을 수행하는 동안 큰 소리로 자신의 생각과 관찰을 말하는 것을 의미 한다.

think-aloud protocol의 단점은 부자연스러운 환경으로 인해 사용자 경험을 흐리게 하거나 수정될 수 있는 가능성이 존재하는 것이다.

 

원격 테스트

원격 테스트를 수행할 수도 있다.

장점으로는 원격 테스팅은 테스트 결과에 대한 외부의 영향 가능성을 제거하고 익숙한 환경에서 최종 애플리케이션을 테스트하는 것이다.

단점으로는 think-aloud protocol로 가능했던 세부 피드백을 개발자가 받지 못할 수 있다.

 

아이트래킹

아이트래킹은 복잡하지만 잠재적으로 유용한 방법이다.

우리의 눈은 특정 패던에 의해 스캔을 하며 화면을 읽는다. 이러한 데이터는 사용자가 제시된 소프트웨어 화면의 효율성을 잠재적으로 활용하는지 유용하게 쓸 수 있다.

 

---

 

사용성 설문(Usability Questionnaire)

사용성 질문은 신중하게 관련 테스트 절차로부터 필요한 정보를 얻을 수 있도록 계획 되어야 한다.

일반적으로 계산되고 분석할 수 있는 형태의 응답을 유도하는 설문을 만들고자 한다.

예를 들어

예/아니오 같은 답 대신

-5 ~ 5 까지 숫자로 답할 수 있게 한다.

대규모  소프트웨어 시스템에 대규모 사용자 집단을 통한 광범위한 테스트에서는 통계 프로그램은 경향을 발견하는 방법에 도움이 되지 않는다.

 

---

 

그렇다면 언제 그만 두어도 되는가?(When Is Enough, Enough?)

예산과 시간이 충분하다면 각 부분이 완료되면 그 단계의 소프트웨어를 테스트 하는 것이 좋다.

개별 구성 요소 개발 프로세스 전반에 대한 테스트를 진행한 경우

테스트의 마지막은 각 부분의 통합 작업에 대한 테스트를 진행해야 한다.

 

---

 

728x90

 

정리

성공적인 개발에 필수적인 사용성 테스트가 요구되고 있다.

성공적인 사용성 테스트는 정확하고 상세한 데이터 수집과 분석이다.

사용자 관찰, 시험 결과를 모으는 것으로 종료

테스트 결과는 반드시 분석되어야 하고 개발자는 데이터에서 확인된 내용을 소프트웨어에 반영하는 것을 고려해야한다.

식별된 소프트웨어 변경이 완료되고 난 뒤에 비슷한 작업을 하는 동일한 테스터를 통한 반복 과정이 될수 있다.