QA इंजीनियर इंटरव्यू के सवाल और जवाब (हिंदी में)

Severity बताती है कि bug system के काम पर कितना बुरा असर डालता है, और इसे आम तौर पर tester तय करता है। Priority बताती है कि इसे कितनी जल्दी ठीक करना है, जो product owner या lead बिज़नेस के हिसाब से तय करते हैं। उदाहरण के लिए, home page पर कंपनी के नाम की spelling गलत होना कम severity है, पर priority बहुत ऊंची है। वहीं किसी पुरानी report में, जिसे साल में एक बार कुछ ही लोग खोलते हैं, crash होना ऊंची severity है पर priority कम हो सकती है।

Positive cases में सही email और password से login, और Remember me चुनकर browser बंद करके दोबारा खोलने पर भी logged in रहना, और इसे न चुनने पर session ख़त्म होना देखूंगा। Negative cases में गलत password, ग़ैर-मौजूद email, खाली fields, गलत format वाला email और email में शुरुआत या अंत के spaces। Security में password का छिपा दिखना, कई बार गलत कोशिश पर account lock होना, error message से यह पता न चलना कि email मौजूद है या नहीं, और SQL injection की कोशिश। साथ में logout के बाद back button भी जांचूंगा।

Bug मिलने पर मैं Jira में उसे New के रूप में दर्ज करता हूं, जिसमें दोहराने के कदम, expected और actual नतीजा, environment, build number, screenshot या screen recording और severity होती है। Lead या product owner उसकी review करके उसे Open करते हैं और developer को assign करते हैं। ठीक होने पर status Fixed होता है और नए build में मैं उसे दोबारा test करता हूं। ठीक मिलने पर Closed, नहीं तो Reopened। अगर bug duplicate है, अपेक्षित व्यवहार है या अगले release में जाएगा, तो वह कारण के साथ उसी status में रहता है।

Equivalence partitioning में inputs को ऐसे समूहों में बांटते हैं जिनके साथ system एक जैसा व्यवहार करे, इसलिए हर समूह से एक value काफ़ी है। यहां तीन समूह हैं: अठारह से कम invalid, अठारह से साठ valid और साठ से ज़्यादा invalid। जैसे 10, 35 और 70। Boundary value analysis में सीमाओं के आसपास test करते हैं, क्योंकि ज़्यादातर गलतियां वहीं होती हैं: 17, 18, 19 और 59, 60, 61। इसके साथ मैं खाली value, दशमलव, negative number और अक्षर भी जांचूंगा।

पहले मैं flaky tests को release gate से अलग करता हूं ताकि वे build न रोकें, पर उन्हें एक सूची में साफ़ दिखाता रहता हूं। फिर failures में pattern ढूंढता हूं: एक ही step, कोई ख़ास browser, parallel run या कोई ख़ास समय। आम कारण होते हैं: fixed sleep की जगह सही wait न होना, tests का आपस में data साझा करना, किसी test का दूसरे के बाद ही चलना, या environment का धीमा होना। मैं explicit waits लगाता हूं, हर test का अपना data बनाता हूं और कारण ठीक होने पर ही test को वापस gate में डालता हूं।

पहले मैं product owner और developer के साथ एक घंटा बैठकर समझूंगा कि क्या बदला है और सबसे जोखिम वाले हिस्से कौन से हैं। Payments में ये हैं: रक़म की गणना, failure और retry, दोहरी payment, refund और payment gateway से आने वाले जवाब। पहले दिन इन्हीं ज़रूरी flows को test करूंगा, अलग-अलग payment तरीकों के साथ। दूसरे दिन edge cases, कमज़ोर network और regression। आख़िर में साफ़ लिखकर दूंगा कि क्या test हुआ, क्या नहीं हुआ और कौन से risk बाकी हैं, ताकि release का फ़ैसला जानकारी के साथ हो।

मैंने report किया कि order confirmation email में कभी-कभी गलत delivery date आती है। Developer ने इसे "cannot reproduce" कर दिया। मैंने बहस करके दोबारा खोलने के बजाय pattern ढूंढा और पाया कि यह सिर्फ़ उन orders में होता है जो आधी रात के आसपास होते हैं, यानी समय क्षेत्र की गणना में गड़बड़ी थी। मैंने ठीक वही कदम और दो उदाहरण के orders लिखकर developer के पास गया और साथ बैठकर दिखाया। उन्होंने तुरंत कारण पकड़ लिया और हमारा तालमेल भी बेहतर हुआ।

एक insurance policy app के release से पहले की शाम exploratory testing करते हुए मुझे मिला कि discount code दो बार लगाने पर premium दो बार कम हो जाता है। मैंने ठीक कदम और हर बार की रक़म नोट की, screen recording बनाई और तुरंत अपने lead और product owner को बताया, सिर्फ़ ticket डालकर नहीं छोड़ा। Developer ने उसी रात fix किया। मैंने fix के साथ discount से जुड़े सभी cases दोबारा चलाए। Release तय समय पर हुआ, और इसके बाद discount के लिए एक automated test भी जुड़ा।

Production में एक bug पहुंचा जिसमें बहुत लंबा display name रखने वाले users के लिए app crash हो जाता था। मैंने profile screen test की थी, पर सिर्फ़ सामान्य नामों से। Report आने पर मैंने कुछ ही मिनटों में उसे दोहराया और developer को पूरी जानकारी दी, जिससे fix जल्दी हुआ। अपनी गलती मानते हुए मैंने हर text field के लिए एक checklist बनाई: बहुत लंबा text, ख़ास characters, emoji, दूसरी भाषाएं और खाली value। अब यह checklist हमारी टीम के test design का हिस्सा है।

Final year प्रोजेक्ट में मुझे features जोड़ने से ज़्यादा अपने app में समस्याएं ढूंढने में मज़ा आया। मैंने एक bug पकड़ा जिसमें एक ही slot को एक साथ बुक करने वाले दो users दोनों को confirmation मिल जाता था, और उसे ठीक करवाने से हमारा app असल में भरोसेमंद बना। तब समझ आया कि quality की ज़िम्मेदारी लेना मुझे अच्छा लगता है। मैंने Selenium और API testing सीखी है, और आगे automation और performance testing में गहराई से काम करना चाहता हूं।

जी हां। अभी मेरी नौकरी में मैं महीने में लगभग दो बार release support करता हूं, ज़्यादातर देर शाम। Deployment के तुरंत बाद production पर smoke tests चलाकर पक्का करता हूं कि ज़रूरी flows काम कर रहे हैं। मैं समझता हूं कि release अक्सर कम traffic वाले समय में होते हैं। इसके लिए मैं पहले से smoke checklist तैयार रखता हूं ताकि काम जल्दी और सही हो। बस इतना जानना चाहूंगा कि ऐसी रातों के बाद अगले दिन के काम के समय में कोई लचीलापन मिलता है या नहीं।

मेरे पास QA में कुछ साल का अनुभव है, जिसमें पिछले दो साल मुख्य रूप से Selenium, Java और RestAssured से automation पर काम किया है। हमारा framework मैंने बनाया और उसे Jenkins में चलाया। यह भूमिका पूरी तरह automation की है और इसमें framework की ज़िम्मेदारी भी है, इसलिए मैं अपनी current CTC से उचित बढ़ोतरी की उम्मीद रखता हूं, जो इस स्तर की QA automation भूमिकाओं के आम दायरे में हो। मेरी current salary की जानकारी मैं दे सकता हूं और बातचीत के लिए तैयार हूं।