UX और UI टेस्टिंग एक ही गतिविधि नहीं हैं

UX और UI टेस्टिंग दो अलग सवाल पूछती हैं

कोई प्रोडक्ट हर UI टेस्ट पास कर सकता है और फिर भी इस्तेमाल में तकलीफ़देह हो सकता है। वही प्रोडक्ट यूज़ेबिलिटी सेशन में लोगों को खुश कर सकता है और प्रोडक्शन में डेटा गँवा सकता है। इनमें से कोई भी गतिविधि दूसरी की जगह नहीं ले सकती।

ऑटोमेशन ईमानदारी से क्या संभाल सकता है

• हर फ़्लो की फ़ंक्शनल शुद्धता। पहले कॉलम की हर चीज़।

• मशीनी एक्सेसिबिलिटी जाँच। गायब लेबल, कंट्रास्ट, फ़ोकस ऑर्डर। असली काम की चीज़, पर एक्सेसिबिलिटी का पूरा हिस्सा नहीं।

• एकरूपता की जाँच। क्या एक ही ऐक्शन तीनों जगह एक जैसा व्यवहार करता है — यह UX की ऐसी समस्या है जिसे टेस्ट किया जा सकता है।

क्या नहीं कर सकता

क्या फ़्लो समझ में आया। क्या एरर मैसेज से मदद मिली। क्या किसी ने बीच में हार मान ली। इनके लिए लोग चाहिए, और इसे यूँ देखना उपयोगी है कि ऑटोमेशन मैन्युअल रिग्रेशन पास हटाकर इन्हीं कामों के लिए समय वापस दिला देता है।

वह ओवरलैप जिसे ऑटोमेट करना सार्थक है

एक पतली-सी पट्टी है जहाँ दोनों सचमुच मिलते हैं, और ज़्यादातर टीमों के पास मौजूद ऑटोमेशन में यही सबसे कम इस्तेमाल होने वाला हिस्सा है।

एकरूपता UX का ऐसा गुण है जिसे टेस्ट किया जा सकता है। क्या एक ही ऐक्शन उन तीनों जगहों पर वही कन्फ़र्मेशन देता है जहाँ वह दिखता है। क्या एरर हर जगह एरर जैसा दिखता है, या कोई एक स्क्रीन चुपचाप फेल हो जाती है। क्या प्राइमरी ऐक्शन हर मोडल में एक ही जगह होता है। इनमें से किसी के लिए भी यह तय करने की ज़रूरत नहीं कि डिज़ाइन अच्छा है या नहीं, और ये सब वही चीज़ें हैं जिन्हें यूज़र लापरवाही के रूप में नोटिस करते हैं।

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

जाल

टीमें UX रिसर्च इसलिए घटा देती हैं क्योंकि UI टेस्ट कवरेज ऊँचा है। यह तर्क सही लगता है, पर यह श्रेणी की ग़लती है: कवरेज बताता है कि प्रोडक्ट वही करता है जिसके लिए उसे बनाया गया था, और इस बारे में कुछ नहीं बताता कि उसे बनाना सही था या नहीं।

बेहतर व्यवस्था यह है कि दोहराव वाली जाँच ऑटोमेशन संभाले, और उससे बचे घंटे उस रिसर्च में लगें जो सिर्फ़ लोग ही कर सकते हैं।

इसके लिए टर्मिनल की ज़रूरत नहीं है। TestSprite डैशबोर्ड में एक प्रोजेक्ट बनाइए, जाँच को सादी भाषा में बताइए और उसे अपने ऐप पर लगा दीजिए। आपकी टीम के डेवलपर चाहें तो यही काम कमांड लाइन से चला सकते हैं; वह यहाँ मिलेगा — CLI रिपॉज़िटरी।

मैकेनिज़्म से ज़्यादा मायने ट्रिगर रखता है। इसे अपने डिप्लॉयमेंट इवेंट से जोड़ देने का मतलब है कि हर बदलाव की जाँच हो जाती है, बिना किसी के अलग से तय किए; GitHub App यह काम डैशबोर्ड से करता है, और GitHub Actions स्टेप यही काम आपके वर्कफ़्लो के भीतर से कर देता है।

TestSprite क्या ऑटोमेट करता है, और क्या आपके लिए छोड़ देता है

यह पूरा फ़ंक्शनल कॉलम ऑटोमेट करता है: फ़्लो काम करता है या नहीं, स्टेप्स के बीच स्टेट सही तरह से आगे बढ़ती है या नहीं, यूज़र को जो बताया जाता है वह असल में हुई बात से मेल खाता है या नहीं। टेस्ट केस आपके प्रोडक्ट से बनते हैं और सादी भाषा में सुधारे जाते हैं, और वे हर बदलाव पर चलते हैं।

यह उन एकरूपता जाँचों को भी कवर करता है जो इसी ओवरलैप में आती हैं — जैसे कि एक ही ऐक्शन हर उस जगह एक जैसा व्यवहार करता है या नहीं जहाँ वह दिखता है, जो कि UX की ऐसी शिकायत है जिसे टेस्ट किया जा सकता है।

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