उपयोगिता परीक्षण

From Vigyanwiki
Revision as of 10:50, 25 February 2023 by alpha>Indicwiki (Created page with "{{short description|Technique in user-centered interaction design}} उपयोगिता परीक्षण उपयोगकर्ता-केंद्रित ड...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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

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

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

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

तरीके

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

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

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

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

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

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

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

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

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

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

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

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

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

ए/बी परीक्षण

Main article: A/B testing

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

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

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

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

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

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

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

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

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

उदाहरण

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

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

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

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.

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

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.

शिक्षा

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


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=उपयोगिता_परीक्षण&oldid=102667’