대부분의 개발 팀과 마찬가지로 여기에서도 Mendix, 우리는 스크럼을 적용하여 애플리케이션을 빌드합니다. 스크럼 방법의 일부는 사용자와 이해 관계자와 함께 제품을 검증하는 것입니다. 그러나 이 단계는 기능적 제품을 빌드하려는 최선의 노력에도 불구하고 많은 개발 팀에서 종종 무시됩니다. 일반적으로 발생하는 일은 사람들이 사용성 테스트를 너무 복잡하게 만들어서 개발 프로세스에서 제외하여 중요하지 않거나 리소스를 절약하고 있다고 잘못 생각하는 것입니다. 이는 사용자와 함께 (최소한의 가치 있는) 제품을 테스트하면 더 나은 결과를 얻을 수 있기 때문에 부끄러운 일입니다.
사용성 테스트는 애플리케이션의 성공 가능성을 높여줍니다.
애플리케이션의 성공은 사용자가 애플리케이션을 사용하는 방식에 따라 달라집니다. 사용성 문제는 제품 사용 의지에 부정적인 영향을 미칠 수 있으며, 따라서 애플리케이션의 장기적인 성공에도 부정적인 영향을 미칩니다. 책 "Rocket Surgery Made Easy"(Kurt, 2010)에 따르면, 모든 애플리케이션에는 사소한 문제에서 심각한 문제까지 사용성 문제가 있습니다. 여기서 문제는 사용성 문제가 일반적으로 설계자, 개발팀, 제품 소유자가 간과하는 것입니다. 애플리케이션을 사용하는 방법이 그들에게 '너무나 명확'하기 때문입니다.
사용성 테스트를 통해 사용성 문제를 쉽게 발견하고 설명할 수 있습니다. 개발 중에 이러한 문제를 해결하는 것은 성공적인 애플리케이션을 만들고 나중에 이를 수정하는 데 불필요한 개발 시간과 비용을 방지하는 데 필수적입니다.
왜 사람들은 검사를 하지 않을까요?
사용자 및 이해관계자와 함께 제품을 검증하는 것이 Scrum 프로세스의 필수 요소임에도 불구하고, 다음과 같은 이유로 사용성 테스트는 종종 생략됩니다.
- 사고방식: 가능한 한 빨리 애플리케이션을 배포하고 필요하면 나중에 조정하겠습니다.
- 저희(개발팀)는 사용성 문제를 겪지 않았으므로 문제가 없을 것입니다.
- 이를 위해서는 전문지식과 지식이 필요한데, 개발팀에는 그러한 것이 없습니다.
- 그리고 외부 업체를 고용하면 비용이 너무 많이 듭니다.
사용성 테스트는 며칠 또는 몇 주가 걸린다고 생각하는 경우가 많습니다. 그런 일정에 직면했을 때, 대부분은 우리에게 명백한 것들을 테스트하고 미세 조정하는 것보다 새로운 기능을 구축하는 데 리소스를 투자하는 것을 선호합니다.
당신을 위해 만들어진 사용성 테스트 방법
사용성 테스트가 얼마나 큰 영향을 미칠 수 있는지 알고 있는 당사의 디자인 팀은 테스트 방법을 확립했습니다. Mendix 우리 제작자가 프로세스에 삽입할 수 있는 제품. 실험 후, 우리는 간단하고 빠르고 저렴한 테스트 방법을 생각해냈습니다. Mendix 응용 프로그램. 우리가 설계한 접근 방식은 책 "Rocket Surgery Made Easy"(Kurt, 2010)에서 영감을 받았으며 개발자, 디자이너 및 제품 소유자에게 응용 프로그램이 어떻게 사용되고 어떻게 개선될 수 있는지에 대한 귀중한 통찰력을 제공합니다.
이 과정에서는 항상 생각해내지 못했던 흥미로운 것들을 발견하게 될 것이고, 사용성 문제를 해결하면 애플리케이션이 진정으로 사용자 친화적으로 만들어질 것입니다. 이 접근 방식은 또한 이해 관계자에게 참여를 요청하여 참여를 늘릴 수 있는 좋은 기회입니다. 게다가, 결과는 개발에 사용된 가정이 실제로 유효하지 않다는 것을 보여줄 수 있습니다.
따라서 Mendix 사용성 테스트 방법
단순함을 유지한다는 생각으로, 우리의 방법은 세 가지 주요 단계로 구성됩니다. 아래에 각 단계와 모든 테스트 경험을 최대한 활용하는 데 도움이 되는 몇 가지 지침이 나와 있습니다.
시험을 준비하세요
- 3번째 세션 계획 – 팁: 스프린트 검토를 사용하여 테스트를 실시하세요.
- 사용자 시나리오를 정의합니다.
- 신청서를 준비하세요 Mendix 테스트 환경.
- 시범 테스트를 실시합니다.
테스트 실시
- 관찰자는 소리를 끄고, 카메라를 끄고, 메모를 해야 합니다.
- 참가자를 안내할 진행자를 지정하세요.
- 사용자 시나리오를 수행할 때 참가자에게 "생각해 보라고" 요청합니다.
- 마지막 15분을 이용해 참가자들에게 질문을 하세요.
테스트를 검토하세요
- 각 관찰자는 자신들이 발견한 세 가지 중요한 사용성 문제를 제시합니다.
- 팀은 함께 상위 5개의 사용성 문제를 정의합니다.
- 각 사용성 문제를 새로운 스토리/작업으로 변환하여 프로젝트 백로그에 추가합니다.
이 방법을 가장 잘 보여주기 위해, 해커톤 애플리케이션*을 위해 만든 테스트를 예로 들어 보겠습니다. 이 테스트의 목표는 애플리케이션에서 해커톤 이벤트를 설정할 때 주최자에게 사용성 문제를 찾는 것이었습니다. 한 가지 주목할 점은 테스트를 수행하는 데 아침 한 번만 걸렸다는 것입니다.
*참고: 해커톤 애플리케이션을 사용하면 조직에서 해커가 등록하고 솔루션을 업로드하여 시청하고 수상자를 볼 수 있는 완전한 온라인 해커톤 이벤트를 설정하고 호스팅할 수 있습니다. 또한 솔루션을 평가하고 상을 수여할 수 있는 심사위원 패널을 추가할 수 있습니다. 해커톤 애플리케이션은 현재 다음에서 제공됩니다. 온라인마켓.
사용성 테스트 설정
프로젝트의 마지막 두 번째 스프린트에서는 총 60분짜리 세션 XNUMX개를 계획했습니다. 이를 통해 팀은 애플리케이션을 출시하기 전에 마지막 스프린트에서 사용성 문제를 해결할 수 있었습니다. 이해 관계자가 애플리케이션 검증에 참여하도록 하기 위해 참여자 또는 관찰자 역할을 하도록 요청했습니다.
준비의 또 다른 부분은 참가자를 위한 사용자 시나리오를 정의하는 것이었습니다. 팀과 제품 소유자는 다음 질문에 답함으로써 이를 수행했습니다.
- 우리가 확신하지 못하는 것은 무엇인가?
- 이 애플리케이션에서 가장 중요한 기능은 무엇입니까?
우리가 알고 싶었던 것 중 하나는 주최측이 애플리케이션에서 새로운 해커톤 이벤트를 어떻게 설정했는지였습니다. 그들은 의심이나 걸림돌 없이 양식을 작성할 수 있었을까요? 그들은 새로운 이벤트에 필요한 모든 정보를 추가할 수 있다고 느꼈을까요? 또한, 뉴스피드 페이지에 해커를 위한 게시물을 남기는 것은 다음 사용자 시나리오를 만들어 참가자들에게 테스트되었습니다.
"해커톤 동안 해커를 지원하기 위해 팁 목록을 게시하고 싶습니다. 앱을 사용하여 이러한 팁을 공유하세요:
Tips:
-
- 일어나서 몸을 움직여 깨어 있으십시오.
- 졸음을 없애기 위해 낮잠을 자십시오.
- 피로를 피하기 위해 눈을 쉬게 하세요.
시나리오를 작성하는 동안 참가자가 모든 것을 어떻게 완료하고 싶은지 결정하도록 최소한의 지침을 추가했습니다. 이런 방식으로 하면 엄격한 완료 방법을 지시하는 것보다 더 귀중한 통찰력을 얻을 수 있습니다.
다음으로, 해당 애플리케이션은 테스트 환경에 추가되었습니다. Mendix 플랫폼. 현실적인 테스트 환경을 생성하기 위해 다른 해커톤 이벤트의 더미 데이터를 추가하고, 참가자가 애플리케이션에 들어갈 수 있도록 사용자 계정을 만들었습니다. 마지막으로, 파일럿 테스트를 사용하여 테스트 설정과 환경을 검증했습니다.
설정에서 마지막 변경을 한 후, 실제 사용성 테스트를 시작할 준비가 되었습니다!
사용성 테스트 실시
각 세션이 시작될 때, 진행자(이번에는 디자이너가 맡았지만 팀원 중 누구라도 될 수 있음)는 설정 방법을 설명하고 팀에서 나중에 확인할 수 있도록 세션을 녹화해도 되는지 참가자들에게 허락을 구했습니다.
세션 내내 관찰자들은 카메라를 끄고 음소거하여 참가자와 진행자 간의 상호작용을 유지했습니다. 더 나은 전략은 참가자에게 누군가가 자신을 지켜보고 있다는(또는 심지어 판단하고 있다는) 느낌을 주지 않기 위해 "다른 방"에서 관찰하게 하는 것입니다.
참가자들은 사용자 시나리오를 수행할 때 소리 내어 생각해 보라는 요청을 받았습니다("생각하기 방법"). 이를 통해 팀은 혼자 지켜보는 것보다 무슨 일이 일어나고 있는지에 대한 더 많은 통찰력을 얻었습니다. 예를 들어, 한 참가자는 "새로운 해커톤" 버튼을 찾지 못했습니다. 그가 버튼을 찾을 수 있다고 생각하는 곳을 '말해 준' 덕분에 팀은 애플리케이션에서 가장 중요한 버튼의 위치를 개선하는 방법에 대한 귀중한 통찰력을 얻었습니다.
참가자들이 시나리오를 살펴보는 동안, 진행자는 필요할 때만 안내를 해주었습니다. 저를 믿으세요. 누군가가 막혀서 스스로 탈출구를 찾아야 할 때 가장 가치 있는 통찰력을 얻을 수 있습니다. 세션의 마지막 15분 동안 참가자, 진행자, 관찰자의 질문을 기록하고 처리했습니다. 이 부분은 참가자의 "고통스러운 점"을 성찰하기에 완벽하며, 특히 "신청서에서 바꿀 수 있는 것이 있다면, 무엇을 바꾸시겠습니까?"와 같은 보다 일반적인 질문을 할 때 더욱 그렇습니다.
이 예에서 세 명의 참가자는 모두 이 질문에 같은 방식으로 답했습니다. 그들은 '뉴스피드' 페이지로의 탐색을 개선할 것입니다. 관찰자들은 또한 페이지를 찾는 것이 실제로 그들에게 힘들다는 것을 알아챘습니다.
사용성 테스트를 검토하세요
세션 직후, 관찰자들과 함께 검토 회의를 진행하여 결과를 논의했습니다. 회의 시작 시, 모두가 발견한 가장 중요한 사용성 문제 1가지를 선택하여 발표했습니다. 그 후, 팀은 함께 협력하여 가장 중요한 사용성 문제 5가지를 결정하고 5(가장 중요한 것)에서 7(덜 중요한 것)까지 순위를 매겼습니다. 발견한 필수 문제의 수에 따라 "상위 10가지"는 "상위 XNUMX가지" 또는 "상위 XNUMX가지" 등이 될 수 있습니다.
우리가 발견한 중요한 문제 중 하나는 애플리케이션에 상과 상품을 추가하는 흐름이 불분명하다는 것이었습니다. 참가자 중 누구도 실수 없이 이를 수행할 수 없었습니다. 이는 앱을 만드는 모든 사람에게 수행해야 할 방법이 너무나 명확했기 때문에 팀에서 잠재적인 문제로 인식하지 못했습니다.
검토가 끝나면 가장 중요한 문제는 새로운 스토리/작업으로 번역되어 프로젝트 백로그에 추가되었습니다. Mendix 플랫폼에서 새로운 스토리/작업은 팀에서 빠르게 처리되었습니다. 이 모든 것이 1스프린트(2주) 이내에 개선된 버전의 애플리케이션으로 이어졌습니다!
맺음말
사용성 테스트의 중요한 부분은 여러 번의 성공적인 테스트를 수행한 후에 그 이점이 스스로를 말해준다는 것입니다. 더 성공적인 제품을 생산할 뿐만 아니라, 관련 팀도 사용성 테스트를 자신들이 참여하고 싶어하는 개발 프로세스의 필수 요소로 취급하기 시작할 것입니다. 왜냐하면 그들은 제품이 어떻게 사용되고 어떻게 개선될 수 있는지 직접 볼 수 있기 때문입니다.
당신이 테스트를 시작하도록 격려되기를 바랍니다 Mendix 분야의 다양한 어플리케이션에서 사용됩니다.
만들어 보세요(그리고 테스트해 보세요)!