तीन हफ्ते पहले मैंने अपने एक दोस्त के लिए एक बुकिंग विजेट बनाया था, जो एक योगा स्टूडियो चलाता है — एक चैट, एक प्लान जिसे मैंने जल्दी में मंज़ूर कर दिया क्योंकि मैं किसी और काम में बीच में था, एक रन, और फिर एक वर्ज़न कार्ड जिस पर हरा चेकमार्क था जिसे मैंने देखा और आगे बढ़ गया। मंगलवार को उसने मैसेज किया कि क्या वह किसी दूसरे स्टूडियो की साइट को उसी बिल्ड पर पॉइंट कर सकती है। हां कहने से पहले मैं यह देखने वापस गया कि तीन हफ्ते पहले "वेरिफाइड" का असल मतलब क्या था, और तभी मैंने पहली बार इनमें से किसी रिकॉर्ड को सिर्फ चेकमार्क पर भरोसा करने के बजाय वाकई पढ़ा।
यह ठीक वर्ज़न कार्ड पर, प्रीव्यू और कोड एक्शन के बगल में रहता है — वही जगह जहां आप रीडिप्लॉय या रोलबैक के लिए जाते हैं। सबसे पहली बात जो मैंने नोटिस की: यह सिर्फ उस एक वर्ज़न तक सीमित है, पूरी बातचीत तक नहीं। मैंने एक टूटे हुए डेट पिकर को ठीक करने के लिए इस बिल्ड पर पांच बार इटरेट किया था, और मुझे आधी उम्मीद थी कि रिकॉर्ड मुझे पूरे आगे-पीछे की कहानी बताएगा। यह नहीं बताता। वर्ज़न 4 का रिकॉर्ड सिर्फ वर्ज़न 4 का वर्णन करता है। इसे याद नहीं कि वर्ज़न 2 एक लॉगिन फॉर्म के साथ शिप हुआ था जो चुपचाप फेल हो रहा था, और यह मुझे नहीं बताएगा कि वर्ज़न 5 ने चुपचाप वह चीज़ ठीक कर दी जो वर्ज़न 3 ने तोड़ी थी। हर रिकॉर्ड एक स्नैपशॉट है, न कि कोई डिफ या चेंजलॉग — अगर मुझे रिलीज़-दर-रिलीज़ बदलावों का इतिहास चाहिए, तो वह बिल्कुल अलग व्यू है। यह सिर्फ "क्या यह एक ठीक है" का जवाब देता है।
नीचे स्क्रॉल करने पर, रिकॉर्ड छह पंक्तियों में बंटता है:
| लेयर | पास का मतलब है |
|---|---|
| फंक्शनल / इन-ब्राउज़र | बिल्ड एक वास्तविक ब्राउज़र में चला; इंटरैक्शन को आज़माया गया (गेम्स खेले गए) |
| कोड रिव्यू | एक रीड-ओनली रिव्यूअर को ऐसी कोई खामी नहीं मिली जिसे वह किसी फ़ाइल और व्यवहार से साबित कर सके |
| सुरक्षा | कोई इंजेक्शन सरफेस, लीक हुए सीक्रेट्स, या असुरक्षित पैटर्न सामने नहीं आए |
| लिंक्स और SEO | कोई टूटा लिंक नहीं; मेटाडेटा, robots और sitemap सही क्रम में |
| एक्सेसिबिलिटी | ऑटोमेटेड axe पास में कोई उल्लंघन नहीं मिला |
| कन्फॉर्मेंस | बिल्ड में वही है जो मंज़ूर किए गए प्लान ने वादा किया था |
सभी छह हरे थे, और मेरी पहली प्रतिक्रिया वही गलत प्रतिक्रिया थी जो शायद ज़्यादातर लोगों की होती है: सुरक्षा पास हुई, तो यह सुरक्षित है; एक्सेसिबिलिटी पास हुई, तो यह एक्सेसिबल है। इनमें से कोई भी व्याख्या यह जांचने पर टिक नहीं पाती कि चेक असल में क्या करते हैं। सुरक्षा पास का मतलब है — सतही चीज़ें, जैसे किसी क्वेरी में स्ट्रिंग कॉन्कैटेनेशन, क्लाइंट बंडल में खुलेआम पड़ी API key, किसी यूज़र के टाइप किए गए पर eval — सामने नहीं आईं। यह किसी पेनिट्रेशन टेस्टर के साथ बिताया गया दिन नहीं है। मेरे दोस्त का स्टूडियो इस विजेट के ज़रिए पेमेंट नहीं ले रहा, सिर्फ नाम और टाइम स्लॉट, इसलिए यह स्तर उसके लिए ठीक था। अगर यह चेकआउट फ्लो होता, तो मैं इससे ज़्यादा चाहता।
एक्सेसिबिलिटी वह पंक्ति थी जिसने मुझे वाकई रुककर कुछ खोजने पर मजबूर किया, क्योंकि "axe पास" सुनने में पूर्ण लगता है और है नहीं। Axe — पर्दे के पीछे चलने वाला ऑटोमेटेड इंजन — भरोसेमंद तरीके से WCAG के लगभग एक-तिहाई से आधे सक्सेस क्राइटेरिया पकड़ता है: गुम alt टेक्स्ट, खराब कॉन्ट्रास्ट रेशियो, बिना लेबल वाले फॉर्म फील्ड्स, साफ ARIA गलतियां। यह यह नहीं बता सकता कि मैंने जो कस्टम डेट-पिकर ड्रॉपडाउन मांगा था वह स्क्रीन रीडर से इस्तेमाल हो पाता है या नहीं, मल्टी-स्टेप बुकिंग फ्लो में टैब करने पर फोकस कहीं सही जगह पहुंचता है या नहीं, या मैंने "confirmed" बनाम "pending" स्टेटस को जो हरा और पीला रंग दिया है वह लाल-हरे रंगान्धता वाले किसी व्यक्ति के लिए समस्या है या नहीं। इनके लिए किसी व्यक्ति को उन्हीं टूल्स से बिल्ड से गुज़रना होगा जिन पर विकलांग यूज़र्स असल में निर्भर करते हैं। Axe असली संकेत है, कुछ नहीं से बेहतर — यह एक्सेसिबिलिटी की स्पेलिंग-चेकर लेयर है, एडिटर नहीं।
कन्फॉर्मेंस वह पंक्ति थी जिसे मैं लगभग छोड़ते-छोड़ते बचा, क्योंकि यह ब्यूरोक्रेटिक लगती है — "जो प्लान ने वादा किया वही है" — जब तक मुझे याद नहीं आया कि जो प्लान मैंने मंज़ूर किया था वह मेरे विचलित रहते हुए लिखा गया था, और मुझे सच में याद नहीं था कि मैंने ईमेल कन्फर्मेशन मांगा था या सिर्फ SMS। यह वह लेयर है जो बिल्ड को प्लान के मुकाबले जांचती है, मेरे असली इरादे के मुकाबले नहीं, और यह पास हुई, जिसने मुझे बताया कि बिल्ड उससे मेल खाता है जिसे मैंने हां कहा था, ज़रूरी नहीं कि उससे जो मेरा मतलब था। मैंने ऐसे बिल्ड्स के बारे में सुना है जो फंक्शनल रूप से मज़बूत और सुरक्षित थे फिर भी इस लेयर पर फेल हो गए क्योंकि समय के दबाव में एक फीचर चुपचाप छूट गया। यह वह लेयर है जो बिल्ड को उस बातचीत के प्रति ईमानदार रखती है जिसने इसे जन्म दिया, भले ही वह बातचीत खुद थोड़ी लापरवाह रही हो।
छह पंक्तियों के नीचे एक लंबी सूची थी, जो दो हिस्सों में बंटी थी, और यहीं मैंने सबसे ज़्यादा समय बिताया। Must-fix आइटम्स बिल्ड में फिलहाल गलत चीज़ें नहीं हैं — ये रसीदें हैं। एक लाइन में लिखा था कि रिव्यू लेयर ने एक ऐसा मामला फ्लैग किया था जहां एक डेट स्ट्रिंग सीधे किसी क्वेरी में इंटरपोलेट हो गई थी, और इस वर्ज़न को पूर्ण चिह्नित किए जाने से पहले ही इसे पैच कर दिया गया था। मैं किसी खुले घाव को नहीं देख रहा था; मैं एक निशान देख रहा था। यह फर्क मायने रखता है, क्योंकि अगर आप must-fix एंट्री को एक लाइव चेतावनी की तरह पढ़ते हैं, तो आप ऐसी चीज़ की चिंता में समय गंवाएंगे जो पहले ही बंद हो चुकी है।
एडवाइज़री सूची लंबी थी, और इसमें ज़्यादातर वे चीज़ें थीं जो अगर मैं किसी सहकर्मी का कोड रिव्यू कर रहा होता और मर्ज ब्लॉक नहीं करना चाहता, तो मैं खुद कहता: "दोहराए जा रहे स्लॉट-रेंडरिंग ब्लॉक को एक शेयर्ड कंपोनेंट में निकालने पर विचार करें," "इस एंडपॉइंट में कोई रेट लिमिटिंग नहीं है, जो एक इंटरनल बुकिंग टूल के लिए ठीक है लेकिन अगर यह पब्लिक हो तो दोबारा सोचने लायक है।" उस सूची में कुछ भी खामी नहीं थी। ये ऐसे जजमेंट कॉल्स थे जो एक वेरिफायर ने सिर्फ प्लान और कोड के आधार पर लिए, और एक योगा स्टूडियो के इंटरनल शेड्यूलर के लिए, हर एक कॉल उचित पक्ष पर उतरा। अगर मेरे दोस्त का स्टूडियो एक फ्रैंचाइज़ होता जिसका विजेट पचास लोकेशन पेजों पर एम्बेड होता, तो मैं रेट-लिमिटिंग वाली बात पर आपत्ति जताना चाहता — यह वर्गीकरण उस संदर्भ पर निर्भर करता है जिसे वेरिफायर सिर्फ अनुमान लगा सकता है, और जब कोई अनुमान आपको गलत लगे, तो सही कदम यह है कि चैट में कह दें, यह मान न लें कि लेबल अंतिम है।
जो बात मुझे चौंका गई, एक साफ-सुथरे must-fix कॉलम के बगल में एक ठीक-ठाक बड़ी एडवाइज़री सूची देखकर, वह यह थी कि मैं लगभग इसकी लंबाई को बुरी खबर की तरह पढ़ने लगा था। ऐसा नहीं है। शून्य एडवाइज़री नोट्स वाला बिल्ड या तो सीमित पास से गुज़रा या किस्मत अच्छी थी; "consider" वाले आइटम्स के ढेर और must-fix में कुछ भी बकाया न होने वाला बिल्ड वह है जिसे वाकई ध्यान से देखा गया है। एडवाइज़री कॉलम वही है जो असली समस्याएं दूर होने के बाद बचना चाहिए।
एक और चीज़ जो मैंने खुद से करवाई, क्योंकि यह रिकॉर्ड तीन हफ्ते पुराना था, वह यह जांचना था कि निर्णयों पर भरोसा करने से पहले असल में कौन-सी लेयर्स चलीं। यहां सभी छह मौजूद थीं, लेकिन मैंने तब से एक ऐसा बिल्ड देखा है जहां एक्सेसिबिलिटी को पास या फेल चिह्नित करने के बजाय सूची से पूरी तरह गायब कर दिया गया था — यह इस बात जैसा नहीं है कि इसे महत्वहीन मानकर छोड़ दिया गया, यह संकेत है कि उस खास साइट टाइप या फ्लैग कॉन्फ़िगरेशन के लिए चेक चला ही नहीं, और गायब होने को खामोश पास मान लेना बिल्कुल वही गलती है जिसकी दावत यह फॉर्मैट देता है अगर आप सरसरी तौर पर देख रहे हों।
इनमें से किसी ने भी मुझे यह नहीं बताया कि योगा स्टूडियो का बुकिंग फ्लो असल में कन्वर्ट करता है या नहीं, लोग टाइम-स्लॉट स्टेप पर इसे छोड़ते हैं या नहीं, या क्या Calendly पर लिंक करने के बजाय एक कस्टम विजेट का पूरा आइडिया ही सही फैसला था। वेरिफिकेशन यह साबित करता है कि बिल्ड वादे के मुताबिक काम करता है, यह नहीं कि वह वादा करना सही था — ये अलग सवाल हैं, और मैंने ऐसे बिल्ड्स देखे हैं जो हर लेयर से साफ निकल गए फिर भी असली यूज़र्स के साथ फ्लॉप हो गए क्योंकि "सही तरीके से काम करना" और "सही समस्या हल करना" उतने मेल नहीं खाते जितनी उम्मीद होती है। इसका वह आधा हिस्सा जो असल में दूसरे सवाल का जवाब देता है वह है मेज़रमेंट लूप, और दोनों को साथ पढ़ा जाना चाहिए। एक ऐसे फीचर पर साफ वेरिफिकेशन रिकॉर्ड जिसे कोई बुक ही न करे, फिर भी वह ऐसा ही फीचर रहता है जिसे कोई बुक नहीं करता।
