मॉड्यूल 19 · यूज़ेबिलिटी और कम्पैटिबिलिटी

UX टेस्टिंग

Mutqan Soft QA टीम द्वारा · · 17 मिनट · शुरुआती

UX testing product के user experience की tester द्वारा की गई अपनी inspection है: आप हर user flow पर वैसे चलते हैं जैसे एक customer चलेगा, और हर step पर जाँचते हैं कि navigation, forms और messages उस व्यक्ति को बिना उलझन अपने goal तक पहुँचने देते हैं या नहीं। Reference आपकी पसंद नहीं, बल्कि approved design और WCAG 2.2 जैसी बताई गई expectations हैं।

उदाहरण: food-delivery app में "खाना order करें" छह screens का flow है। UX pass जाँचता है कि हर screen बताती है आप कहाँ हैं, "Continue" वहीं ले जाता है जहाँ उसका label वादा करता है, और declined card पर ऐसा message आता है जो बताए कि आगे क्या करें, "Something went wrong" नहीं।

यह क्यों ज़रूरी है

कोई product हर functional test pass करके भी users खो सकता है: flow पूरा होता है और message technically सही है, फिर भी लोग cart छोड़ देते हैं क्योंकि अगला step साफ़ नहीं। कुछ crash नहीं हुआ, इसलिए ऐसी failures शायद ही report होती हैं।

UX testing अस्पष्ट "कुछ अजीब लगता है" को ऐसी findings में बदलती है जिन पर team काम कर सके, हर finding एक step और टूटी हुई expectation से जुड़ी। ISO/IEC 25010:2023 इन qualities को interaction capability के तहत रखता है, operability, user error protection और self-descriptiveness जैसी sub-characteristics के साथ, इसलिए बताई गई expectation पर टिकी UX finding किसी भी दूसरे defect की तरह एक quality defect है।

UX testing क्या जाँचती है

Usability testing में, जैसा पिछले पाठ में देखा, participants को observe किया जाता है। UX testing, जैसे QA teams इसे करती हैं, वह inspection है जो आप हर sprint में, बिना participants, खुद करते हैं। यह ISTQB का term नहीं है; ISTQB में इसके सबसे क़रीब checklist-based testing है, जो experience-based techniques में से एक है। UX pass ठीक यही है: flow पर चलते हुए लागू की गई एक तय checklist, heuristic evaluation का संकरा और दोहराने योग्य रूप।

आपके test oracle, यानी expected result के स्रोत, के चार हिस्से हैं: approved design, product की अपनी conventions (एक जैसा button हर जगह एक जैसा बर्ताव करे), मान्य heuristics जैसे Nielsen Norman Group के दस heuristics, और WCAG 2.2, जिसके forms, navigation और errors पर criteria इतने precise हैं कि cite किए जा सकें। इनमें से किसी पर टिकी finding defect है; सिर्फ़ पसंद पर टिकी finding suggestion है।

  • User flows: goal से उसकी confirmation तक की screens, बाहर निकलने और वापस आने के रास्तों समेत।
  • Navigation: user कहाँ है, कहाँ जा सकता है, कैसे लौटे।
  • Forms: labels, hints, defaults, validation की timing और error के बाद data।
  • Messages: errors, confirmations और empty states जो बताएँ कि क्या हुआ और आगे क्या करना है।

User flows और navigation

Flow को steps में लिखें, हर step में एक screen और एक action: "Cart → Address → Delivery time → Payment → Review → Confirmation"। Happy path पर एक बार चलें, फिर हर exit और return पर: हर step से Back, refresh, app फिर से खोलना, Payment पर expire होती session, email का link जो flow के बीच में उतारे। अच्छा flow user को किसी भी step से काम खोए बिना पीछे हटने देता है (heuristic 3, user control and freedom)।

हर step पर तीन सवाल पूछें। मैं कहाँ हूँ: page title, highlighted menu item, step indicator ("Step 2 of 5")। कहाँ जा सकता हूँ: ऐसे buttons और links जो अपना action बताएँ ("Continue to payment", "OK" नहीं)। वापस कैसे जाऊँ: ऐसा Back control जो step का data बचाए रखे। WCAG 2.2 आपको cite करने लायक criteria देता है: 2.4.2 Page Titled (page का topic या purpose बताने वाला title), 2.4.4 Link Purpose (link का text, अपने context के साथ, बताए कि वह कहाँ ले जाता है) और 3.2.3 Consistent Navigation (दोहराए गए menus वही relative order रखें)।

Flow: खाना order करें (mobile web)

Step  Screen         Action          टेस्ट करने वाले exits
1     Cart           Continue        Back, refresh
2     Address        Save address    Back (cart बचा?), refresh (form बचा?)
3     Delivery time  Pick a slot     चुनते-चुनते slot भर गया
4     Payment        Pay             card declined, session expired, Back
5     Review         Confirm order   Confirm पर double tap
6     Confirmation   -               refresh (order दोबारा?), email का link

आज़माएँ: User Story → टेस्ट सिनेरियो आज़माएँ: टेस्ट सिनेरियो जनरेटर

Forms और error messages

Forms उन जगहों में से हैं जहाँ बहुत से UX defects रहते हैं, क्योंकि यहाँ product user से काम करवाता है। हर form को तीन passes में जाँचें। खाली form: visible labels, शब्दों में marked required fields, टाइप करने से पहले DD/MM/YYYY जैसे format hints, sensible defaults और field से मेल खाता mobile keyboard, जो सब errors को पहले ही रोकते हैं (heuristic 5, error prevention)। Realistic valid data: पूरा Arabic या हिंदी नाम, spaces वाला phone number, paste की गई values। Invalid data, जैसे positive और negative testing के पाठ में।

Invalid pass में timing और उसके बाद का हाल देखें। जो validation user के टाइप करते-करते चल पड़े वह finding है; आम expectation यह है कि वह user के field छोड़ने या submit करने तक रुके, फिर focus पहले error पर ले जाए। Error के बाद टाइप की गई values बची रहें, और message अपने field के पास हो। WCAG 3.3.1 माँगता है कि error वाले field की पहचान हो और error text में बताया जाए; 3.3.3, कि पता हो तो सुधार सुझाया जाए; 3.3.7 Redundant Entry, कि उसी process में पहले दी गई जानकारी auto-populate हो या चुनने के लिए उपलब्ध हो, security के लिए दोबारा entry जैसे exceptions के साथ। Payment step पर delivery address फिर से टाइप करवाना ऐसा defect है जिसे आप cite कर सकते हैं।

Heuristic 9 माँगता है कि messages सादी भाषा में हों, codes के बिना, समस्या ठीक-ठीक बताएँ और समाधान सुझाएँ। Field के लिए इससे चार checkable हिस्से बनते हैं, सादे शब्दों में और दोष के बिना: field का नाम, ठीक-ठीक क्या ग़लत है, कैसे ठीक करें, और जहाँ कोई format हो वहाँ स्वीकार होने वाली value का उदाहरण। Error 4011: Invalid input में इनमें से कुछ नहीं; "Mobile number: इस number में 8 digits हैं। 5 से शुरू होने वाले 9 digits डालें, जैसे 512345678" में चारों हैं। Confirmations और empty states पर भी यही test लागू होता है।

अच्छा error message field का नाम लेता है, बताता है कि क्या ग़लत है और कैसे ठीक करें, और एक उदाहरण देता है, सादे शब्दों में; Error 4011: Invalid input पहली दो जगहों पर code और अस्पष्ट phrase रखता है और न सुधार देता है न उदाहरण।

अच्छा message

भाग 1:Mobile number: भाग 2:this number has 8 digits. भाग 3:Enter 9 digits starting with 5, भाग 4:for example 512345678.

कमज़ोर message, जैसा ship हुआ

भाग 1:Error 4011: भाग 2:Invalid input.

  • 1–4शुरू से अंत तक सादे शब्द: न code, न दोष
  1. 1Field या जगह का नाम लेता हैसमस्या कहाँ है, उन्हीं शब्दों में जो label इस्तेमाल करता है। कमज़ोर message यहाँ एक error code रखता है, जो user को कुछ नहीं बताता।WCAG 3.3.1
  2. 2ठीक-ठीक बताता है कि क्या ग़लत हैUser की value को rule से नापा गया: 9 की जगह 8 digits। Invalid input न किसी rule का नाम लेता है न value का।WCAG 3.3.1
  3. 3बताता है कि कैसे ठीक करेंRule ऐसी instruction के रूप में जिस पर user काम कर सके; WCAG 3.3.3 यही माँगता है जब सुधार पता हो।कमज़ोर message में नहीं
  4. 4एक उदाहरण देता हैएक value जो pass हो जाती, ताकि user अंदाज़ा लगाने की जगह उसका आकार नकल कर सके।कमज़ोर message में नहीं

Message के आस-पास भी जाँचें: वह field के पास है, टाइप की गई value अब भी वहीं है, focus field पर गया, और हर form पर wording एक जैसी है।

पाठ संस्करण
Field: mobile number. Rule: 5 से शुरू होने वाले 9 digits.

Weak:  Error 4011: Invalid input.
Good:  Mobile number: इस number में 8 digits हैं.
       5 से शुरू होने वाले 9 digits डालें, जैसे 512345678.

यह भी जाँचें:  message field के पास है               हाँ / नहीं
              टाइप की गई value field में बची है       हाँ / नहीं
              focus field पर गया                      हाँ / नहीं
              हर form पर एक जैसी wording              हाँ / नहीं

आज़माएँ: वैलिडेशन टेस्ट जनरेटर आज़माएँ: Mock एरर पेलोड जनरेटर आज़माएँ: फ़ेक नाम जनरेटर

UX checklist, एक checkout पर लागू

इन सवालों को ids वाली checklist में बदलें, हर item में हाँ-या-ना वाली एक condition, जैसे checklist-based testing के पाठ में। इसे हर page पर नहीं, हर flow पर चलाएँ। खाना-order flow पर यह ऐसी दिखती है, और इसने यह पाया:

  • FLW-04, Confirm पर double tap से दो orders: Critical, एक functional defect जो UX check से मिला।
  • FLW-02 और FRM-04, Payment से Back पर cart खाली और error के बाद address form साफ़: Major, user दो बार काम खोता है।
  • MSG-01, declined card पर "Something went wrong": Major, user नहीं बता सकता कि retry करे, card बदले या bank को call करे; proposed text attached।
  • NAV-01, NAV-02, FRM-02, step indicator नहीं, "Continue to delivery time" की जगह "OK", card number के लिए text keyboard: हर एक Minor, एक report में grouped।
UX checklist, हर flow पर                                    Result
FLW-01  Happy path बिना dead end पूरा होता है                 pass
FLW-02  हर step से Back data सुरक्षित रखते हुए लौटाता है       fail: Payment -> Cart खाली
FLW-03  किसी भी step पर refresh भरा data रखता है               pass
FLW-04  Double submit दो orders नहीं बना सकता                  fail: orders 1042 और 1043
NAV-01  हर screen बताती है कि user कहाँ है                    fail: step indicator नहीं
NAV-02  हर button अपना action या destination बताता है          fail: Address पर "OK"
NAV-03  Menus और controls हर जगह एक ही स्थान पर                pass
FRM-01  Labels visible, required fields शब्दों में marked       pass
FRM-02  Hints टाइप से पहले, mobile keyboard field जैसा  fail: card के लिए text keyboard
FRM-03  User के टाइप करते समय कोई error नहीं दिखता           pass
FRM-04  Error के बाद टाइप की values बची रहती हैं           fail: address form साफ़ हो गया
MSG-01  Error field, समस्या और सुधार का नाम लेता है             fail: "Something went wrong"
MSG-02  Confirmation बताता है क्या हुआ और आगे क्या              pass
MSG-03  Empty states बताते हैं क्या करना है                     n/a

आज़माएँ: AI QA चेकलिस्ट जनरेटर

आम गलतियाँ

  • पसंद ("button नीला होना चाहिए") को defect के रूप में report करना। हर finding उस expectation का नाम लेती है जिसका उल्लंघन हुआ।
  • सिर्फ़ happy path पर चलना, जबकि बहुत से UX defects सिर्फ़ Back, refresh, timeout या re-entry पर दिखते हैं।
  • Forms को सुविधाजनक data से टेस्ट करना: छोटे Latin नाम, default country। Product की भाषाओं में realistic data इस्तेमाल करें।
  • "Something went wrong" को इसलिए मान लेना कि server सच में fail हुआ। अगर user नहीं जानता कि आगे क्या करे, तो message defect है।
  • Fields को एक-एक करके जाँचना और पूरा form कभी submit न करना, जिससे error के बाद data का हाल कभी नहीं दिखता।
  • अपनी आसानी पर भरोसा करना: flow आपको आसान लगा क्योंकि आप product जानते हैं। Checklist के सामने जो देखा वह report करें।

QA का नज़रिया

UX pass दो बार चलाएँ: design या prototype पर, जब उलझाने वाले step की कीमत बस एक बातचीत है, और बनी हुई feature पर story की testing के हिस्से के रूप में। Flow पर phone और desktop दोनों पर चलें, हर उस भाषा में जिसमें product release होता है।

Screen, step, user क्या देखता है, किस expectation का उल्लंघन हुआ और severity दर्ज करें: खोया order Critical, खोया data Major, अस्पष्ट message Major या Minor, इस पर निर्भर कि user recover कर सकता है या नहीं। Designer और product owner से intended path और messages की approved wording पूछें, और जब भी कोई flow बदले, checklist फिर से चलाएँ।

अभ्यास

Password-reset flow पर UX pass चलाएँ

आपका काम

नीचे एक web app का password-reset flow है, जैसा एक tester ने दर्ज किया। UX checklist लागू करें: हर finding को checklist id, user क्या देखता है, किस expectation का उल्लंघन हुआ और severity के साथ लिखें।

फिर सबसे ख़राब message दोबारा लिखें।

सामग्री
Step 1  Login page: password field के नीचे link "Forgot?".
Step 2  Reset page: placeholder "Email" वाला एक field, label नहीं; button "Submit".
        पहला अक्षर टाइप करते ही field के नीचे लाल रंग में "Invalid email" दिखता है.
        Valid email submit करने पर "Done." दिखता है और page वहीं रहता है.
Step 3  Email "Reset your password", जिसका link step 4 खोलता है.
Step 4  New password page: fields "Password" और "Repeat"; button "Submit".
        Mismatched values: ऊपर "Error: PWD_MISMATCH", दोनों fields साफ़.
        इस page से browser Back step 2 पर ले जाता है, email field खाली.
Step 5  Success के बाद: login page पर redirect, कोई message नहीं.
चरण
  1. Flow map करें: screen, action और टेस्ट करने वाले exits।
  2. हर step पर पूछें: मैं कहाँ हूँ, कहाँ जा सकता हूँ, वापस कैसे जाऊँ।
  3. हर form जाँचें: labels, hints, validation की timing, error के बाद data बचा या नहीं।
  4. हर message को अच्छे message के चार हिस्सों पर जाँचें।
  5. हर finding को id, evidence, expectation और severity के साथ दर्ज करें।
मॉडल उत्तर दिखाएँ
मॉडल उत्तर

NAV-02: "Forgot?" अपना action नहीं बताता; अपेक्षित "Forgot your password?"। Steps 2 और 4 पर "Submit"; अपेक्षित "Send reset link" और "Save new password"। Minor।

FRM-01: step 2 label की जगह placeholder इस्तेमाल करता है, इसलिए टाइप करते ही नाम गायब हो जाता है (संबंधित: WCAG 3.3.2 Labels or Instructions)। Major। FRM-03: "Invalid email" field छोड़ने का इंतज़ार किए बिना पहले अक्षर पर चल पड़ता है। Minor।

MSG-02: "Done." न बताता है क्या हुआ, न आगे क्या करें; अपेक्षित "अगर इस email का account है तो हमने reset link भेज दिया है। अपना inbox और spam folder देखें।" Major। Step 5 पर कोई confirmation नहीं; अपेक्षित "आपका password बदल गया है। नए password से sign in करें।" Minor।

MSG-01, सबसे ख़राब: Error: PWD_MISMATCH न field का नाम लेता है न सुधार सुझाता है (WCAG 3.3.1, 3.3.3), और page के ऊपर दिखता है। Major। Replacement: "Repeat password: दोनों passwords मेल नहीं खाते। दोनों fields में एक ही password टाइप करें।" FRM-04: दोनों fields चुपचाप साफ़ हो जाते हैं; अगर यह जानबूझकर है तो message में यह लिखा हो। Minor। FLW-02: Back पर email खो जाता है। Minor।

अक्सर पूछे जाने वाले सवाल

क्या UX testing और usability testing एक ही हैं?

नहीं। Usability testing असली participants को tasks करते देखती है और उनकी success, time, errors और satisfaction मापती है। UX testing flows, navigation, forms और messages की tester द्वारा की गई अपनी inspection है, checklist और मान्य expectations के सामने। UX pass पहले करें; यह स्पष्ट रुकावटें हटा देता है ताकि usability session सूक्ष्म रुकावटें दिखा सके।

UX finding को कैसे report करूँ कि वह opinion कहकर खारिज न हो?

Expectation का नाम लें। "Declined-card message नहीं बताता कि आगे क्या करें, heuristic 9 (errors से recover करने में मदद) का उल्लंघन; proposed text attached" एक defect है जिसके साथ fix है। "Message unfriendly है" एक opinion है। Screenshot जोड़ें और messages के लिए replacement wording भी।

क्या UX testing accessibility testing की जगह लेती है?

नहीं। दोनों forms और navigation पर overlap करती हैं, और यहाँ cite किए WCAG criteria दोनों के हिस्से हैं, पर accessibility testing screen readers, keyboard operation, contrast और target size भी cover करती है, जो accessibility module में सिखाए जाते हैं।

क्या UX testing automate हो सकती है?

कुछ हिस्से: automated checks पुष्टि कर सकते हैं कि flow पूरा होता है, form error के बाद अपनी values रखता है और हर page का title है। कोई message साफ़ है या कोई step उलझाता है, यह आँकना अब भी इंसान का काम है, इसलिए बदलते flows के लिए checklist को manual regression step के रूप में रखें।

संदर्भ

  • ISO/IEC 25010:2023 — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality modelISO/IEC · 2023उत्पाद गुणवत्ता मॉडल: कार्यात्मक उपयुक्तता, प्रदर्शन दक्षता, संगतता, इंटरैक्शन क्षमता, विश्वसनीयता, सुरक्षा, रखरखाव-योग्यता और लचीलापन।
  • Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024W3C की Recommendation जो सुलभ वेब कंटेंट के लिए टेस्ट करने योग्य success criteria तय करती है — चार सिद्धांतों और तीन conformance स्तरों (A, AA, AAA) में व्यवस्थित।
  • 10 Usability Heuristics for User Interface Design (Jakob Nielsen)Nielsen Norman Group · 1994इंटरफ़ेस डिज़ाइन के लिए Jakob Nielsen के दस व्यापक rules of thumb — जैसे system status की दृश्यता और error prevention — जो मूल रूप से heuristic evaluation के लिए बने थे।
  • ISTQB Certified Tester Foundation Level (CTFL) v4.0ISTQB · 2023सॉफ़्टवेयर टेस्टिंग का फ़ाउंडेशन पाठ्यक्रम: टेस्ट स्तर और प्रकार, टेस्ट डिज़ाइन तकनीकें, टेस्ट प्रबंधन और टूल।
टूल्स

Mutqan tools से अभ्यास करें

वैलिडेशन टेस्ट जनरेटर

फ़ॉर्म फ़ील्ड के लिए validation टेस्ट केस बनाएँ: required, फ़ॉर्मेट, लंबाई, रेंज, pattern और cross-field नियम।

टेस्ट डिज़ाइन

Mock एरर पेलोड जनरेटर

UI की एरर स्थितियाँ टेस्ट करने के लिए फ़ॉर्म और API हेतु फ़ील्ड-स्तरीय validation एरर पेलोड थोक में बनाएँ।

मॉकिंग

फ़ेक नाम जनरेटर

अंग्रेज़ी, अरबी और हिंदी में रैंडम पहले और अंतिम नाम जनरेट करें, लिंग और फ़ॉर्मेट विकल्पों के साथ।

टेस्ट डेटा

टेस्ट सिनेरियो जनरेटर

किसी फ़ीचर के लिए functional, negative, security, usability और compatibility पहलुओं को कवर करने वाले उच्च-स्तरीय टेस्ट सिनेरियो जनरेट करें।

टेस्ट डिज़ाइन

AI QA चेकलिस्ट जनरेटर

Mutqan AI से किसी भी फ़ीचर के लिए अनुकूलित QA चेकलिस्ट (functional, UI, API, security, performance, accessibility, release) बनाएँ।

टेस्ट जनरेशन AI

और गहराई से

इस topic में आपकी प्रगति

QA रोडमैप का हिस्सा