क्वालिटी इंजीनियर इंटरव्यू में किन प्रश्नों की उम्मीद करूँ?

इंटरव्यू लेने वाले टूल से पहले आपके निर्णय को परखते हैं। ऐसी सुविधा के लिए क्या टेस्ट करना है जिसे आपने पहले कभी नहीं देखा, यह समझाने के लिए तैयार रहें: आवश्यकताओं और कोड में हुए बदलाव को पढ़ना, सबसे जोखिमपूर्ण रास्तों की पहचान करना, यह चुनना कि कौन-सी जाँच यूनिट, इंटीग्रेशन और एंड-टू-एंड स्तर पर चलेगी, और यह तय करना कि क्या मैन्युअल रहेगा। अगला प्रश्न लगभग हमेशा इसका उलटा होता है: आप क्या टेस्ट नहीं करेंगे और क्यों। जो उम्मीदवार यह कह सकते हैं कि कम जोखिम वाले कॉन्फ़िगरेशन बदलाव के लिए पूर्ण रिग्रेशन के बजाय स्मोक टेस्ट पर्याप्त है, वे वही निर्णय क्षमता दिखाते हैं जिसकी इस भूमिका में आवश्यकता है।

• टेस्ट पिरामिड। बहुत सारे तेज़ यूनिट टेस्ट, उनसे कम इंटीग्रेशन टेस्ट और बहुत कम एंड-टू-एंड टेस्ट। अगला प्रश्न: जब कोई टीम इसे उलट देती है तो क्या गलत होता है?
• जोखिम-आधारित टेस्टिंग। विफलता की संभावना और प्रभाव के अनुसार प्राथमिकता तय करना और किसी प्रोडक्ट मैनेजर को यह प्राथमिकता समझा पाना।
• टेस्ट डिज़ाइन तकनीकें। इक्विवेलेंस पार्टिशनिंग, बाउंड्री वैल्यू, डिसीजन टेबल और स्टेट ट्रांज़िशन; किसी ठोस इनपुट फ़ील्ड पर इनमें से किसी एक को लागू करने के लिए तैयार रहें।
• नॉन-फंक्शनल टेस्टिंग। परफ़ॉर्मेंस, एक्सेसिबिलिटी और सुरक्षा की बुनियादी बातें तथा यह जानना कि इनमें से प्रत्येक कब दायरे में आता है।
• एग्ज़िट मानदंड। आप कैसे तय करते हैं कि रिलीज़ तैयार है और जब मानदंड पूरे होने से पहले समय-सीमा आ जाए तो क्या करते हैं।

जहाँ भी प्रश्न अनुमति दे, अपने काम का कोई ठोस उदाहरण दें; रणनीति से जुड़े प्रश्नों में विशिष्टता के आधार पर मूल्यांकन होता है।

आप रोज़ ऑटोमेशन करते हैं और उम्मीद रखते हैं कि इंटरव्यू लेने वाला टूल के बारे में पूछेगा। इसके बजाय वे संरचना के बारे में पूछेंगे, इसलिए इस खंड में वे प्रश्न शामिल हैं जो बताते हैं कि आपका ऑटोमेशन सुव्यवस्थित ढंग से बनाया गया है या बस इकट्ठा होता गया है।

• फ्रेमवर्क डिज़ाइन। टेस्ट और एप्लिकेशन के बीच की लेयर (ड्राइवर, पेज ऑब्जेक्ट या स्क्रीन मॉडल, API क्लाइंट), साझा फ़िक्स्चर, टेस्ट डेटा प्रबंधन, रिपोर्टिंग और कोई नया इंजीनियर पुराने टेस्ट की नकल किए बिना नया टेस्ट कैसे जोड़ता है।
• अस्थिर टेस्ट। सबसे पसंदीदा प्रश्न। दोबारा चलाने से पहले कारण खोजें: टाइमिंग और इम्प्लिसिट वेट, टेस्ट के बीच साझा स्थिति, क्रम पर निर्भरता, एनवायरनमेंट के अंतर और एसिंक्रोनस व्यवहार। बताएँ कि आप किसे अलग रखते हैं, किसे हटाते हैं और पूरे सुइट को अनदेखा होने से कैसे बचाते हैं।
• API और कॉन्ट्रैक्ट टेस्टिंग। सेवाओं को सीधे टेस्ट करना, स्कीमा सत्यापित करना और उपभोक्ता-संचालित कॉन्ट्रैक्ट इस्तेमाल करना, जो एंड-टू-एंड टेस्ट से पहले नुकसानदेह बदलाव पकड़ लेते हैं।
• टूल से जुड़े प्रश्न। Selenium, Playwright, Cypress या कोई मोबाइल फ्रेमवर्क; REST क्लाइंट; कोई लोड टूल। इंटरव्यू लेने वालों के लिए यह कम महत्वपूर्ण है कि आपने कौन-सा चुना, और अधिक महत्वपूर्ण यह है कि आपने उसे क्यों चुना और उसकी सीमाएँ क्या हैं।
• कोडिंग। Python, Java, JavaScript या C# में कोई छोटा टेस्ट या यूटिलिटी लिखने और यह बताने के लिए तैयार रहें कि कई एज केस वाले फ़ंक्शन को आप कैसे टेस्ट करेंगे।

उत्तर आपस में जोड़ें: स्पष्ट लेयर वाला फ्रेमवर्क ही अस्थिर टेस्ट का कारण खोजना आसान बनाता है, और कॉन्ट्रैक्ट टेस्ट ही एंड-टू-एंड लेयर को छोटा रखने देते हैं।

वरिष्ठ भूमिकाओं के इंटरव्यू में आपको कोई स्थिति दी जाती है। एक सामान्य उदाहरण: किसी हेल्थकेयर सॉफ़्टवेयर कंपनी में वरिष्ठ भूमिका के लिए इंटरव्यू दे रहे क्वालिटी इंजीनियर को बताया जाता है कि रिलीज़ दो दिन में भेजी जानी है, एंड-टू-एंड सुइट एक सप्ताह से विफल है और डेवलपर कहते हैं कि विफलताएँ एनवायरनमेंट के कारण हैं। मजबूत उत्तर रिलीज़ पर बहस करने से पहले विफलताओं को कारण के अनुसार अलग करता है: वह विफलताओं को पढ़ता है, एनवायरनमेंट की समस्याओं को वास्तविक दोषों से अलग करता है, जाँचता है कि विफल टेस्ट इस रिलीज़ के बदलावों को कवर करते हैं या नहीं, और रिलीज़ मैनेजर को केवल हाँ या नहीं के बजाय जोखिम का स्पष्ट विवरण देता है। इंटरव्यू लेने वाला छंटाई और संवाद क्षमता का मूल्यांकन कर रहा होता है।

बार-बार आने वाले अन्य परिदृश्य: CI गेट इस तरह डिज़ाइन करना कि पुल रिक्वेस्ट पर यूनिट और कॉन्ट्रैक्ट टेस्ट चलें, जबकि धीमे सुइट तय समय-सारणी पर चलें; टेस्ट एनवायरनमेंट और टेस्ट डेटा का ऐसा प्रबंधन कि टेस्ट किसी एक साझा डेटाबेस पर निर्भर न हों; किसी ऐसे थर्ड-पार्टी इंटीग्रेशन में बदलाव को टेस्ट करने का तरीका तय करना जिसे आप नियंत्रित नहीं कर सकते; ऐसा दोष रिपोर्ट करना जिससे डेवलपर असहमत हो; और कवरेज को लक्ष्य बनाए बिना गुणवत्ता मापना। हर मामले में बाधा बताएँ, कोई तरीका चुनें और उसकी लागत स्पष्ट करें।

जब आप इन उत्तरों को आगे के प्रश्नों के साथ बोलकर अभ्यास करते हैं तो इनमें तेज़ी से सुधार होता है; इसी के लिए मॉक इंटरव्यू मोड है। अन्य भूमिकाओं के प्रश्न-संग्रह भूमिका और विषय के अनुसार इंटरव्यू प्रश्न के अंतर्गत उपलब्ध हैं।

संवाद-आधारित दौरों में, हाँ—ईमानदार सीमाओं के भीतर। SubcueAI का मूल macOS और Windows डेस्कटॉप ऐप सिस्टम ऑडियो और आपके माइक्रोफ़ोन की आवाज़ कैप्चर करता है तथा स्थानीय ओवरले में छोटे उत्तर-सुझाव दिखाता है। इसलिए जब इंटरव्यू लेने वाला पूछता है कि आप किसी अस्थिर सुइट का कारण कैसे खोजेंगे, तो अपने अनुभव के आधार पर उत्तर देते समय चेकलिस्ट आपकी स्क्रीन पर होती है। ब्राउज़र एक्सटेंशन Chrome और Edge पर ब्राउज़र-टैब कॉल के लिए केवल मीटिंग टैब का ऑडियो कैप्चर करता है। कोई बॉट कॉल में शामिल नहीं होता और मीटिंग पेज में कुछ भी इंजेक्ट नहीं किया जाता; सेटअप ट्यूटोरियल पेज पर दिया गया है।

सीमाएँ: टेक-होम असाइनमेंट, निगरानी वाले कोडिंग कार्य, रिकॉर्ड की जा रही स्क्रीन और कंपनी द्वारा प्रबंधित लैपटॉप इसके दायरे से बाहर हैं, और ऐसा लाइव अभ्यास जिसमें आप निगरानी के अंतर्गत टेस्ट लिखते हैं, आपका अपना काम है। SubcueAI के संस्थापक Aaron Cao इस उत्पाद को स्क्रिप्ट के बजाय उस जानकारी के संकेत के रूप में बताते हैं जिसे आप पहले से जानते हैं; इसीलिए यह आपके रिज़्यूमे और आपके अपने शब्दों के आधार पर काम करता है। पहले वह रिज़्यूमे लोड करें; आपकी प्रोफ़ाइल रिज़्यूमे बिल्डर में रहती है।