उपयोगिता परीक्षण: Difference between revisions

From Vigyanwiki
(Created page with "{{short description|Technique in user-centered interaction design}} उपयोगिता परीक्षण उपयोगकर्ता-केंद्रित ड...")
 
No edit summary
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{short description|Technique in user-centered interaction design}}
{{short description|Technique in user-centered interaction design}}
उपयोगिता परीक्षण उपयोगकर्ता-केंद्रित डिज़ाइन में उपयोग की जाने वाली एक तकनीक है | उपयोगकर्ता-केंद्रित [[पारस्परिक प्रभाव वाली डिज़ाइन]] उपयोगकर्ताओं पर परीक्षण करके किसी उत्पाद का मूल्यांकन करने के लिए उपयोग किया जाता है। इसे एक अपूरणीय उपयोगिता अभ्यास के रूप में देखा जा सकता है, क्योंकि यह प्रत्यक्ष इनपुट देता है कि वास्तविक उपयोगकर्ता सिस्टम का उपयोग कैसे करते हैं।<ref>Nielsen, J. (1994). Usability Engineering, Academic Press Inc, p 165</ref> यह उत्पाद की डिजाइन सहजता से अधिक चिंतित है और उन उपयोगकर्ताओं के साथ परीक्षण किया गया है जिनके पास इसका कोई पूर्व अनुभव नहीं है। इस तरह का परीक्षण एक अंतिम उत्पाद की सफलता के लिए सर्वोपरि है क्योंकि पूरी तरह से काम करने वाला अनुप्रयोग जो अपने उपयोगकर्ताओं के बीच भ्रम पैदा करता है वह लंबे समय तक नहीं चलेगा।<ref>{{Cite web|url=https://moodup.team/blog/usability-testing-the-key-to-design-validation/|title=Usability Testing: the Key to Design Validation|last=Mejs|first=Monika|date=2019-06-27|website=Mood Up team - software house|language=en-US|access-date=2019-09-11}}</ref> यह [[उपयोगिता निरीक्षण]] विधियों के विपरीत है जहां विशेषज्ञ उपयोगकर्ताओं को शामिल किए बिना उपयोगकर्ता इंटरफ़ेस का मूल्यांकन करने के लिए विभिन्न तरीकों का उपयोग करते हैं।
उपयोगिता परीक्षण उपयोगकर्ता-केंद्रित डिज़ाइन में उपयोग की जाने वाली एक तकनीक है | उपयोगकर्ता-केंद्रित [[पारस्परिक प्रभाव वाली डिज़ाइन]] उपयोगकर्ताओं पर परीक्षण करके किसी उत्पाद का मूल्यांकन करने के लिए उपयोग किया जाता है। इसे एक अपूरणीय उपयोगिता अभ्यास के रूप में देखा जा सकता है, क्योंकि यह प्रत्यक्ष निवेश देता है कि वास्तविक उपयोगकर्ता पद्धति का उपयोग कैसे करते हैं।<ref>Nielsen, J. (1994). Usability Engineering, Academic Press Inc, p 165</ref> यह उत्पाद की डिजाइन सहजता से अधिक चिंतित है और उन उपयोगकर्ताओं के साथ परीक्षण किया गया है जिनके समीप इसका कोई पूर्व अनुभव नहीं है। इस प्रकार का परीक्षण एक अंतिम उत्पाद की सफलता के लिए सर्वोपरि है क्योंकि पूर्ण रूप से कार्य करने वाला अनुप्रयोग जो अपने उपयोगकर्ताओं के बीच विभ्रान्ति उत्पन्न करता है वह लंबे समय तक नहीं चलेगा।<ref>{{Cite web|url=https://moodup.team/blog/usability-testing-the-key-to-design-validation/|title=Usability Testing: the Key to Design Validation|last=Mejs|first=Monika|date=2019-06-27|website=Mood Up team - software house|language=en-US|access-date=2019-09-11}}</ref> यह [[उपयोगिता निरीक्षण]] विधियों के विपरीत है जहां विशेषज्ञ उपयोगकर्ताओं को सम्मिलित किए बिना उपयोगकर्ता अंतरापृष्ठ का मूल्यांकन करने के लिए विभिन्न विधियों का उपयोग करते हैं।


प्रयोज्यता परीक्षण मानव निर्मित उत्पाद की उसके इच्छित उद्देश्यों को पूरा करने की क्षमता को मापने पर केंद्रित है। उत्पादों के उदाहरण जो आमतौर पर उपयोगिता परीक्षण से लाभान्वित होते हैं, वे हैं भोजन, उपभोक्ता उत्पाद, [[वेबसाइट]] या वेब एप्लिकेशन, उपयोगकर्ता इंटरफ़ेस, दस्तावेज़ और उपकरण। उपयोगिता परीक्षण किसी विशिष्ट वस्तु या वस्तुओं के सेट की उपयोगिता, या उपयोग में आसानी को मापता है, जबकि सामान्य मानव-कंप्यूटर इंटरैक्शन अध्ययन सार्वभौमिक सिद्धांतों को तैयार करने का प्रयास करते हैं।
उपयोगिता परीक्षण मानव निर्मित उत्पाद की उसके इच्छित उद्देश्यों को पूर्ण करने की क्षमता को मापने पर केंद्रित है। उत्पादों के उदाहरण जो सामान्यतः उपयोगिता परीक्षण से लाभान्वित होते हैं, वे हैं भोजन, उपभोक्ता उत्पाद, [[वेबसाइट]] या वेब एप्लिकेशन, उपयोगकर्ता अंतरापृष्ठ, दस्तावेज़ और उपकरण। उपयोगिता परीक्षण किसी विशिष्ट वस्तु या वस्तुओं के समूह की उपयोगिता, या उपयोग में सुगमता को मापता है, जबकि सामान्य मानव-कंप्यूटर अन्योन्यक्रिया अध्ययन सार्वभौमिक सिद्धांतों को सूत्रबद्ध करने का प्रयत्न करते हैं।


== यह क्या नहीं है ==
== यह क्या नहीं है ==
किसी वस्तु या दस्तावेज़ पर केवल राय एकत्र करना उपयोगिता परीक्षण के बजाय [[बाजार अनुसंधान]] या [[गुणात्मक शोध]] है। उपयोगिता परीक्षण में आमतौर पर नियंत्रित परिस्थितियों में व्यवस्थित अवलोकन शामिल होता है ताकि यह निर्धारित किया जा सके कि लोग उत्पाद का कितनी अच्छी तरह उपयोग कर सकते हैं।<ref>{{cite web | url=http://jerz.setonhill.edu/writing/technical-writing/usability-testing/ | title=Usability Testing: What Is It? | work=Jerz's Literacy Weblog | date=July 19, 2000 | access-date=June 29, 2016 | author=Dennis G. Jerz}}</ref> हालांकि, अक्सर गुणात्मक शोध और उपयोगिता परीक्षण दोनों का संयोजन में उपयोग किया जाता है, ताकि उनके कार्यों के अलावा, उपयोगकर्ताओं की प्रेरणा/धारणाओं को बेहतर ढंग से समझा जा सके।
किसी वस्तु या दस्तावेज़ पर मात्र विचार एकत्र करना उपयोगिता परीक्षण के अतिरिक्त [[बाजार अनुसंधान]] या [[गुणात्मक शोध]] है। उपयोगिता परीक्षण में सामान्यतः नियंत्रित परिस्थितियों में व्यवस्थित अवलोकन सम्मिलित होता है ताकि यह निर्धारित किया जा सके कि लोग उत्पाद का कितना ठीक रूप से उपयोग कर सकते हैं।<ref>{{cite web | url=http://jerz.setonhill.edu/writing/technical-writing/usability-testing/ | title=Usability Testing: What Is It? | work=Jerz's Literacy Weblog | date=July 19, 2000 | access-date=June 29, 2016 | author=Dennis G. Jerz}}</ref> यद्यपि, प्रायः गुणात्मक शोध और उपयोगिता परीक्षण दोनों का संयोजन में उपयोग किया जाता है, ताकि उनके कार्यों के अतिरिक्त, उपयोगकर्ताओं की प्रेरणा/धारणाओं को ठीक रूप से समझा जा सके।


उपयोगकर्ताओं को एक कच्चा मसौदा दिखाने और पूछने के बजाय, क्या आप इसे समझते हैं? उपयोगिता परीक्षण में लोगों को इसके इच्छित उद्देश्य के लिए कुछ उपयोग करने की कोशिश करना शामिल है। उदाहरण के लिए, जब किसी खिलौने को असेंबल करने के लिए परीक्षण निर्देश दिए जाते हैं, तो परीक्षण विषयों को निर्देश और भागों का एक बॉक्स दिया जाना चाहिए और भागों और सामग्रियों पर टिप्पणी करने के लिए कहने के बजाय, उन्हें खिलौने को एक साथ रखने के लिए कहा जाना चाहिए। निर्देश वाक्यांश, चित्रण गुणवत्ता, और खिलौने का डिज़ाइन सभी असेंबली प्रक्रिया को प्रभावित करते हैं।
उपयोगकर्ताओं को एक अपूर्ण प्रारूप दिखाने और पूछने के अतिरिक्त, क्या आप इसे समझते हैं? उपयोगिता परीक्षण में लोगों को इसके इच्छित उद्देश्य के लिए कुछ उपयोग करने की प्रयत्न करना सम्मिलित है। उदाहरण के लिए, जब किसी खिलौने को कोडांतरण करने के लिए परीक्षण निर्देश दिए जाते हैं, तो परीक्षण विषयों को निर्देश और भागों का एक डिब्बा दिया जाना चाहिए और भागों और पदार्थों पर टिप्पणी करने के लिए कहने के अतिरिक्त, उन्हें खिलौने को एक साथ रखने के लिए कहा जाना चाहिए। निर्देश वाक्यांश, चित्रण गुणवत्ता, और खिलौने के डिज़ाइन सभी कोडांतरणी प्रक्रिया को प्रभावित करते हैं।


== तरीके ==
== विधियां ==
प्रयोज्य परीक्षण की स्थापना में सावधानीपूर्वक एक [[परिदृश्य]], या एक यथार्थवादी स्थिति बनाना शामिल है, जिसमें व्यक्ति [[गतिशील परीक्षण]] वाले उत्पाद का उपयोग करते हुए कार्यों की एक सूची करता है, जबकि पर्यवेक्षक देखते हैं और नोट्स लेते हैं (सॉफ़्टवेयर सत्यापन#गतिशील सत्यापन .28Test.2C प्रयोग.29) . कई अन्य स्टेटिक परीक्षण उपकरण जैसे स्क्रिप्टेड निर्देश, [[पेपर प्रोटोटाइप]], और प्री- और पोस्ट-टेस्ट प्रश्नावली का भी परीक्षण किए जा रहे उत्पाद पर प्रतिक्रिया एकत्र करने के लिए उपयोग किया जाता है (सॉफ़्टवेयर सत्यापन#स्टेटिक सत्यापन .28विश्लेषण.29)। उदाहरण के लिए, एक [[ईमेल]] प्रोग्राम के अटैचमेंट फ़ंक्शन का परीक्षण करने के लिए, एक परिदृश्य उस स्थिति का वर्णन करेगा जहां एक व्यक्ति को एक ई-मेल अटैचमेंट भेजने की आवश्यकता होती है, और उन्हें यह कार्य करने के लिए कहा जाता है। इसका उद्देश्य यह देखना है कि लोग यथार्थवादी तरीके से कैसे काम करते हैं, ताकि डेवलपर्स समस्या वाले क्षेत्रों की पहचान कर सकें और उन्हें ठीक कर सकें। प्रयोज्य परीक्षण के दौरान डेटा एकत्र करने के लिए लोकप्रिय तकनीकों में [[ज़ोर से सोचो प्रोटोकॉल]], को-डिस्कवरी लर्निंग और [[आँख ट्रैकिंग]] शामिल हैं।
उपयोगिता परीक्षण की स्थापना में सावधानीपूर्वक एक [[परिदृश्य]], या एक यथार्थवादी स्थिति बनाना सम्मिलित है, जिसमें व्यक्ति [[गतिशील परीक्षण]] वाले उत्पाद का उपयोग करते हुए कार्यों की एक सूची करता है, जबकि पर्यवेक्षक देखते हैं और टिप्पणियाँ लेते हैं(सॉफ़्टवेयर सत्यापन)कई अन्य स्थिर परीक्षण उपकरण जैसे लिखित निर्देश, [[पेपर प्रोटोटाइप|दस्तावेज़ प्रोटोटाइप]], और पूर्व- और पद-परीक्षण प्रश्नावली का भी परीक्षण किए जा रहे उत्पाद पर प्रतिक्रिया एकत्र करने के लिए उपयोग किया जाता है(सॉफ़्टवेयर सत्यापन)। उदाहरण के लिए, एक [[ईमेल]] प्रोग्राम के आसक्ति कार्य का परीक्षण करने के लिए, एक परिदृश्य उस स्थिति का वर्णन करेगा जहां एक व्यक्ति को एक ई-मेल आसक्ति भेजने की आवश्यकता होती है, और उन्हें यह कार्य करने के लिए कहा जाता है। इसका उद्देश्य यह देखना है कि लोग यथार्थवादी विधि से कैसे कार्य करते हैं, ताकि विकासक समस्या वाले क्षेत्रों की पहचान कर सकें और उन्हें ठीक कर सकें। उपयोगिता परीक्षण के समय डेटा एकत्र करने के लिए लोकप्रिय तकनीकों में [[ज़ोर से सोचो प्रोटोकॉल]], सह खोज अधिगम और [[आँख ट्रैकिंग|आँख मार्गन]] सम्मिलित हैं।


=== दालान परीक्षण ===
=== दालान परीक्षण ===


हॉलवे परीक्षण, जिसे गुरिल्ला उपयोगिता के रूप में भी जाना जाता है, उपयोगिता परीक्षण का एक त्वरित और सस्ता तरीका है जिसमें लोग - जैसे कि हॉलवे में गुजरने वालों - को उत्पाद या सेवा का उपयोग करने का प्रयास करने के लिए कहा जाता है। यह डिजाइनरों को ईंट की दीवारों की पहचान करने में मदद कर सकता है, समस्याएं इतनी गंभीर हैं कि उपयोगकर्ता नए डिजाइन के शुरुआती चरणों में आसानी से आगे नहीं बढ़ सकते हैं। परियोजना डिजाइनरों और इंजीनियरों के अलावा कोई भी इस्तेमाल किया जा सकता है (वे विशेषज्ञ समीक्षक के रूप में कार्य करते हैं क्योंकि वे परियोजना के बहुत करीब हैं)।
दालान परीक्षण, जिसे गुरिल्ला उपयोगिता के रूप में भी जाना जाता है, उपयोगिता परीक्षण का एक त्वरित और सस्ती विधि है जिसमें लोग - जैसे कि दालान में गुजरने वालों - को उत्पाद या सेवा का उपयोग करने का प्रयत्न करने के लिए कहा जाता है। यह डिजाइनरों को ईंट की दीवारों की पहचान करने में सहायता कर सकता है, समस्याएं इतनी गंभीर हैं कि उपयोगकर्ता नवीन डिजाइन के प्रारंभिक चरणों में सुगमता से आगे नहीं बढ़ सकते हैं। परियोजना डिजाइनरों और इंजीनियरों के अतिरिक्त कोई भी उपयोग किया जा सकता है(वे विशेषज्ञ समीक्षक के रूप में कार्य करते हैं क्योंकि वे परियोजना के बहुत समीप हैं)।


इस प्रकार का परीक्षण सुविधा नमूनाकरण का एक उदाहरण है और इस प्रकार परिणाम संभावित रूप से पक्षपाती हैं।
इस प्रकार का परीक्षण सुविधा नमूनाकरण का एक उदाहरण है और इस प्रकार परिणाम संभावित रूप से पक्षपाती हैं।
Line 20: Line 20:
=== दूरस्थ उपयोगिता परीक्षण ===
=== दूरस्थ उपयोगिता परीक्षण ===


ऐसे परिदृश्य में जहां प्रयोज्यता मूल्यांकनकर्ता, विकासकर्ता और संभावित उपयोगकर्ता विभिन्न देशों और समय क्षेत्रों में स्थित हैं, एक पारंपरिक प्रयोगशाला उपयोगिता मूल्यांकन का आयोजन लागत और संभार तंत्र दोनों दृष्टिकोणों से चुनौतियां पैदा करता है। इन चिंताओं ने दूरस्थ उपयोगिता मूल्यांकन पर शोध किया, उपयोगकर्ता और मूल्यांकनकर्ता अंतरिक्ष और समय से अलग हो गए। दूरस्थ परीक्षण, जो उपयोगकर्ता के अन्य कार्यों और प्रौद्योगिकी के संदर्भ में किए जा रहे मूल्यांकन को सुगम बनाता है, या तो तुल्यकालिक या अतुल्यकालिक हो सकता है। पूर्व में मूल्यांकनकर्ता और उपयोगकर्ता के बीच वास्तविक समय पर एक-एक संचार शामिल होता है, जबकि बाद में मूल्यांकनकर्ता और उपयोगकर्ता अलग-अलग काम करते हैं।<ref>{{cite book |doi=10.1145/1240624.1240838 |chapter=What happened to remote usability testing? |title=कंप्यूटिंग सिस्टम में मानव कारक पर SIGCHI सम्मेलन की कार्यवाही|year=2007 |last1=Andreasen |first1=Morten Sieker |last2=Nielsen |first2=Henrik Villemann |last3=Schrøder |first3=Simon Ormholt |last4=Stage |first4=Jan |isbn=978-1-59593-593-9 |page=1405 |s2cid=12388042 }}</ref> इन दोनों तरीकों की जरूरतों को पूरा करने के लिए कई टूल उपलब्ध हैं।
ऐसे परिदृश्य में जहां उपयोगिता मूल्यांकनकर्ता, विकासकर्ता और संभावित उपयोगकर्ता विभिन्न देशों और समय क्षेत्रों में स्थित हैं, एक परंपरागत प्रयोगशाला उपयोगिता मूल्यांकन का आयोजन लागत और संभार तंत्र दोनों दृष्टिकोणों से चुनौतियां उत्पन्न करते है। इन चिंताओं ने दूरस्थ उपयोगिता मूल्यांकन पर शोध किया, उपयोगकर्ता और मूल्यांकनकर्ता अंतरिक्ष और समय से अलग हो गए। दूरस्थ परीक्षण, जो उपयोगकर्ता के अन्य कार्यों और प्रौद्योगिकी के संदर्भ में किए जा रहे मूल्यांकन को सुगम बनाते है, या तो तुल्यकालिक या अतुल्यकालिक हो सकता है। पूर्व में मूल्यांकनकर्ता और उपयोगकर्ता के बीच वास्तविक समय पर एक-एक संचार सम्मिलित होता है, जबकि बाद में मूल्यांकनकर्ता और उपयोगकर्ता अलग-अलग कार्य करते हैं।<ref>{{cite book |doi=10.1145/1240624.1240838 |chapter=What happened to remote usability testing? |title=कंप्यूटिंग सिस्टम में मानव कारक पर SIGCHI सम्मेलन की कार्यवाही|year=2007 |last1=Andreasen |first1=Morten Sieker |last2=Nielsen |first2=Henrik Villemann |last3=Schrøder |first3=Simon Ormholt |last4=Stage |first4=Jan |isbn=978-1-59593-593-9 |page=1405 |s2cid=12388042 }}</ref> इन दोनों विधियों की आवश्यकताओं को पूर्ण करने के लिए कई उपकरण उपलब्ध हैं।


तुल्यकालिक उपयोगिता परीक्षण पद्धति में वीडियो कॉन्फ्रेंसिंग शामिल है या वेबएक्स जैसे दूरस्थ एप्लिकेशन साझाकरण टूल को नियोजित करता है। WebEx और GoToMeeting सिंक्रोनस रिमोट उपयोगिता परीक्षण करने के लिए सबसे अधिक उपयोग की जाने वाली तकनीकें हैं।<ref>{{cite web|url=http://www.boxesandarrows.com/view/remote_online_usability_testing_why_how_and_when_to_use_it|title=Remote Online Usability Testing: Why, How, and When to Use It|author=Dabney Gough|author2=Holly Phillips|date=2003-06-09|archive-url=https://web.archive.org/web/20051215231619/http://www.boxesandarrows.com/view/remote_online_usability_testing_why_how_and_when_to_use_it|archive-date=December 15, 2005}}</ref> हालांकि, तुल्यकालिक दूरस्थ परीक्षण में सहयोगी परीक्षण प्रक्रिया का समर्थन करने के लिए वांछित उपस्थिति और उपस्थिति की भावना की कमी हो सकती है। इसके अलावा, सांस्कृतिक और भाषाई बाधाओं के पार पारस्परिक गतिशीलता का प्रबंधन करने के लिए शामिल संस्कृतियों के प्रति संवेदनशील दृष्टिकोण की आवश्यकता हो सकती है। अन्य नुकसानों में परीक्षण वातावरण पर कम नियंत्रण और प्रतिभागियों द्वारा अपने मूल वातावरण में अनुभव किए गए विक्षेप और रुकावट शामिल हैं।<ref name="Dray & Siegel 2004">{{cite journal |last1=Dray |first1=Susan |last2=Siegel |first2=David |title=Remote possibilities?: international usability testing at a distance |journal=Interactions |date=March 2004 |volume=11 |issue=2 |pages=10–17 |doi=10.1145/971258.971264 |s2cid=682010 }}</ref> आभासी दुनिया का उपयोग करके एक तुल्यकालिक दूरस्थ उपयोगिता परीक्षण करने के लिए विकसित नए तरीकों में से एक है।<ref>{{cite book |doi=10.1145/1978942.1979267 |chapter=Synchronous remote usability testing |title=कंप्यूटिंग सिस्टम में मानव कारक पर SIGCHI सम्मेलन की कार्यवाही|year=2011 |last1=Chalil Madathil |first1=Kapil |last2=Greenstein |first2=Joel S. |pages=2225–2234 |isbn=978-1-4503-0228-9 |s2cid=14077658 }}</ref>
तुल्यकालिक उपयोगिता परीक्षण पद्धति में वीडियो कॉन्फ्रेंसिंग सम्मिलित है या वेबएक्स जैसे दूरस्थ एप्लिकेशन साझाकरण उपकरण को नियोजित करता है। वेबएक्स और गोटूमीटिंग समकालिक दूरस्थ उपयोगिता परीक्षण करने के लिए सबसे अधिक उपयोग की जाने वाली तकनीकें हैं।<ref>{{cite web|url=http://www.boxesandarrows.com/view/remote_online_usability_testing_why_how_and_when_to_use_it|title=Remote Online Usability Testing: Why, How, and When to Use It|author=Dabney Gough|author2=Holly Phillips|date=2003-06-09|archive-url=https://web.archive.org/web/20051215231619/http://www.boxesandarrows.com/view/remote_online_usability_testing_why_how_and_when_to_use_it|archive-date=December 15, 2005}}</ref> यद्यपि, तुल्यकालिक दूरस्थ परीक्षण में सहयोगी परीक्षण प्रक्रिया का समर्थन करने के लिए वांछित उपस्थिति और उपस्थिति की भावना की कमी हो सकती है। इसके अतिरिक्त, सांस्कृतिक और भाषाई बाधाओं के पार पारस्परिक गतिशीलता का प्रबंधन करने के लिए सम्मिलित संस्कृतियों के प्रति संवेदनशील दृष्टिकोण की आवश्यकता हो सकती है। अन्य क्षतियों में परीक्षण वातावरण पर कम नियंत्रण और प्रतिभागियों द्वारा अपने मूल वातावरण में अनुभव किए गए विक्षेप और रुकावट सम्मिलित हैं।<ref name="Dray & Siegel 2004">{{cite journal |last1=Dray |first1=Susan |last2=Siegel |first2=David |title=Remote possibilities?: international usability testing at a distance |journal=Interactions |date=March 2004 |volume=11 |issue=2 |pages=10–17 |doi=10.1145/971258.971264 |s2cid=682010 }}</ref> आभासी संसार का उपयोग करके एक तुल्यकालिक दूरस्थ उपयोगिता परीक्षण करने के लिए विकसित नवीन विधियों में से एक है।<ref>{{cite book |doi=10.1145/1978942.1979267 |chapter=Synchronous remote usability testing |title=कंप्यूटिंग सिस्टम में मानव कारक पर SIGCHI सम्मेलन की कार्यवाही|year=2011 |last1=Chalil Madathil |first1=Kapil |last2=Greenstein |first2=Joel S. |pages=2225–2234 |isbn=978-1-4503-0228-9 |s2cid=14077658 }}</ref>
अतुल्यकालिक पद्धतियों में उपयोगकर्ता की क्लिक स्ट्रीम का स्वत: संग्रह, महत्वपूर्ण घटनाओं के उपयोगकर्ता लॉग शामिल होते हैं जो एप्लिकेशन के साथ बातचीत करते समय होते हैं और उपयोगकर्ताओं द्वारा इंटरफ़ेस पर व्यक्तिपरक प्रतिक्रिया होती है।<ref name="Dray & Siegel 2004"/>इन-लैब अध्ययन के समान, एक अतुल्यकालिक दूरस्थ उपयोगिता परीक्षण कार्य-आधारित है और प्लेटफ़ॉर्म शोधकर्ताओं को क्लिक और कार्य समय पर कब्जा करने की अनुमति देता है। इसलिए, कई बड़ी कंपनियों के लिए, यह शोधकर्ताओं को किसी वेबसाइट या मोबाइल साइट पर जाने पर आगंतुकों के इरादों को बेहतर ढंग से समझने की अनुमति देता है। इसके अतिरिक्त, उपयोगकर्ता परीक्षण की यह शैली जनसांख्यिकीय, व्यवहारिक और व्यवहारिक प्रकार से फीडबैक को विभाजित करने का अवसर भी प्रदान करती है। परीक्षण उपयोगकर्ता के अपने वातावरण (प्रयोगशालाओं के बजाय) में किए जाते हैं जो वास्तविक जीवन परिदृश्य परीक्षण को आगे बढ़ाने में मदद करते हैं। यह दृष्टिकोण दूरदराज के क्षेत्रों में उपयोगकर्ताओं से आसानी से और कम संगठनात्मक ओवरहेड्स के साथ आसानी से फीडबैक मांगने के लिए एक वाहन प्रदान करता है। हाल के वर्षों में, एसिंक्रोनस रूप से उपयोगिता परीक्षण आयोजित करना भी प्रचलित हो गया है और परीक्षकों को अपने खाली समय में और अपने घर के आराम से प्रतिक्रिया प्रदान करने की अनुमति देता है।
 
अतुल्यकालिक पद्धतियों में उपयोगकर्ता की क्लिक स्ट्रीम का स्वत: संग्रह, महत्वपूर्ण घटनाओं के उपयोगकर्ता लॉग सम्मिलित होते हैं जो एप्लिकेशन के साथ अन्योन्यक्रिया करते समय होते हैं और उपयोगकर्ताओं द्वारा अंतरापृष्ठ पर व्यक्तिपरक प्रतिक्रिया होती है।<ref name="Dray & Siegel 2004" /> प्रयोगशाला में अध्ययन के समान, एक अतुल्यकालिक दूरस्थ उपयोगिता परीक्षण कार्य-आधारित है और प्लेटफ़ॉर्म शोधकर्ताओं को क्लिक और कार्य समय पर आधिपत्य करने की अनुमति देता है। इसलिए, कई बड़ी कंपनियों के लिए, यह शोधकर्ताओं को किसी वेबसाइट या मोबाइल साइट पर जाने पर आगंतुकों के विचारों को ठीक रूप से समझने की अनुमति देता है। इसके अतिरिक्त, उपयोगकर्ता परीक्षण की यह शैली जनसांख्यिकीय, व्यवहारिक और व्यवहारिक प्रकार से प्रतिपुष्टि को विभाजित करने का अवसर भी प्रदान करती है। परीक्षण उपयोगकर्ता के अपने वातावरण(प्रयोगशालाओं के अतिरिक्त) में किए जाते हैं जो वास्तविक जीवन परिदृश्य परीक्षण को आगे बढ़ाने में सहायता करते हैं। यह दृष्टिकोण दूरदराज के क्षेत्रों में उपयोगकर्ताओं से सुगमता से और कम संगठनात्मक उपरिव्यय के साथ सुगमता से प्रतिपुष्टि मांगने के लिए एक वाहन प्रदान करता है। आधुनिक वर्षों में, समकालिक रूप से उपयोगिता परीक्षण आयोजित करना भी प्रचलित हो गया है और परीक्षकों को अपने रिक्त समय में और अपने घर के आराम से प्रतिक्रिया प्रदान करने की अनुमति देता है।


=== विशेषज्ञ समीक्षा ===
=== विशेषज्ञ समीक्षा ===


उपयोगिता परीक्षण का एक अन्य सामान्य तरीका विशेषज्ञ समीक्षा है। जैसा कि नाम से पता चलता है, यह विधि किसी उत्पाद की प्रयोज्यता का मूल्यांकन करने के लिए क्षेत्र में अनुभव वाले विशेषज्ञों (संभवतः उन कंपनियों से जो उपयोगिता परीक्षण में विशेषज्ञ हैं) को लाने पर निर्भर करती है।
उपयोगिता परीक्षण का एक अन्य सामान्य विधि विशेषज्ञ समीक्षा है। जैसा कि नाम से ज्ञात होता है, यह विधि किसी उत्पाद की उपयोगिता का मूल्यांकन करने के लिए क्षेत्र में अनुभव वाले विशेषज्ञों(संभवतः उन कंपनियों से जो उपयोगिता परीक्षण में विशेषज्ञ हैं) को लाने पर निर्भर करती है।
 
एक [[अनुमानी मूल्यांकन]] या उपयोगिता लेखापरीक्षा एक या अधिक मानव कारक विशेषज्ञों द्वारा एक अंतरापृष्ठ का मूल्यांकन है। मूल्यांकनकर्ता उपयोगिता सिद्धांतों के आधार पर अंतरापृष्ठ की उपयोगिता, दक्षता और प्रभावशीलता को मापते हैं, जैसे कि 1994 में जैकब नीलसन(उपयोगिता सलाहकार) द्वारा मूल रूप से परिभाषित 10 उपयोगिता अनुमान।<ref>{{cite web|title=अनुमानी मूल्यांकन|url=http://www.usabilityfirst.com/usability-methods/heuristic-evaluation/|publisher=Usability First|access-date=April 9, 2013}}</ref>


एक [[अनुमानी मूल्यांकन]] या प्रयोज्य लेखापरीक्षा एक या अधिक मानव कारक विशेषज्ञों द्वारा एक इंटरफ़ेस का मूल्यांकन है। मूल्यांकनकर्ता प्रयोज्य सिद्धांतों के आधार पर इंटरफ़ेस की उपयोगिता, दक्षता और प्रभावशीलता को मापते हैं, जैसे कि 1994 में जैकब नीलसन (प्रयोज्य सलाहकार) द्वारा मूल रूप से परिभाषित 10 उपयोगिता अनुमान।<ref>{{cite web|title=अनुमानी मूल्यांकन|url=http://www.usabilityfirst.com/usability-methods/heuristic-evaluation/|publisher=Usability First|access-date=April 9, 2013}}</ref>
नीलसन की उपयोगिता अनुमान, जो उपयोगकर्ता अनुसंधान और नवीन उपकरणों की प्रतिक्रिया में विकसित होना जारी है, में सम्मिलित हैं:
नीलसन की उपयोगिता अनुमान, जो उपयोगकर्ता अनुसंधान और नए उपकरणों के जवाब में विकसित होना जारी है, में शामिल हैं:
* पद्धति स्थिति की दृश्यता
* सिस्टम स्थिति की दृश्यता
* प्रणाली और वास्तविक संसार के बीच मेल
* प्रणाली और वास्तविक दुनिया के बीच मेल
* उपयोगकर्ता नियंत्रण और स्वतंत्रता
* उपयोगकर्ता नियंत्रण और स्वतंत्रता
* संगति और मानक
* संगति और मानक
* त्रुटि निवारण
* त्रुटि निवारण
* याद करने के बजाय पहचान
* याद करने के अतिरिक्त पहचान
* लचीलापन और उपयोग की दक्षता
* लचीलापन और उपयोग की दक्षता
* सौंदर्य और न्यूनतम डिजाइन
* सौंदर्य और न्यूनतम डिजाइन
Line 44: Line 46:
=== स्वचालित विशेषज्ञ समीक्षा ===
=== स्वचालित विशेषज्ञ समीक्षा ===


विशेषज्ञ समीक्षाओं के समान, स्वचालित विशेषज्ञ समीक्षाएं उपयोगिता परीक्षण प्रदान करती हैं, लेकिन अच्छे डिजाइन और ह्यूरिस्टिक्स के लिए दिए गए नियमों के कार्यक्रमों के उपयोग के माध्यम से। हालांकि एक स्वचालित समीक्षा लोगों की समीक्षाओं के रूप में अधिक विवरण और अंतर्दृष्टि प्रदान नहीं कर सकती है, लेकिन उन्हें अधिक तेज़ी से और लगातार समाप्त किया जा सकता है। उपयोगिता परीक्षण के लिए सरोगेट उपयोगकर्ता बनाने का विचार कृत्रिम बुद्धि समुदाय के लिए एक महत्वाकांक्षी दिशा है।
विशेषज्ञ समीक्षाओं के समान, स्वचालित विशेषज्ञ समीक्षाएं उपयोगिता परीक्षण प्रदान करती हैं, परंतु कार्यक्रमों के उपयोग के माध्यम से अच्छे डिजाइन और अनुमानी के लिए नियम दिए गए हैं। यद्यपि एक स्वचालित समीक्षा लोगों की समीक्षाओं के रूप में अधिक विवरण और अंतर्दृष्टि प्रदान नहीं कर सकती है, परंतु उन्हें अधिक तीव्रता से और निरंतर समाप्त किया जा सकता है। उपयोगिता परीक्षण के लिए प्रतिनिधि उपयोगकर्ता बनाने का विचार कृत्रिम बुद्धिमत्ता समुदाय के लिए एक महत्वाकांक्षी दिशा है।


===ए/बी परीक्षण===
===ए/बी परीक्षण===
{{Main|A/B testing}}
{{Main|/बी परीक्षण}}


वेब डेवलपमेंट और मार्केटिंग में, A/B टेस्टिंग या स्प्लिट टेस्टिंग वेब डिज़ाइन (विशेष रूप से उपयोगकर्ता अनुभव डिज़ाइन) के लिए एक प्रायोगिक दृष्टिकोण है, जिसका उद्देश्य उन वेब पेजों में परिवर्तनों की पहचान करना है जो रुचि के परिणाम को बढ़ाते हैं या अधिकतम करते हैं (जैसे, क्लिक-थ्रू दर) एक बैनर विज्ञापन के लिए)। जैसा कि नाम से पता चलता है, दो संस्करणों (ए और बी) की तुलना की जाती है, जो एक भिन्नता को छोड़कर समान हैं जो उपयोगकर्ता के व्यवहार को प्रभावित कर सकती हैं। संस्करण ए वर्तमान में उपयोग किया जाने वाला संस्करण हो सकता है, जबकि संस्करण बी को कुछ मामलों में संशोधित किया गया है। उदाहरण के लिए, ई-कॉमर्स वेबसाइट पर खरीद फ़नल आमतौर पर A/B परीक्षण के लिए एक अच्छा उम्मीदवार है, क्योंकि ड्रॉप-ऑफ़ दरों में मामूली सुधार भी बिक्री में महत्वपूर्ण लाभ का प्रतिनिधित्व कर सकता है। कॉपी टेक्स्ट, लेआउट, इमेज और रंगों जैसे परीक्षण तत्वों के माध्यम से महत्वपूर्ण सुधार देखे जा सकते हैं।
वेब विकास और विपणन में, /बी परिक्षण या स्प्लिट परिक्षण वेब डिज़ाइन(विशेष रूप से उपयोगकर्ता अनुभव डिज़ाइन) के लिए एक प्रायोगिक दृष्टिकोण है, जिसका उद्देश्य उन वेब पेजों में परिवर्तनों की पहचान करना है जो रुचि के परिणाम को बढ़ाते हैं या अधिकतम करते हैं(जैसे, क्लिक-थ्रू दर) एक बैनर विज्ञापन के लिए)। जैसा कि नाम से ज्ञात होता है, दो संस्करणों(ए और बी) की तुलना की जाती है, जो एक भिन्नता को छोड़कर समान हैं जो उपयोगकर्ता के गतिविधि को प्रभावित कर सकती हैं। संस्करण ए वर्तमान में उपयोग किया जाने वाला संस्करण हो सकता है, जबकि संस्करण बी को कुछ विषयों में संशोधित किया गया है। उदाहरण के लिए, ई-कॉमर्स वेबसाइट पर खरीद कीप सामान्यतः ए/बी परीक्षण के लिए एक अच्छा उम्मीदवार है, क्योंकि कम दरों में सामान्य सुधार भी बिक्री में महत्वपूर्ण लाभ का प्रतिनिधित्व कर सकता है। कॉपी टेक्स्ट, लेआउट, प्रतिरूप और रंगों जैसे परीक्षण अवयवों के माध्यम से महत्वपूर्ण सुधार देखे जा सकते हैं।


बहुभिन्नरूपी परीक्षण या बकेट परीक्षण A/B परीक्षण के समान है लेकिन एक ही समय में दो से अधिक संस्करणों का परीक्षण करता है।
बहुभिन्नरूपी परीक्षण या डोल परीक्षण /बी परीक्षण के समान है परंतु एक ही समय में दो से अधिक संस्करणों का परीक्षण करता है।


== प्रतिभागियों की संख्या ==
== प्रतिभागियों की संख्या ==


1990 के दशक की शुरुआत में, जैकब नीलसन (उपयोगिता सलाहकार), उस समय [[सन माइक्रोसिस्टम्स]] के एक शोधकर्ता ने कई छोटे प्रयोज्य परीक्षणों का उपयोग करने की अवधारणा को लोकप्रिय बनाया- आम तौर पर केवल पांच प्रतिभागियों के साथ- विकास प्रक्रिया के विभिन्न चरणों में। उनका तर्क यह है कि, एक बार जब यह पाया जाता है कि दो या तीन लोग होम पेज से पूरी तरह से भ्रमित हैं, तो अधिक लोगों को एक ही त्रुटिपूर्ण डिजाइन के माध्यम से पीड़ित देखकर बहुत कम लाभ होता है। विस्तृत उपयोगिता परीक्षण संसाधनों की बर्बादी है। सबसे अच्छे परिणाम पांच से अधिक उपयोगकर्ताओं के परीक्षण से आते हैं और आप जितने छोटे परीक्षण कर सकते हैं उतने छोटे परीक्षण चला सकते हैं।<ref name="useit">{{cite web|url=http://www.useit.com/alertbox/20000319.html|title=Usability Testing with 5 Users (Jakob Nielsen's Alertbox)|publisher=useit.com|date=2000-03-13}}; references {{cite book |doi=10.1145/169059.169166 |chapter=A mathematical model of the finding of usability problems |title=Proceedings of the SIGCHI conference on Human factors in computing systems |year=1993 |last1=Nielsen |first1=Jakob |last2=Landauer |first2=Thomas K. |pages=206–213 |isbn=978-0-89791-575-5 |s2cid=207177537 }}</ref>
1990 के दशक की प्रारंभ में, जैकब नीलसन(उपयोगिता सलाहकार), उस समय [[सन माइक्रोसिस्टम्स|सन मिक्रोसिस्टम्स]] के एक शोधकर्ता ने विकास प्रक्रिया के विभिन्न चरणों में कई छोटे उपयोगिता परीक्षणों का उपयोग करने की अवधारणा को लोकप्रिय बनाया- सामान्यतः मात्र पांच प्रतिभागियों के साथ। उनका तर्क यह है कि, एक बार जब यह पाया जाता है कि दो या तीन लोग होम पेज से पूर्ण रूप से अस्पष्ट हैं, तो अधिक लोगों को एक ही त्रुटिपूर्ण डिजाइन के माध्यम से पीड़ित देखकर बहुत कम लाभ होता है। विस्तृत उपयोगिता परीक्षण संसाधनों की बर्बादी है। सबसे अच्छे परिणाम पांच से अधिक उपयोगकर्ताओं के परीक्षण से आते हैं और आप जितने छोटे परीक्षण कर सकते हैं उतने छोटे परीक्षण चला सकते हैं।<ref name="useit">{{cite web|url=http://www.useit.com/alertbox/20000319.html|title=Usability Testing with 5 Users (Jakob Nielsen's Alertbox)|publisher=useit.com|date=2000-03-13}}; references {{cite book |doi=10.1145/169059.169166 |chapter=A mathematical model of the finding of usability problems |title=Proceedings of the SIGCHI conference on Human factors in computing systems |year=1993 |last1=Nielsen |first1=Jakob |last2=Landauer |first2=Thomas K. |pages=206–213 |isbn=978-0-89791-575-5 |s2cid=207177537 }}</ref>  
फाइव यूजर्स का दावा काफी है बाद में एक गणितीय मॉडल द्वारा वर्णित किया गया था<ref>{{cite journal |last=Virzi |first=R. A. |title=Refining the Test Phase of Usability Evaluation: How Many Subjects is Enough? |journal=Human Factors |year=1992 |volume=34 |issue=4 |pages=457–468 |doi=10.1177/001872089203400407 |s2cid=59748299 }}</ref> जो उजागर समस्याओं के अनुपात के लिए बताता है यू
 
पांच उपयोगकर्ताओं का प्रभुत्व अत्यधिक है बाद में एक गणितीय मॉडल द्वारा वर्णित किया गया था<ref>{{cite journal |last=Virzi |first=R. A. |title=Refining the Test Phase of Usability Evaluation: How Many Subjects is Enough? |journal=Human Factors |year=1992 |volume=34 |issue=4 |pages=457–468 |doi=10.1177/001872089203400407 |s2cid=59748299 }}</ref> जो अपूरित समस्याओं के अनुपात के लिए बताता है यू


<math>U = 1-(1-p)^n</math>
<math>U = 1-(1-p)^n</math>
जहां पी एक विशिष्ट समस्या की पहचान करने वाले एक विषय की संभावना है और एन विषयों की संख्या (या परीक्षण सत्र)। यह मॉडल वास्तविक मौजूदा समस्याओं की संख्या के लिए एक स्पर्शोन्मुख ग्राफ के रूप में दिखाई देता है (नीचे चित्र देखें)।


[[Image:Virzis Formula.PNG]]बाद के शोध में नीलसन के दावे पर दोनों अनुभवजन्य साक्ष्यों का उपयोग करते हुए सवाल उठाया गया है<ref>{{cite conference |last1=Spool |first1=Jared |last2=Schroeder |first2=Will |title=Testing web sites: five users is nowhere near enough |conference=CHI '01 extended abstracts on Human factors in computing systems |date=2001 |page=285 |doi=10.1145/634067.634236 |s2cid=8038786 }}</ref> और अधिक उन्नत गणितीय मॉडल।<ref>{{cite journal |last=Caulton |first=D. A. |title=उपयोगिता परीक्षण में एकरूपता धारणा को शिथिल करना|journal=Behaviour & Information Technology |year=2001 |volume=20 |issue=1 |pages=1–7 |doi=10.1080/01449290010020648 |s2cid=62751921 }}</ref> इस दावे की दो प्रमुख चुनौतियाँ हैं:
जहां p एक विशिष्ट समस्या की पहचान करने वाले एक विषय की संभावना है और n विषयों की संख्या(या परीक्षण सत्र)। यह मॉडल वास्तविक वर्तमान समस्याओं की संख्या के लिए एक स्पर्शोन्मुख ग्राफ के रूप में दिखाई देता है(नीचे चित्र देखें)।
# चूंकि प्रयोज्यता उपयोगकर्ताओं के विशिष्ट सेट से संबंधित है, इसलिए इस तरह के एक छोटे से नमूने का आकार कुल जनसंख्या का प्रतिनिधित्व करने की संभावना नहीं है, इसलिए इस तरह के एक छोटे से नमूने के डेटा की जनसंख्या की तुलना में नमूना समूह को प्रतिबिंबित करने की अधिक संभावना है।
# प्रयोज्यता की प्रत्येक समस्या का पता लगाना समान रूप से आसान नहीं है। समग्र प्रक्रिया को धीमा करने के लिए अट्रैक्टिव समस्याएं होती हैं। इन परिस्थितियों में, प्रक्रिया की प्रगति नीलसन/लैंडौयर सूत्र द्वारा भविष्यवाणी की तुलना में बहुत कम है।<ref>{{cite journal |last1=Schmettow |first1=Martin |title=प्रयोज्यता मूल्यांकन प्रक्रिया में विषमता|series=Electronic Workshops in Computing |date=1 September 2008 |doi=10.14236/ewic/HCI2008.9 |doi-access=free }}</ref>
यह ध्यान देने योग्य है कि नीलसन पांच उपयोगकर्ताओं के साथ एक परीक्षण के बाद रुकने की वकालत नहीं करता है; उनका कहना है कि पांच उपयोगकर्ताओं के साथ परीक्षण करना, उनके द्वारा उजागर की गई समस्याओं को ठीक करना और फिर पांच अलग-अलग उपयोगकर्ताओं के साथ संशोधित साइट का परीक्षण करना 10 उपयोगकर्ताओं के साथ एकल उपयोगिता परीक्षण चलाने की तुलना में सीमित संसाधनों का बेहतर उपयोग है। व्यवहार में, परीक्षण पूरे विकास चक्र के दौरान प्रति सप्ताह एक या दो बार चलाया जाता है, प्रति दौर तीन से पांच परीक्षण विषयों का उपयोग करके, और परिणाम डिजाइनरों को 24 घंटे के भीतर वितरित किए जाते हैं। परियोजना के दौरान वास्तव में परीक्षण किए गए उपयोगकर्ताओं की संख्या इस प्रकार 50 से 100 लोगों तक आसानी से पहुंच सकती है। अनुसंधान से पता चलता है कि संगठनों द्वारा किए गए उपयोगकर्ता परीक्षण में आमतौर पर 5-10 प्रतिभागियों की भर्ती शामिल होती है।<ref>{{Cite web|title=Results of the 2020 User Testing Industry Report|url=https://www.userfountain.com/results-of-the-2020-user-testing-industry-report|access-date=2020-06-04|website=www.userfountain.com|language=en}}</ref>
शुरुआती चरण में, जब उपयोगकर्ताओं को तुरंत उन समस्याओं का सामना करना पड़ता है जो उन्हें अपने ट्रैक में रोकते हैं, सामान्य बुद्धि वाले लगभग किसी को भी परीक्षण विषय के रूप में इस्तेमाल किया जा सकता है। चरण दो में, परीक्षक क्षमताओं के व्यापक स्पेक्ट्रम में परीक्षण विषयों की भर्ती करेंगे। उदाहरण के लिए, एक अध्ययन में, अनुभवी उपयोगकर्ताओं ने पहली से आखिरी तक किसी भी डिज़ाइन का उपयोग करने में कोई समस्या नहीं दिखाई, जबकि भोले-भाले उपयोगकर्ता और स्वयं की पहचान वाले बिजली उपयोगकर्ता दोनों बार-बार विफल रहे।<ref>{{cite web|url=http://www.asktog.com/columns/000maxscrns.html|author=Bruce Tognazzini|title=Maximizing Windows}}</ref> बाद में, जैसा कि डिजाइन सुचारू हो जाता है, उपयोगकर्ताओं को लक्षित आबादी से भर्ती किया जाना चाहिए।


जब एक परियोजना के दौरान पर्याप्त संख्या में लोगों के लिए विधि लागू की जाती है, तो ऊपर उठाई गई आपत्तियां दूर हो जाती हैं: नमूना आकार छोटा होना बंद हो जाता है और उपयोगिता की समस्याएं जो केवल कभी-कभी उपयोगकर्ताओं के साथ उत्पन्न होती हैं। विधि का मूल्य इस तथ्य में निहित है कि एक बार सामने आने वाली विशिष्ट डिजाइन समस्याओं को फिर कभी नहीं देखा जाता है क्योंकि उन्हें तुरंत समाप्त कर दिया जाता है, जबकि जो भाग सफल दिखाई देते हैं उनका बार-बार परीक्षण किया जाता है। हालांकि यह सच है कि डिजाइन में शुरुआती समस्याओं का परीक्षण केवल पांच उपयोगकर्ताओं द्वारा किया जा सकता है, जब विधि को ठीक से लागू किया जाता है, तो उस प्रारंभिक परीक्षण में काम करने वाले डिजाइन के हिस्सों का परीक्षण 50 से 100 लोगों द्वारा किया जाएगा।
[[Image:Virzis Formula.PNG]]बाद के शोध में नीलसन के प्रभुत्व पर अनुभवजन्य साक्ष्य<ref>{{cite conference |last1=Spool |first1=Jared |last2=Schroeder |first2=Will |title=Testing web sites: five users is nowhere near enough |conference=CHI '01 extended abstracts on Human factors in computing systems |date=2001 |page=285 |doi=10.1145/634067.634236 |s2cid=8038786 }}</ref> और अधिक उन्नत गणितीय मॉडल दोनों का उपयोग करते हुए प्रश्न उठाया गया है।<ref>{{cite journal |last=Caulton |first=D. A. |title=उपयोगिता परीक्षण में एकरूपता धारणा को शिथिल करना|journal=Behaviour & Information Technology |year=2001 |volume=20 |issue=1 |pages=1–7 |doi=10.1080/01449290010020648 |s2cid=62751921 }}</ref> इस प्रभुत्व की दो प्रमुख चुनौतियाँ हैं:
# चूंकि उपयोगिता उपयोगकर्ताओं के विशिष्ट समूह से संबंधित है, इसलिए इस प्रकार के एक छोटे से नमूने का आकार कुल जनसंख्या का प्रतिनिधित्व करने की संभावना नहीं है, इसलिए इस प्रकार के एक छोटे से नमूने के डेटा की जनसंख्या की तुलना में नमूना समूह को प्रतिबिंबित करने की अधिक संभावना है।
# उपयोगिता की प्रत्येक समस्या को ज्ञात करना समान रूप से सुगम नहीं है। समग्र प्रक्रिया को धीमा करने के लिए असभ्य समस्याएं होती हैं। इन परिस्थितियों में, प्रक्रिया की प्रगति नीलसन/लैंडौयर सूत्र द्वारा भविष्यवाणी की तुलना में बहुत कम है।<ref>{{cite journal |last1=Schmettow |first1=Martin |title=प्रयोज्यता मूल्यांकन प्रक्रिया में विषमता|series=Electronic Workshops in Computing |date=1 September 2008 |doi=10.14236/ewic/HCI2008.9 |doi-access=free }}</ref>
यह ध्यान देने योग्य है कि नीलसन पांच उपयोगकर्ताओं के साथ एक परीक्षण के बाद रुकने की वकालत नहीं करता है; उनका कहना है कि पांच उपयोगकर्ताओं के साथ परीक्षण करना, उनके द्वारा अपूरित की गई समस्याओं को ठीक करना और फिर पांच अलग-अलग उपयोगकर्ताओं के साथ संशोधित स्थल का परीक्षण करना 10 उपयोगकर्ताओं के साथ एकल उपयोगिता परीक्षण चलाने की तुलना में सीमित संसाधनों का ठीक उपयोग है। अभ्यास में, परीक्षण पूरे विकास चक्र के समय प्रति सप्ताह एक या दो बार चलाया जाता है, प्रति चक्कर तीन से पांच परीक्षण विषयों का उपयोग करके, और परिणाम डिजाइनरों को 24 घंटे के भीतर वितरित किए जाते हैं। परियोजना के समय वास्तव में परीक्षण किए गए उपयोगकर्ताओं की संख्या इस प्रकार 50 से 100 लोगों तक सुगमता से पहुंच सकती है। अनुसंधान से ज्ञात होता है कि संगठनों द्वारा किए गए उपयोगकर्ता परीक्षण में सामान्यतः 5-10 प्रतिभागियों की भर्ती सम्मिलित होती है।<ref>{{Cite web|title=Results of the 2020 User Testing Industry Report|url=https://www.userfountain.com/results-of-the-2020-user-testing-industry-report|access-date=2020-06-04|website=www.userfountain.com|language=en}}</ref>
 
प्रारंभिक चरण में, जब उपयोगकर्ताओं को तुरंत उन समस्याओं का सामना करना पड़ता है जो उन्हें अपने रास्ते में रोकते हैं, सामान्य बुद्धि वाले लगभग किसी को भी परीक्षण विषय के रूप में उपयोग किया जा सकता है। चरण दो में, परीक्षक क्षमताओं के व्यापक वर्णक्रम में परीक्षण विषयों की भर्ती करेंगे। उदाहरण के लिए, एक अध्ययन में, अनुभवी उपयोगकर्ताओं ने प्रथम से अंतिम तक किसी भी डिज़ाइन का उपयोग करने में कोई समस्या नहीं दिखाई, जबकि निष्कपट उपयोगकर्ता और स्वयं की पहचान वाली शक्ति उपयोगकर्ता दोनों बार-बार विफल रहे।<ref>{{cite web|url=http://www.asktog.com/columns/000maxscrns.html|author=Bruce Tognazzini|title=Maximizing Windows}}</ref> बाद में, जैसा कि डिजाइन सुचारू हो जाता है, उपयोगकर्ताओं को लक्षित आबादी से भर्ती किया जाना चाहिए।
 
जब एक परियोजना के समय पर्याप्त संख्या में लोगों के लिए विधि लागू की जाती है, तो ऊपर उठाई गई आपत्तियां दूर हो जाती हैं: नमूना आकार छोटा होना बंद हो जाता है और उपयोगिता की समस्याएं जो मात्र कभी-कभी उपयोगकर्ताओं के साथ उत्पन्न होती हैं। विधि का मूल्य इस तथ्य में निहित है कि एक बार सामने आने वाली विशिष्ट डिजाइन समस्याओं को फिर कभी नहीं देखा जाता है क्योंकि उन्हें तुरंत समाप्त कर दिया जाता है, जबकि जो भाग सफल दिखाई देते हैं उनका बार-बार परीक्षण किया जाता है। यद्यपि यह सच है कि डिजाइन में प्रारंभिक समस्याओं का परीक्षण मात्र पांच उपयोगकर्ताओं द्वारा किया जा सकता है, जब विधि को ठीक से लागू किया जाता है, तो उस प्रारंभिक परीक्षण में कार्य करने वाले डिजाइन के भागों का परीक्षण 50 से 100 लोगों द्वारा किया जाएगा।


== उदाहरण ==
== उदाहरण ==
डेवलपर्स के लिए 1982 का Apple कंप्यूटर मैनुअल प्रयोज्य परीक्षण पर सलाह देता है:<ref name="apple1982">{{cite book|author1=Meyers, Joe|url=https://mirrors.apple2.org.za/ftp.apple.asimov.net/documentation/hardware/misc/Apple%20IIe%20Design%20Guidelines.pdf|title=Apple IIe डिज़ाइन दिशानिर्देश|author2=Tognazzini, Bruce|publisher=Apple Computer|year=1982|pages=11–13, 15}}</ref>
विकासक के लिए 1982 का एप्पल कंप्यूटर मैनुअल उपयोगिता परीक्षण पर सलाह देता है:<ref name="apple1982">{{cite book|author1=Meyers, Joe|url=https://mirrors.apple2.org.za/ftp.apple.asimov.net/documentation/hardware/misc/Apple%20IIe%20Design%20Guidelines.pdf|title=Apple IIe डिज़ाइन दिशानिर्देश|author2=Tognazzini, Bruce|publisher=Apple Computer|year=1982|pages=11–13, 15}}</ref>
# लक्षित दर्शकों का चयन करें। अपने लक्षित दर्शकों की पहचान करके अपना मानव इंटरफ़ेस डिज़ाइन शुरू करें। क्या आप व्यवसायियों या बच्चों के लिए लिख रहे हैं?
# लक्षित दर्शकों का चयन करें। अपने लक्षित दर्शकों की पहचान करके अपना मानव अंतरापृष्ठ डिज़ाइन प्रारम्भ करें। क्या आप व्यवसायियों या बच्चों के लिए लिख रहे हैं?
# निर्धारित करें कि लक्षित उपयोगकर्ता Apple कंप्यूटर और सॉफ़्टवेयर की विषय-वस्तु के बारे में कितना जानते हैं।
# निर्धारित करें कि लक्षित उपयोगकर्ता एप्पल कंप्यूटर और सॉफ़्टवेयर की विषय-वस्तु के विषय में कितना जानते हैं।
# चरण 1 और 2 लक्षित दर्शकों की आवश्यकताओं के अनुरूप यूजर इंटरफेस डिजाइन करने की अनुमति देते हैं। लेखाकारों के लिए लिखा गया कर-तैयारी सॉफ़्टवेयर यह मान सकता है कि इसके उपयोगकर्ता कंप्यूटर के बारे में कुछ नहीं जानते हैं, लेकिन कर कोड के विशेषज्ञ हैं, जबकि उपभोक्ताओं के लिए लिखे गए ऐसे सॉफ़्टवेयर यह मान सकते हैं कि इसके उपयोगकर्ता करों के बारे में कुछ नहीं जानते हैं, लेकिन Apple कंप्यूटर की मूल बातों से परिचित हैं।
# चरण 1 और 2 लक्षित दर्शकों की आवश्यकताओं के अनुरूप उपयोगकर्ता अंतरापृष्ठ डिजाइन करने की अनुमति देते हैं। लेखाकारों के लिए लिखा गया कर-सूत्रबद्धी सॉफ़्टवेयर यह मान सकता है कि इसके उपयोगकर्ता कंप्यूटर के विषय में कुछ नहीं जानते हैं, परंतु कर कोड के विशेषज्ञ हैं, जबकि उपभोक्ताओं के लिए लिखे गए ऐसे सॉफ़्टवेयर यह मान सकते हैं कि इसके उपयोगकर्ता करों के विषय में कुछ नहीं जानते हैं, परंतु एप्पल कंप्यूटर की मूल बातों से परिचित हैं।


Apple ने डेवलपर्स को सलाह दी, आपको ड्राफ्ट किए गए मित्रों, रिश्तेदारों और नए कर्मचारियों का उपयोग करके जल्द से जल्द परीक्षण शुरू करना चाहिए:{{r|apple1982}}
एप्पल ने विकासक को सलाह दी, आपको प्रारूप किए गए मित्रों, रिश्तेदारों और नवीन कर्मचारियों का उपयोग करके शीघ्रता से परीक्षण प्रारम्भ करना चाहिए:{{r|apple1982}}


{{quote|Our testing method is as follows. We set up a room with five to six computer systems. We schedule two to three groups of five to six users at a time to try out the systems (often without their knowing that it is the software rather than the system that we are testing). We have two of the designers in the room. Any fewer, and they miss a lot of what is going on. Any more and the users feel as though there is always someone breathing down their necks.}}
{{quote|हमारी परीक्षण विधि इस प्रकार है। हम पांच से छह कंप्यूटर प्रणाली के साथ एक कक्ष स्थापित करते हैं। हम प्रणाली को अवलोकन के लिए एक बार में पाँच से छह उपयोगकर्ताओं के दो से तीन समूहों को सूचीपत्र करते हैं (प्रायः बिना यह जाने कि यह उस प्रणाली के अतिरिक्त सॉफ़्टवेयर है जिसका हम परीक्षण कर रहे हैं)। हमारे समीप कक्ष में दो डिज़ाइनर हैं। कोई भी कम, और जो हो रहा है उसे बहुत याद करते हैं। और भी अधिक और उपयोगकर्ताओं को ऐसा लगता है कि कोई सदैव उनकी गर्दन के नीचे सांस ले रहा है।}}


डिजाइनरों को लोगों को व्यक्तिगत रूप से कार्यक्रम का उपयोग करते हुए देखना चाहिए, क्योंकि{{r|apple1982}}
डिजाइनरों को लोगों को व्यक्तिगत रूप से कार्यक्रम का उपयोग करते हुए देखना चाहिए, क्योंकि{{r|apple1982}}


{{quote|Ninety-five percent of the stumbling blocks are found by watching the body language of the users. Watch for squinting eyes, hunched shoulders, shaking heads, and deep, heart-felt sighs. When a user hits a snag, he will assume it is "on account of he is not too bright": he will not report it; he will hide it ... Do not make assumptions about why a user became confused. Ask him. You will often be surprised to learn what the user thought the program was doing at the time he got lost.}}
{{quote|पचानवे प्रतिशत ठोकरें उपयोगकर्ताओं के हाव भाव देखकर पाई जाती हैं। टेढ़ी-मेढ़ी आँखें, झुके हुए कंधे, हिलते हुए सिर, और गहरी, दिल को छू लेने वाली आहों पर ध्यान दें। जब कोई उपयोगकर्ता एक रोड़ा मारता है, तो वह मान लेगा कि "क्योंकि वह बहुत उज्ज्वल नहीं है": वह इसकी प्रतिवेदन नहीं करेगा; वह इसे छिपा देगा ... इस विषय में धारणा न बनाएं कि उपयोगकर्ता भ्रांत क्यों हो गया। उससे पूछो। आप प्रायः यह जानकर चकित रह जाएंगे कि उपयोगकर्ता ने सोचा था कि प्रोग्राम उस समय क्या कर रहा था जब वह खो गया था।}}


== शिक्षा ==
== शिक्षा ==
उपयोगिता परीक्षण विभिन्न विषयों में शैक्षणिक निर्देश का एक औपचारिक विषय रहा है।<ref>{{cite journal |last1=Breuch |first1=Lee-Ann M. Kastman |last2=Zachry |first2=Mark |last3=Spinuzzi |first3=Clay |title=Usability Instruction in Technical Communication Programs: New Directions in Curriculum Development |journal=Journal of Business and Technical Communication |date=April 2001 |volume=15 |issue=2 |pages=223–240 |doi=10.1177/105065190101500204 |s2cid=61365767 }}</ref> उपयोगिता परीक्षण संरचना अध्ययन और ऑनलाइन लेखन निर्देश (ओडब्ल्यूआई) के लिए महत्वपूर्ण है।<ref>{{cite journal |last1=Miller-Cochran |first1=Susan K. |last2=Rodrigo |first2=Rochelle L. |title=उपयोगिता परीक्षण के माध्यम से प्रभावी दूरस्थ शिक्षा डिजाइनों का निर्धारण|journal=Computers and Composition |date=January 2006 |volume=23 |issue=1 |pages=91–107 |doi=10.1016/j.compcom.2005.12.002 }}</ref> विद्वान कॉलिन ब्योर्क का तर्क है कि प्रयोज्य परीक्षण आवश्यक है लेकिन प्रभावी OWI विकसित करने के लिए अपर्याप्त है, जब तक कि यह [[डिजिटल बयानबाजी]] के सिद्धांतों के साथ भी नहीं जोड़ा जाता है।<ref>{{cite journal |last1=Bjork |first1=Collin |title=OWI में डिजिटल रेटोरिक के साथ उपयोगिता परीक्षण को एकीकृत करना|journal=Computers and Composition |date=September 2018 |volume=49 |pages=4–13 |doi=10.1016/j.compcom.2018.05.009 |s2cid=196160668 }}</ref>
उपयोगिता परीक्षण विभिन्न विषयों में शैक्षणिक निर्देश का एक औपचारिक विषय रहा है।<ref>{{cite journal |last1=Breuch |first1=Lee-Ann M. Kastman |last2=Zachry |first2=Mark |last3=Spinuzzi |first3=Clay |title=Usability Instruction in Technical Communication Programs: New Directions in Curriculum Development |journal=Journal of Business and Technical Communication |date=April 2001 |volume=15 |issue=2 |pages=223–240 |doi=10.1177/105065190101500204 |s2cid=61365767 }}</ref> उपयोगिता परीक्षण संरचना अध्ययन और ऑनलाइन लेखन निर्देश(ओडब्ल्यूआई) के लिए महत्वपूर्ण है।<ref>{{cite journal |last1=Miller-Cochran |first1=Susan K. |last2=Rodrigo |first2=Rochelle L. |title=उपयोगिता परीक्षण के माध्यम से प्रभावी दूरस्थ शिक्षा डिजाइनों का निर्धारण|journal=Computers and Composition |date=January 2006 |volume=23 |issue=1 |pages=91–107 |doi=10.1016/j.compcom.2005.12.002 }}</ref> विद्वान कॉलिन ब्योर्क का तर्क है कि उपयोगिता परीक्षण आवश्यक है परंतु प्रभावी ओडब्ल्यूआई विकसित करने के लिए अपर्याप्त है, जब तक कि यह [[डिजिटल बयानबाजी]] के सिद्धांतों के साथ भी नहीं जोड़ा जाता है।<ref>{{cite journal |last1=Bjork |first1=Collin |title=OWI में डिजिटल रेटोरिक के साथ उपयोगिता परीक्षण को एकीकृत करना|journal=Computers and Composition |date=September 2018 |volume=49 |pages=4–13 |doi=10.1016/j.compcom.2018.05.009 |s2cid=196160668 }}</ref>




Line 94: Line 99:
* [[शैक्षिक प्रौद्योगिकी]]
* [[शैक्षिक प्रौद्योगिकी]]
* [[सार्वभौमिक उपयोगिता]]
* [[सार्वभौमिक उपयोगिता]]
* [[कमर्शियल आई ट्रैकिंग]]
* [[वाणिज्यिक आँख मार्गन]]
* मुझे मत सोचो
* डोंट मेक में  थिंक
* [[सॉफ्टवेयर प्रदर्शन परीक्षण]]
* [[सॉफ्टवेयर प्रदर्शन परीक्षण]]
* [[सिस्टम उपयोगिता स्केल]] | सिस्टम उपयोगिता स्केल (SUS)
* [[पद्धति उपयोगिता परिमाण]] | सिस्टम उपयोगिता स्केल (SUS)
* [[परिक्षण विधि]]
* [[परिक्षण विधि]]
* [[वृक्ष परीक्षण (सूचना वास्तुकला)]]
* [[ट्री परीक्षण (सूचना वास्तुकला)]]
* [[राइट विधि]]
* [[राइट विधि]]
* [[घटक-आधारित उपयोगिता परीक्षण]]
* [[घटक-आधारित उपयोगिता परीक्षण]]
* [[ क्राउडसोर्स्ड परीक्षण ]]
* [[ भीड़ से एकत्रित परीक्षण ]]
* प्रयोज्य लक्ष्य
* प्रयोज्य लक्ष्य
* अनुमानी मूल्यांकन
* अनुमानी मूल्यांकन
Line 120: Line 125:
     See Talk, WP:EL, and WP:SPAM for more information.
     See Talk, WP:EL, and WP:SPAM for more information.
     Wikipedia is not a link directory.  Consider submitting your link to DMOZ instead.
     Wikipedia is not a link directory.  Consider submitting your link to DMOZ instead.
-->


{{Product testing}}
{{Software testing}}


{{DEFAULTSORT:Usability Testing}}[[Category: प्रयोज्य]] [[Category: सॉफ़्टवेयर परीक्षण]] [[Category: शैक्षिक प्रौद्योगिकी]] [[Category: उत्पाद का परीक्षण करना]]






[[Category: Machine Translated Page]]
 
[[Category:Created On 25/02/2023]]
 
 
 
 
-->
 
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:CS1 English-language sources (en)]]
[[Category:CS1 errors]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Multi-column templates]]
[[Category:Pages using div col with small parameter]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Templates using under-protected Lua modules]]
[[Category:Wikipedia fully protected templates|Div col]]

Latest revision as of 11:16, 10 March 2023

उपयोगिता परीक्षण उपयोगकर्ता-केंद्रित डिज़ाइन में उपयोग की जाने वाली एक तकनीक है | उपयोगकर्ता-केंद्रित पारस्परिक प्रभाव वाली डिज़ाइन उपयोगकर्ताओं पर परीक्षण करके किसी उत्पाद का मूल्यांकन करने के लिए उपयोग किया जाता है। इसे एक अपूरणीय उपयोगिता अभ्यास के रूप में देखा जा सकता है, क्योंकि यह प्रत्यक्ष निवेश देता है कि वास्तविक उपयोगकर्ता पद्धति का उपयोग कैसे करते हैं।[1] यह उत्पाद की डिजाइन सहजता से अधिक चिंतित है और उन उपयोगकर्ताओं के साथ परीक्षण किया गया है जिनके समीप इसका कोई पूर्व अनुभव नहीं है। इस प्रकार का परीक्षण एक अंतिम उत्पाद की सफलता के लिए सर्वोपरि है क्योंकि पूर्ण रूप से कार्य करने वाला अनुप्रयोग जो अपने उपयोगकर्ताओं के बीच विभ्रान्ति उत्पन्न करता है वह लंबे समय तक नहीं चलेगा।[2] यह उपयोगिता निरीक्षण विधियों के विपरीत है जहां विशेषज्ञ उपयोगकर्ताओं को सम्मिलित किए बिना उपयोगकर्ता अंतरापृष्ठ का मूल्यांकन करने के लिए विभिन्न विधियों का उपयोग करते हैं।

उपयोगिता परीक्षण मानव निर्मित उत्पाद की उसके इच्छित उद्देश्यों को पूर्ण करने की क्षमता को मापने पर केंद्रित है। उत्पादों के उदाहरण जो सामान्यतः उपयोगिता परीक्षण से लाभान्वित होते हैं, वे हैं भोजन, उपभोक्ता उत्पाद, वेबसाइट या वेब एप्लिकेशन, उपयोगकर्ता अंतरापृष्ठ, दस्तावेज़ और उपकरण। उपयोगिता परीक्षण किसी विशिष्ट वस्तु या वस्तुओं के समूह की उपयोगिता, या उपयोग में सुगमता को मापता है, जबकि सामान्य मानव-कंप्यूटर अन्योन्यक्रिया अध्ययन सार्वभौमिक सिद्धांतों को सूत्रबद्ध करने का प्रयत्न करते हैं।

यह क्या नहीं है

किसी वस्तु या दस्तावेज़ पर मात्र विचार एकत्र करना उपयोगिता परीक्षण के अतिरिक्त बाजार अनुसंधान या गुणात्मक शोध है। उपयोगिता परीक्षण में सामान्यतः नियंत्रित परिस्थितियों में व्यवस्थित अवलोकन सम्मिलित होता है ताकि यह निर्धारित किया जा सके कि लोग उत्पाद का कितना ठीक रूप से उपयोग कर सकते हैं।[3] यद्यपि, प्रायः गुणात्मक शोध और उपयोगिता परीक्षण दोनों का संयोजन में उपयोग किया जाता है, ताकि उनके कार्यों के अतिरिक्त, उपयोगकर्ताओं की प्रेरणा/धारणाओं को ठीक रूप से समझा जा सके।

उपयोगकर्ताओं को एक अपूर्ण प्रारूप दिखाने और पूछने के अतिरिक्त, क्या आप इसे समझते हैं? उपयोगिता परीक्षण में लोगों को इसके इच्छित उद्देश्य के लिए कुछ उपयोग करने की प्रयत्न करना सम्मिलित है। उदाहरण के लिए, जब किसी खिलौने को कोडांतरण करने के लिए परीक्षण निर्देश दिए जाते हैं, तो परीक्षण विषयों को निर्देश और भागों का एक डिब्बा दिया जाना चाहिए और भागों और पदार्थों पर टिप्पणी करने के लिए कहने के अतिरिक्त, उन्हें खिलौने को एक साथ रखने के लिए कहा जाना चाहिए। निर्देश वाक्यांश, चित्रण गुणवत्ता, और खिलौने के डिज़ाइन सभी कोडांतरणी प्रक्रिया को प्रभावित करते हैं।

विधियां

उपयोगिता परीक्षण की स्थापना में सावधानीपूर्वक एक परिदृश्य, या एक यथार्थवादी स्थिति बनाना सम्मिलित है, जिसमें व्यक्ति गतिशील परीक्षण वाले उत्पाद का उपयोग करते हुए कार्यों की एक सूची करता है, जबकि पर्यवेक्षक देखते हैं और टिप्पणियाँ लेते हैं(सॉफ़्टवेयर सत्यापन)। कई अन्य स्थिर परीक्षण उपकरण जैसे लिखित निर्देश, दस्तावेज़ प्रोटोटाइप, और पूर्व- और पद-परीक्षण प्रश्नावली का भी परीक्षण किए जा रहे उत्पाद पर प्रतिक्रिया एकत्र करने के लिए उपयोग किया जाता है(सॉफ़्टवेयर सत्यापन)। उदाहरण के लिए, एक ईमेल प्रोग्राम के आसक्ति कार्य का परीक्षण करने के लिए, एक परिदृश्य उस स्थिति का वर्णन करेगा जहां एक व्यक्ति को एक ई-मेल आसक्ति भेजने की आवश्यकता होती है, और उन्हें यह कार्य करने के लिए कहा जाता है। इसका उद्देश्य यह देखना है कि लोग यथार्थवादी विधि से कैसे कार्य करते हैं, ताकि विकासक समस्या वाले क्षेत्रों की पहचान कर सकें और उन्हें ठीक कर सकें। उपयोगिता परीक्षण के समय डेटा एकत्र करने के लिए लोकप्रिय तकनीकों में ज़ोर से सोचो प्रोटोकॉल, सह खोज अधिगम और आँख मार्गन सम्मिलित हैं।

दालान परीक्षण

दालान परीक्षण, जिसे गुरिल्ला उपयोगिता के रूप में भी जाना जाता है, उपयोगिता परीक्षण का एक त्वरित और सस्ती विधि है जिसमें लोग - जैसे कि दालान में गुजरने वालों - को उत्पाद या सेवा का उपयोग करने का प्रयत्न करने के लिए कहा जाता है। यह डिजाइनरों को ईंट की दीवारों की पहचान करने में सहायता कर सकता है, समस्याएं इतनी गंभीर हैं कि उपयोगकर्ता नवीन डिजाइन के प्रारंभिक चरणों में सुगमता से आगे नहीं बढ़ सकते हैं। परियोजना डिजाइनरों और इंजीनियरों के अतिरिक्त कोई भी उपयोग किया जा सकता है(वे विशेषज्ञ समीक्षक के रूप में कार्य करते हैं क्योंकि वे परियोजना के बहुत समीप हैं)।

इस प्रकार का परीक्षण सुविधा नमूनाकरण का एक उदाहरण है और इस प्रकार परिणाम संभावित रूप से पक्षपाती हैं।

दूरस्थ उपयोगिता परीक्षण

ऐसे परिदृश्य में जहां उपयोगिता मूल्यांकनकर्ता, विकासकर्ता और संभावित उपयोगकर्ता विभिन्न देशों और समय क्षेत्रों में स्थित हैं, एक परंपरागत प्रयोगशाला उपयोगिता मूल्यांकन का आयोजन लागत और संभार तंत्र दोनों दृष्टिकोणों से चुनौतियां उत्पन्न करते है। इन चिंताओं ने दूरस्थ उपयोगिता मूल्यांकन पर शोध किया, उपयोगकर्ता और मूल्यांकनकर्ता अंतरिक्ष और समय से अलग हो गए। दूरस्थ परीक्षण, जो उपयोगकर्ता के अन्य कार्यों और प्रौद्योगिकी के संदर्भ में किए जा रहे मूल्यांकन को सुगम बनाते है, या तो तुल्यकालिक या अतुल्यकालिक हो सकता है। पूर्व में मूल्यांकनकर्ता और उपयोगकर्ता के बीच वास्तविक समय पर एक-एक संचार सम्मिलित होता है, जबकि बाद में मूल्यांकनकर्ता और उपयोगकर्ता अलग-अलग कार्य करते हैं।[4] इन दोनों विधियों की आवश्यकताओं को पूर्ण करने के लिए कई उपकरण उपलब्ध हैं।

तुल्यकालिक उपयोगिता परीक्षण पद्धति में वीडियो कॉन्फ्रेंसिंग सम्मिलित है या वेबएक्स जैसे दूरस्थ एप्लिकेशन साझाकरण उपकरण को नियोजित करता है। वेबएक्स और गोटूमीटिंग समकालिक दूरस्थ उपयोगिता परीक्षण करने के लिए सबसे अधिक उपयोग की जाने वाली तकनीकें हैं।[5] यद्यपि, तुल्यकालिक दूरस्थ परीक्षण में सहयोगी परीक्षण प्रक्रिया का समर्थन करने के लिए वांछित उपस्थिति और उपस्थिति की भावना की कमी हो सकती है। इसके अतिरिक्त, सांस्कृतिक और भाषाई बाधाओं के पार पारस्परिक गतिशीलता का प्रबंधन करने के लिए सम्मिलित संस्कृतियों के प्रति संवेदनशील दृष्टिकोण की आवश्यकता हो सकती है। अन्य क्षतियों में परीक्षण वातावरण पर कम नियंत्रण और प्रतिभागियों द्वारा अपने मूल वातावरण में अनुभव किए गए विक्षेप और रुकावट सम्मिलित हैं।[6] आभासी संसार का उपयोग करके एक तुल्यकालिक दूरस्थ उपयोगिता परीक्षण करने के लिए विकसित नवीन विधियों में से एक है।[7]

अतुल्यकालिक पद्धतियों में उपयोगकर्ता की क्लिक स्ट्रीम का स्वत: संग्रह, महत्वपूर्ण घटनाओं के उपयोगकर्ता लॉग सम्मिलित होते हैं जो एप्लिकेशन के साथ अन्योन्यक्रिया करते समय होते हैं और उपयोगकर्ताओं द्वारा अंतरापृष्ठ पर व्यक्तिपरक प्रतिक्रिया होती है।[6] प्रयोगशाला में अध्ययन के समान, एक अतुल्यकालिक दूरस्थ उपयोगिता परीक्षण कार्य-आधारित है और प्लेटफ़ॉर्म शोधकर्ताओं को क्लिक और कार्य समय पर आधिपत्य करने की अनुमति देता है। इसलिए, कई बड़ी कंपनियों के लिए, यह शोधकर्ताओं को किसी वेबसाइट या मोबाइल साइट पर जाने पर आगंतुकों के विचारों को ठीक रूप से समझने की अनुमति देता है। इसके अतिरिक्त, उपयोगकर्ता परीक्षण की यह शैली जनसांख्यिकीय, व्यवहारिक और व्यवहारिक प्रकार से प्रतिपुष्टि को विभाजित करने का अवसर भी प्रदान करती है। परीक्षण उपयोगकर्ता के अपने वातावरण(प्रयोगशालाओं के अतिरिक्त) में किए जाते हैं जो वास्तविक जीवन परिदृश्य परीक्षण को आगे बढ़ाने में सहायता करते हैं। यह दृष्टिकोण दूरदराज के क्षेत्रों में उपयोगकर्ताओं से सुगमता से और कम संगठनात्मक उपरिव्यय के साथ सुगमता से प्रतिपुष्टि मांगने के लिए एक वाहन प्रदान करता है। आधुनिक वर्षों में, समकालिक रूप से उपयोगिता परीक्षण आयोजित करना भी प्रचलित हो गया है और परीक्षकों को अपने रिक्त समय में और अपने घर के आराम से प्रतिक्रिया प्रदान करने की अनुमति देता है।

विशेषज्ञ समीक्षा

उपयोगिता परीक्षण का एक अन्य सामान्य विधि विशेषज्ञ समीक्षा है। जैसा कि नाम से ज्ञात होता है, यह विधि किसी उत्पाद की उपयोगिता का मूल्यांकन करने के लिए क्षेत्र में अनुभव वाले विशेषज्ञों(संभवतः उन कंपनियों से जो उपयोगिता परीक्षण में विशेषज्ञ हैं) को लाने पर निर्भर करती है।

एक अनुमानी मूल्यांकन या उपयोगिता लेखापरीक्षा एक या अधिक मानव कारक विशेषज्ञों द्वारा एक अंतरापृष्ठ का मूल्यांकन है। मूल्यांकनकर्ता उपयोगिता सिद्धांतों के आधार पर अंतरापृष्ठ की उपयोगिता, दक्षता और प्रभावशीलता को मापते हैं, जैसे कि 1994 में जैकब नीलसन(उपयोगिता सलाहकार) द्वारा मूल रूप से परिभाषित 10 उपयोगिता अनुमान।[8]

नीलसन की उपयोगिता अनुमान, जो उपयोगकर्ता अनुसंधान और नवीन उपकरणों की प्रतिक्रिया में विकसित होना जारी है, में सम्मिलित हैं:

  • पद्धति स्थिति की दृश्यता
  • प्रणाली और वास्तविक संसार के बीच मेल
  • उपयोगकर्ता नियंत्रण और स्वतंत्रता
  • संगति और मानक
  • त्रुटि निवारण
  • याद करने के अतिरिक्त पहचान
  • लचीलापन और उपयोग की दक्षता
  • सौंदर्य और न्यूनतम डिजाइन
  • उपयोगकर्ताओं को त्रुटियों को पहचानने, निदान करने और पुनर्प्राप्त करने में सहायता करें
  • सहायता और दस्तावेज

स्वचालित विशेषज्ञ समीक्षा

विशेषज्ञ समीक्षाओं के समान, स्वचालित विशेषज्ञ समीक्षाएं उपयोगिता परीक्षण प्रदान करती हैं, परंतु कार्यक्रमों के उपयोग के माध्यम से अच्छे डिजाइन और अनुमानी के लिए नियम दिए गए हैं। यद्यपि एक स्वचालित समीक्षा लोगों की समीक्षाओं के रूप में अधिक विवरण और अंतर्दृष्टि प्रदान नहीं कर सकती है, परंतु उन्हें अधिक तीव्रता से और निरंतर समाप्त किया जा सकता है। उपयोगिता परीक्षण के लिए प्रतिनिधि उपयोगकर्ता बनाने का विचार कृत्रिम बुद्धिमत्ता समुदाय के लिए एक महत्वाकांक्षी दिशा है।

ए/बी परीक्षण

वेब विकास और विपणन में, ए/बी परिक्षण या स्प्लिट परिक्षण वेब डिज़ाइन(विशेष रूप से उपयोगकर्ता अनुभव डिज़ाइन) के लिए एक प्रायोगिक दृष्टिकोण है, जिसका उद्देश्य उन वेब पेजों में परिवर्तनों की पहचान करना है जो रुचि के परिणाम को बढ़ाते हैं या अधिकतम करते हैं(जैसे, क्लिक-थ्रू दर) एक बैनर विज्ञापन के लिए)। जैसा कि नाम से ज्ञात होता है, दो संस्करणों(ए और बी) की तुलना की जाती है, जो एक भिन्नता को छोड़कर समान हैं जो उपयोगकर्ता के गतिविधि को प्रभावित कर सकती हैं। संस्करण ए वर्तमान में उपयोग किया जाने वाला संस्करण हो सकता है, जबकि संस्करण बी को कुछ विषयों में संशोधित किया गया है। उदाहरण के लिए, ई-कॉमर्स वेबसाइट पर खरीद कीप सामान्यतः ए/बी परीक्षण के लिए एक अच्छा उम्मीदवार है, क्योंकि कम दरों में सामान्य सुधार भी बिक्री में महत्वपूर्ण लाभ का प्रतिनिधित्व कर सकता है। कॉपी टेक्स्ट, लेआउट, प्रतिरूप और रंगों जैसे परीक्षण अवयवों के माध्यम से महत्वपूर्ण सुधार देखे जा सकते हैं।

बहुभिन्नरूपी परीक्षण या डोल परीक्षण ए/बी परीक्षण के समान है परंतु एक ही समय में दो से अधिक संस्करणों का परीक्षण करता है।

प्रतिभागियों की संख्या

1990 के दशक की प्रारंभ में, जैकब नीलसन(उपयोगिता सलाहकार), उस समय सन मिक्रोसिस्टम्स के एक शोधकर्ता ने विकास प्रक्रिया के विभिन्न चरणों में कई छोटे उपयोगिता परीक्षणों का उपयोग करने की अवधारणा को लोकप्रिय बनाया- सामान्यतः मात्र पांच प्रतिभागियों के साथ। उनका तर्क यह है कि, एक बार जब यह पाया जाता है कि दो या तीन लोग होम पेज से पूर्ण रूप से अस्पष्ट हैं, तो अधिक लोगों को एक ही त्रुटिपूर्ण डिजाइन के माध्यम से पीड़ित देखकर बहुत कम लाभ होता है। विस्तृत उपयोगिता परीक्षण संसाधनों की बर्बादी है। सबसे अच्छे परिणाम पांच से अधिक उपयोगकर्ताओं के परीक्षण से आते हैं और आप जितने छोटे परीक्षण कर सकते हैं उतने छोटे परीक्षण चला सकते हैं।[9]

पांच उपयोगकर्ताओं का प्रभुत्व अत्यधिक है बाद में एक गणितीय मॉडल द्वारा वर्णित किया गया था[10] जो अपूरित समस्याओं के अनुपात के लिए बताता है यू

जहां p एक विशिष्ट समस्या की पहचान करने वाले एक विषय की संभावना है और n विषयों की संख्या(या परीक्षण सत्र)। यह मॉडल वास्तविक वर्तमान समस्याओं की संख्या के लिए एक स्पर्शोन्मुख ग्राफ के रूप में दिखाई देता है(नीचे चित्र देखें)।

Virzis Formula.PNGबाद के शोध में नीलसन के प्रभुत्व पर अनुभवजन्य साक्ष्य[11] और अधिक उन्नत गणितीय मॉडल दोनों का उपयोग करते हुए प्रश्न उठाया गया है।[12] इस प्रभुत्व की दो प्रमुख चुनौतियाँ हैं:

  1. चूंकि उपयोगिता उपयोगकर्ताओं के विशिष्ट समूह से संबंधित है, इसलिए इस प्रकार के एक छोटे से नमूने का आकार कुल जनसंख्या का प्रतिनिधित्व करने की संभावना नहीं है, इसलिए इस प्रकार के एक छोटे से नमूने के डेटा की जनसंख्या की तुलना में नमूना समूह को प्रतिबिंबित करने की अधिक संभावना है।
  2. उपयोगिता की प्रत्येक समस्या को ज्ञात करना समान रूप से सुगम नहीं है। समग्र प्रक्रिया को धीमा करने के लिए असभ्य समस्याएं होती हैं। इन परिस्थितियों में, प्रक्रिया की प्रगति नीलसन/लैंडौयर सूत्र द्वारा भविष्यवाणी की तुलना में बहुत कम है।[13]

यह ध्यान देने योग्य है कि नीलसन पांच उपयोगकर्ताओं के साथ एक परीक्षण के बाद रुकने की वकालत नहीं करता है; उनका कहना है कि पांच उपयोगकर्ताओं के साथ परीक्षण करना, उनके द्वारा अपूरित की गई समस्याओं को ठीक करना और फिर पांच अलग-अलग उपयोगकर्ताओं के साथ संशोधित स्थल का परीक्षण करना 10 उपयोगकर्ताओं के साथ एकल उपयोगिता परीक्षण चलाने की तुलना में सीमित संसाधनों का ठीक उपयोग है। अभ्यास में, परीक्षण पूरे विकास चक्र के समय प्रति सप्ताह एक या दो बार चलाया जाता है, प्रति चक्कर तीन से पांच परीक्षण विषयों का उपयोग करके, और परिणाम डिजाइनरों को 24 घंटे के भीतर वितरित किए जाते हैं। परियोजना के समय वास्तव में परीक्षण किए गए उपयोगकर्ताओं की संख्या इस प्रकार 50 से 100 लोगों तक सुगमता से पहुंच सकती है। अनुसंधान से ज्ञात होता है कि संगठनों द्वारा किए गए उपयोगकर्ता परीक्षण में सामान्यतः 5-10 प्रतिभागियों की भर्ती सम्मिलित होती है।[14]

प्रारंभिक चरण में, जब उपयोगकर्ताओं को तुरंत उन समस्याओं का सामना करना पड़ता है जो उन्हें अपने रास्ते में रोकते हैं, सामान्य बुद्धि वाले लगभग किसी को भी परीक्षण विषय के रूप में उपयोग किया जा सकता है। चरण दो में, परीक्षक क्षमताओं के व्यापक वर्णक्रम में परीक्षण विषयों की भर्ती करेंगे। उदाहरण के लिए, एक अध्ययन में, अनुभवी उपयोगकर्ताओं ने प्रथम से अंतिम तक किसी भी डिज़ाइन का उपयोग करने में कोई समस्या नहीं दिखाई, जबकि निष्कपट उपयोगकर्ता और स्वयं की पहचान वाली शक्ति उपयोगकर्ता दोनों बार-बार विफल रहे।[15] बाद में, जैसा कि डिजाइन सुचारू हो जाता है, उपयोगकर्ताओं को लक्षित आबादी से भर्ती किया जाना चाहिए।

जब एक परियोजना के समय पर्याप्त संख्या में लोगों के लिए विधि लागू की जाती है, तो ऊपर उठाई गई आपत्तियां दूर हो जाती हैं: नमूना आकार छोटा होना बंद हो जाता है और उपयोगिता की समस्याएं जो मात्र कभी-कभी उपयोगकर्ताओं के साथ उत्पन्न होती हैं। विधि का मूल्य इस तथ्य में निहित है कि एक बार सामने आने वाली विशिष्ट डिजाइन समस्याओं को फिर कभी नहीं देखा जाता है क्योंकि उन्हें तुरंत समाप्त कर दिया जाता है, जबकि जो भाग सफल दिखाई देते हैं उनका बार-बार परीक्षण किया जाता है। यद्यपि यह सच है कि डिजाइन में प्रारंभिक समस्याओं का परीक्षण मात्र पांच उपयोगकर्ताओं द्वारा किया जा सकता है, जब विधि को ठीक से लागू किया जाता है, तो उस प्रारंभिक परीक्षण में कार्य करने वाले डिजाइन के भागों का परीक्षण 50 से 100 लोगों द्वारा किया जाएगा।

उदाहरण

विकासक के लिए 1982 का एप्पल कंप्यूटर मैनुअल उपयोगिता परीक्षण पर सलाह देता है:[16]

  1. लक्षित दर्शकों का चयन करें। अपने लक्षित दर्शकों की पहचान करके अपना मानव अंतरापृष्ठ डिज़ाइन प्रारम्भ करें। क्या आप व्यवसायियों या बच्चों के लिए लिख रहे हैं?
  2. निर्धारित करें कि लक्षित उपयोगकर्ता एप्पल कंप्यूटर और सॉफ़्टवेयर की विषय-वस्तु के विषय में कितना जानते हैं।
  3. चरण 1 और 2 लक्षित दर्शकों की आवश्यकताओं के अनुरूप उपयोगकर्ता अंतरापृष्ठ डिजाइन करने की अनुमति देते हैं। लेखाकारों के लिए लिखा गया कर-सूत्रबद्धी सॉफ़्टवेयर यह मान सकता है कि इसके उपयोगकर्ता कंप्यूटर के विषय में कुछ नहीं जानते हैं, परंतु कर कोड के विशेषज्ञ हैं, जबकि उपभोक्ताओं के लिए लिखे गए ऐसे सॉफ़्टवेयर यह मान सकते हैं कि इसके उपयोगकर्ता करों के विषय में कुछ नहीं जानते हैं, परंतु एप्पल कंप्यूटर की मूल बातों से परिचित हैं।

एप्पल ने विकासक को सलाह दी, आपको प्रारूप किए गए मित्रों, रिश्तेदारों और नवीन कर्मचारियों का उपयोग करके शीघ्रता से परीक्षण प्रारम्भ करना चाहिए:[16]

हमारी परीक्षण विधि इस प्रकार है। हम पांच से छह कंप्यूटर प्रणाली के साथ एक कक्ष स्थापित करते हैं। हम प्रणाली को अवलोकन के लिए एक बार में पाँच से छह उपयोगकर्ताओं के दो से तीन समूहों को सूचीपत्र करते हैं (प्रायः बिना यह जाने कि यह उस प्रणाली के अतिरिक्त सॉफ़्टवेयर है जिसका हम परीक्षण कर रहे हैं)। हमारे समीप कक्ष में दो डिज़ाइनर हैं। कोई भी कम, और जो हो रहा है उसे बहुत याद करते हैं। और भी अधिक और उपयोगकर्ताओं को ऐसा लगता है कि कोई सदैव उनकी गर्दन के नीचे सांस ले रहा है।

डिजाइनरों को लोगों को व्यक्तिगत रूप से कार्यक्रम का उपयोग करते हुए देखना चाहिए, क्योंकि[16]

पचानवे प्रतिशत ठोकरें उपयोगकर्ताओं के हाव भाव देखकर पाई जाती हैं। टेढ़ी-मेढ़ी आँखें, झुके हुए कंधे, हिलते हुए सिर, और गहरी, दिल को छू लेने वाली आहों पर ध्यान दें। जब कोई उपयोगकर्ता एक रोड़ा मारता है, तो वह मान लेगा कि "क्योंकि वह बहुत उज्ज्वल नहीं है": वह इसकी प्रतिवेदन नहीं करेगा; वह इसे छिपा देगा ... इस विषय में धारणा न बनाएं कि उपयोगकर्ता भ्रांत क्यों हो गया। उससे पूछो। आप प्रायः यह जानकर चकित रह जाएंगे कि उपयोगकर्ता ने सोचा था कि प्रोग्राम उस समय क्या कर रहा था जब वह खो गया था।

शिक्षा

उपयोगिता परीक्षण विभिन्न विषयों में शैक्षणिक निर्देश का एक औपचारिक विषय रहा है।[17] उपयोगिता परीक्षण संरचना अध्ययन और ऑनलाइन लेखन निर्देश(ओडब्ल्यूआई) के लिए महत्वपूर्ण है।[18] विद्वान कॉलिन ब्योर्क का तर्क है कि उपयोगिता परीक्षण आवश्यक है परंतु प्रभावी ओडब्ल्यूआई विकसित करने के लिए अपर्याप्त है, जब तक कि यह डिजिटल बयानबाजी के सिद्धांतों के साथ भी नहीं जोड़ा जाता है।[19]


यह भी देखें

संदर्भ

  1. Nielsen, J. (1994). Usability Engineering, Academic Press Inc, p 165
  2. Mejs, Monika (2019-06-27). "Usability Testing: the Key to Design Validation". Mood Up team - software house (in English). Retrieved 2019-09-11.
  3. Dennis G. Jerz (July 19, 2000). "Usability Testing: What Is It?". Jerz's Literacy Weblog. Retrieved June 29, 2016.
  4. Andreasen, Morten Sieker; Nielsen, Henrik Villemann; Schrøder, Simon Ormholt; Stage, Jan (2007). "What happened to remote usability testing?". कंप्यूटिंग सिस्टम में मानव कारक पर SIGCHI सम्मेलन की कार्यवाही. p. 1405. doi:10.1145/1240624.1240838. ISBN 978-1-59593-593-9. S2CID 12388042.
  5. Dabney Gough; Holly Phillips (2003-06-09). "Remote Online Usability Testing: Why, How, and When to Use It". Archived from the original on December 15, 2005.
  6. 6.0 6.1 Dray, Susan; Siegel, David (March 2004). "Remote possibilities?: international usability testing at a distance". Interactions. 11 (2): 10–17. doi:10.1145/971258.971264. S2CID 682010.
  7. Chalil Madathil, Kapil; Greenstein, Joel S. (2011). "Synchronous remote usability testing". कंप्यूटिंग सिस्टम में मानव कारक पर SIGCHI सम्मेलन की कार्यवाही. pp. 2225–2234. doi:10.1145/1978942.1979267. ISBN 978-1-4503-0228-9. S2CID 14077658.
  8. "अनुमानी मूल्यांकन". Usability First. Retrieved April 9, 2013.
  9. "Usability Testing with 5 Users (Jakob Nielsen's Alertbox)". useit.com. 2000-03-13.; references Nielsen, Jakob; Landauer, Thomas K. (1993). "A mathematical model of the finding of usability problems". Proceedings of the SIGCHI conference on Human factors in computing systems. pp. 206–213. doi:10.1145/169059.169166. ISBN 978-0-89791-575-5. S2CID 207177537.
  10. Virzi, R. A. (1992). "Refining the Test Phase of Usability Evaluation: How Many Subjects is Enough?". Human Factors. 34 (4): 457–468. doi:10.1177/001872089203400407. S2CID 59748299.
  11. Spool, Jared; Schroeder, Will (2001). Testing web sites: five users is nowhere near enough. CHI '01 extended abstracts on Human factors in computing systems. p. 285. doi:10.1145/634067.634236. S2CID 8038786.
  12. Caulton, D. A. (2001). "उपयोगिता परीक्षण में एकरूपता धारणा को शिथिल करना". Behaviour & Information Technology. 20 (1): 1–7. doi:10.1080/01449290010020648. S2CID 62751921.
  13. Schmettow, Martin (1 September 2008). "प्रयोज्यता मूल्यांकन प्रक्रिया में विषमता". Electronic Workshops in Computing. doi:10.14236/ewic/HCI2008.9. {{cite journal}}: Cite journal requires |journal= (help)
  14. "Results of the 2020 User Testing Industry Report". www.userfountain.com (in English). Retrieved 2020-06-04.
  15. Bruce Tognazzini. "Maximizing Windows".
  16. 16.0 16.1 16.2 Meyers, Joe; Tognazzini, Bruce (1982). Apple IIe डिज़ाइन दिशानिर्देश (PDF). Apple Computer. pp. 11–13, 15.
  17. Breuch, Lee-Ann M. Kastman; Zachry, Mark; Spinuzzi, Clay (April 2001). "Usability Instruction in Technical Communication Programs: New Directions in Curriculum Development". Journal of Business and Technical Communication. 15 (2): 223–240. doi:10.1177/105065190101500204. S2CID 61365767.
  18. Miller-Cochran, Susan K.; Rodrigo, Rochelle L. (January 2006). "उपयोगिता परीक्षण के माध्यम से प्रभावी दूरस्थ शिक्षा डिजाइनों का निर्धारण". Computers and Composition. 23 (1): 91–107. doi:10.1016/j.compcom.2005.12.002.
  19. Bjork, Collin (September 2018). "OWI में डिजिटल रेटोरिक के साथ उपयोगिता परीक्षण को एकीकृत करना". Computers and Composition. 49: 4–13. doi:10.1016/j.compcom.2018.05.009. S2CID 196160668.


बाहरी संबंध