Interview Process Samjho
// 01 — QA HIRING KA PATTERN
Screening / Test
Basic aptitude + testing concepts MCQ. Kabhi-kabhi ek scenario likhne ko milta hai — "is login page ke test cases likho."
Technical Round 1
Manual testing concepts — SDLC/STLC, bug life cycle, test case writing live.
Technical Round 2
Automation (Selenium/API) + SQL + scenario questions. Manual-only role mein deep scenarios.
Managerial + HR
Process fit, communication (QA mein bahut important), salary discussion.
Insider tip: QA interview ka favourite live task: "Yeh pen / login page / lift test karo." Ghabrao mat — categories mein socho: functional, UI, boundary, negative, performance, security, usability. Category-wise bologe toh structured tester dikhoge.
Testing Field Mein Kaunsi Jobs Hain?
// JOBS MAP — EK DEGREE, 8 CAREER PATHS
QA ke andar bhi 8 specializations hain — jitna niche skill, utni kam bheed aur utni achhi salary:
📝
Manual Tester
Test design + execution — entry point. Domain knowledge (banking/healthcare) se value double hoti hai.
INTERVIEW FOCUSConcepts, test cases, bug reports, JIRA.
💰 ₹3–4.5 LPA
Full Role Guide niche padho →
🤖
Automation / SDET
Selenium/Playwright + coding — testing ka highest paid track. Manual se 2 saal mein switch possible.
INTERVIEW FOCUSJava/Python, framework design, Git, CI basics.
💰 ₹4–7 LPA
Full Role Guide niche padho →
🔌
API Tester
Postman/RestAssured se backend testing — UI banne se pehle bugs pakdo. Automation ke saath combo best.
INTERVIEW FOCUSHTTP methods, status codes, JSON, auth flows.
💰 ₹3.5–6 LPA
Full Role Guide niche padho →
🚀
Performance Tester
JMeter/LoadRunner — load par system ka behaviour. Niche skill, kam log, achhi salary.
INTERVIEW FOCUSJMeter, response time/TPS metrics, bottleneck analysis.
💰 ₹4–7 LPA
Full Role Guide niche padho →
📱
Mobile Tester
Android/iOS apps — device matrix, gestures, Appium automation.
INTERVIEW FOCUSMobile-specific test cases, ADB basics, Appium awareness.
💰 ₹3.5–6 LPA
Full Role Guide niche padho →
🗄️
ETL / Data Tester
Data pipelines validate karna — SQL heavy. Banking/insurance projects mein regular demand.
INTERVIEW FOCUSComplex SQL, data warehouse concepts, mapping documents.
💰 ₹4–7 LPA
Full Role Guide niche padho →
🎮
Game Tester
Gaming companies mein functionality + gameplay testing — passion wala niche, entry competitive.
INTERVIEW FOCUSGame sense, bug reporting discipline, platform knowledge.
💰 ₹2.5–5 LPA
Full Role Guide niche padho →
👔
QA Lead Track
5+ saal mein team + process ownership — metrics, strategy, client calls. Management ka raasta.
INTERVIEW FOCUSEstimation, risk-based testing, team handling, metrics.
💰 ₹10–18 LPA (exp)
Full Role Guide niche padho →
Kaise choose karein: Manual se shuru karo, 1-2 saal mein automation + API add karo — yahi standard growth formula hai. Performance ya ETL jaisa ek niche pakad liya toh competition 90% kam ho jaati hai.
Manual Testing Q&A
// 03 — FRESHER + MANUAL ROLE KE PAKKE QUESTIONS
SDLC aur STLC mein kya difference hai?
SDLC pura software development ka life cycle hai — requirement, design, coding, testing, deployment, maintenance. STLC uske andar testing ka apna cycle hai — requirement analysis, test planning, test case design, environment setup, execution, closure. Ek line mein: SDLC product banane ka process, STLC us product ko verify karne ka process — STLC SDLC ka subset hai.
Test case aur test scenario mein kya farak hai?
Scenario high-level hai — "kya test karna hai": "Verify login functionality." Test case detailed hai — "kaise test karna hai": steps, test data, expected result. Ek scenario ke multiple test cases hote hain — valid login, invalid password, blank fields, locked account. Interviewer bole "login page ke scenarios batao" toh 8-10 categories mein bolo — functional, negative, UI, security (SQL injection in field), boundary (password length).
Severity aur priority ka difference — example ke saath.
Severity = bug ka technical impact (kitna tootta hai), tester decide karta hai. Priority = kitni jaldi fix karna hai (business urgency), lead/PM decide karta hai. Classic examples: High severity–low priority: app crash hota hai ek aise feature mein jo koi use nahi karta. Low severity–high priority: homepage par company ka naam galat spelled hai — kuch tootta nahi, par turant fix chahiye. Yeh dono examples zubani yaad rakho — 100% poocha jaata hai.
Bug life cycle explain karo.
New → Assigned → Open (dev kaam kar raha) → Fixed → Retest → Verified → Closed. Side paths: Rejected (bug nahi hai), Duplicate, Deferred (baad ke release mein), Reopened (retest mein fail). Har state ka owner batao — New/Retest tester ka, Open/Fixed developer ka. JIRA mein aapne yeh workflow use kiya ho toh bolo.
Smoke, sanity aur regression testing mein difference?
Smoke: naya build aaya — critical paths jaldi check karna ki build testable hai bhi ya nahi ("build verification test"). Sanity: chhote change/fix ke baad related area quickly check karna. Regression: naye change se purana kuch toota toh nahi — pura ya selected suite chalana. Memory trick: smoke = build level, sanity = change level, regression = impact level.
Boundary Value Analysis aur Equivalence Partitioning samjhao.
EP: input range ko valid/invalid classes mein baanto aur har class se ek value test karo. Example: age field 18-60 — classes: <18 (invalid), 18-60 (valid), >60 (invalid). BVA: boundaries par bugs sabse zyada hote hain — test karo 17, 18, 19 aur 59, 60, 61. Dono saath use hote hain — EP se classes, BVA se edges. Yeh example board par likhne ko bola ja sakta hai.
Achhi bug report mein kya hota hai?
Title (clear, searchable), steps to reproduce (numbered, koi bhi follow kar sake), expected vs actual result, environment (browser/OS/build number), severity/priority, screenshot ya video, logs agar available hon. Golden rule bolo: "Bug report aisi ho ki developer bina mujhse baat kiye reproduce kar sake." Reproducibility rate bhi mention karo agar intermittent hai (3/5 times).
Verification aur validation mein difference?
Verification: "Are we building the product right?" — documents/design reviews, static testing, code review — bina execute kiye. Validation: "Are we building the right product?" — actual execution karke check karna ki requirement meet hoti hai — dynamic testing. Review = verification, testing = validation.
Automation Q&A
// 04 — SELENIUM + API TESTING
Selenium mein locators kaunse hain? Priority kya rakhte ho?
ID, name, className, tagName, linkText, partialLinkText, CSS selector, XPath. Priority: ID sabse pehle (fastest, unique), phir name/CSS, XPath last resort (fragile hota hai layout change par). Dynamic elements ke liye: contains(), starts-with() wale XPath ya stable attributes se CSS. Ek dynamic XPath example zubani ready rakho: //button[contains(text(),'Submit')].
Implicit aur explicit wait mein difference?
Implicit wait: global setting — har element find par maximum itna wait karo (driver level, ek baar set). Explicit wait: specific element + specific condition ka wait — WebDriverWait + ExpectedConditions (elementToBeClickable, visibilityOf). Best practice: explicit wait use karo, implicit + explicit mix mat karo (unpredictable timing hoti hai). Thread.sleep() kabhi framework mein nahi — yeh bolna zaroori hai.
POM (Page Object Model) kya hai?
Framework design pattern — har web page ki ek alag class jisme us page ke locators aur actions (methods) hote hain. Test scripts sirf in methods ko call karti hain. Fayda: locator change hua toh sirf ek jagah update — maintenance easy, code reusable, tests readable. PageFactory ka naam le lo (@FindBy annotations) — bonus point.
StaleElementReferenceException kya hai? Kaise handle karte ho?
Element ko locate karne ke baad DOM refresh/change ho gaya — purana reference invalid ho gaya. Handle: element ko dobara locate karo (re-find), explicit wait with refreshed condition, ya retry logic. Yeh sabse common Selenium exception hai — iske saath NoSuchElement (locator galat/element nahi hai) aur TimeoutException bhi ready rakho.
API testing mein kya check karte ho?
(1) Status code sahi hai (200/201/400/401/404/500 scenario ke hisaab se), (2) response body — fields, values, data types, (3) response time, (4) headers (content-type), (5) negative cases — invalid token, missing fields, galat method, (6) DB mein data actually update hua ki nahi (SQL se verify). Postman mein collections, environment variables aur basic tests (pm.test) use kiye hain — yeh bolo agar kiya hai.
Automation kaunse cases ke liye sahi hai aur kaunse ke liye nahi?
Automate karo: regression suite, smoke tests, data-driven repetitive cases, cross-browser checks. Mat karo: ek baar chalne wale tests, frequently changing UI, exploratory/usability testing, jinka automation cost > manual cost. ROI wala answer do: "automation investment hai — repeat hone wale stable cases par hi return milta hai."
Experienced Q&A
// 05 — LEAD-LEVEL THINKING
Release kal hai aur testing time kam hai — kya karoge?
Risk-based testing ka answer: (1) Critical business flows pehle (payment, login, core feature), (2) naye changes + unke impact areas, (3) recent defect-heavy modules, (4) baaki low-risk areas ko time mile toh. Stakeholders ko clearly batao kya test hua, kya nahi — "sign-off with known risks" document karo. "Sab test karunga" bolna immaturity hai — prioritization hi asli skill hai.
Developer bug ko "not a bug" bol raha hai — kya karoge?
(1) Requirement/acceptance criteria ke saath evidence do — screenshot, expected behaviour ka source. (2) Requirement ambiguous hai toh BA/PO ko involve karo — decision unka hai. (3) Personal debate mat banao — data se baat karo. (4) Deferred hota hai toh document karo. Yeh question aapki communication maturity ke liye hai, technical skill ke liye nahi.
Production mein bug escape ho gaya jo aapke area ka tha — kya karoge?
Ownership + process: (1) Pehle impact assessment aur hotfix testing mein support, (2) RCA — yeh case test cases mein kyun nahi tha? Requirement gap, test data gap, ya environment difference? (3) Test suite update karo taaki category cover ho, (4) team ke saath learning share karo. Defensive mat bano — "escape defects process improve karne ka input hote hain" — yeh attitude lead material dikhata hai.
Aapke automation framework ke baare mein batao.
Structure ready rakho: language (Java/Python), Selenium + TestNG/PyTest, POM design, data-driven (Excel/JSON), reporting (Extent/Allure), Git par code, Jenkins/GitHub Actions se nightly run, failures par screenshot + email/Slack alert. Numbers do: "450 regression cases automated, nightly run 2.5 ghante, regression cycle 3 din se 1 din hua." Framework diagram bana kar samjhana best hai.
QA metrics kaunse track karte ho?
Defect density, defect leakage (production escapes ÷ total defects), test case execution/pass rate, automation coverage, requirement coverage, mean time to detect. Smart line: "metrics ko target nahi, signal ki tarah use karta hoon — pass rate 100% ho aur leakage high ho toh test suite hi weak hai."
Specialization-Wise Complete Guides
// TESTING KE HAR TRACK KA POORA MATERIAL
Jo specialization choose ki, uska complete interview material yahan — frameworks, commands, metrics, sab included.
📝 Manual Tester — Complete Guide
Test design, execution, exploratory — testing ki foundation.
⬆ Jobs MapTest case likhne ka standard format kya hai?
Har test case mein: TC ID, module, title, precondition (kya ready hona chahiye), test steps (numbered, koi bhi execute kar sake), test data, expected result (measurable — "kaam karna chahiye" ❌, "success message 'Order placed' dikhe aur order ID generate ho" ✔), actual result, status, severity of failure, evidence link. Live exercise pakka milega ("login page ke test cases likho") — categories mein likho: positive, negative, boundary, UI, security, usability — structure hi selection karata hai.
"Is search box ko test karo" — live kaise approach karoge?
Category framework bolo, phir cases: Functional — valid search, no results, partial match, case sensitivity, special characters; Boundary — empty search, 1 character, max length, sirf spaces; Negative — SQL injection string, HTML tags, emoji; UI/UX — placeholder, clear button, keyboard Enter, suggestions; Performance — bade result set ka time; Compatibility — mobile view. 60 second mein 15+ cases categories ke saath = structured tester. Random 5 cases = reject.
Exploratory testing kya hai? Scripted se kaise alag?
Bina pre-written cases ke, application ko samajhte hue simultaneously test design + execute karna — charter ke saath ("aaj 90 min payment flow explore karunga, focus: interruptions aur back-button"). Scripted testing coverage deta hai, exploratory woh bugs pakadta hai jo cases mein soche hi nahi the. Session notes rakhna (kya explore kiya, kya mila) ise "random clicking" se alag karta hai. "Regression scripted, naye features par exploratory bhi" — yeh balance wala answer do.
Domain knowledge kyun important hai — kaise banaoge?
Banking tester ko pata hona chahiye NEFT kya hai, insurance tester ko premium/claim cycle — warna aap sirf UI test karte ho, BUSINESS test nahi. Domain wale tester ki salary 20-30% zyada isi liye hai. Banane ka tarika: apne project ke domain ke basics padho (isi site ki Banking/CA guides kaam aayengi!), business analysts se process poochho, production data patterns dekho. Interview mein apne project ka domain flow explain kar pao — "loan application se disbursement tak ka flow maine end-to-end test kiya hai" — yeh line resume se zyada bolti hai.
🤖 Automation / SDET — Complete Guide
Framework design, locators, flaky tests — testing ka highest-paid track.
⬆ Jobs MapApne framework ka structure explain karo — kya-kya hota hai?
Standard anatomy bolo: (1) Base/Driver manager — browser setup/teardown, (2) Page Objects — har page ki class (locators + actions), (3) Test classes — sirf business flow, technical details nahi, (4) Utilities — waits, screenshots, Excel/JSON readers, (5) Test data alag files mein (data-driven), (6) config.properties (URL, browser, env), (7) Reporting — Extent/Allure with screenshots on failure, (8) CI integration — nightly Jenkins/GitHub Actions run + email/Slack results. Whiteboard par yeh boxes bana kar samjhao — framework ka diagram hi automation interview ka aadha marks hai.
Flaky tests (kabhi pass kabhi fail) kaise fix karte ho?
Flakiness ke 4 killers: (1) Thread.sleep hatao → explicit waits (ExpectedConditions), (2) test independence — har test apna data khud banaye/cleanup kare, dusre test par depend na kare, (3) dynamic locators fix karo — stable attributes/relative locators, (4) environment issues — test env ka data koi aur badal raha hai toh isolated data strategy. Retry mechanism last resort hai, ilaaj nahi — "retry lagakar flakiness chhupana technical debt hai" — yeh bolo, SDET-level maturity dikhegi.
Kaunse cases automate karoge, kaunse nahi — ROI kaise decide?
Automate: regression (baar-baar chalta hai), smoke/sanity (har build par), data-driven (same flow × 50 data sets), cross-browser. Mat karo: ek baar chalne wale, frequently changing UI, exploratory/usability, captcha/OTP jaise (inke liye test hooks maango dev se). ROI formula ka sense: (manual execution time × frequency × releases) vs (script banane + maintain karne ka time). "Automation coverage 100% target nahi hota — critical path 100%, overall 60-70% healthy hai" — yeh number bolo.
Selenium mein ek dynamic element handle karke dikhao.
Scenario: ID roz badalta hai (id="btn_8372"). Solutions bolo: (1) stable attribute — css: button[data-testid='submit'], (2) text se — xpath: //button[contains(text(),'Submit')], (3) partial attribute — //*[starts-with(@id,'btn_')], (4) relative/anchor se — label ke bagal wala input: //label[text()='Email']/following-sibling::input, (5) best long-term: dev se data-testid attributes maangna — "testability design ka hissa hai." Explicit wait ke saath wrap karna mat bhoolo. Yeh live coding round ka sabse common task hai.
🔌 API Tester — Complete Guide
Postman, auth, chaining, negative testing — UI se pehle bugs pakdo.
⬆ Jobs MapPostman mein professional workflow kya hota hai?
(1) Collections — module-wise organized requests, (2) Environments — dev/staging/prod ke URLs + variables ({{base_url}}), same collection har env par chale, (3) Tests tab mein assertions — pm.test("status 200", () => pm.response.to.have.status(200)), response body/time/schema checks, (4) Pre-request scripts — dynamic data (timestamps, random emails), (5) Collection runner/Newman se poora suite + CI mein. "Main Postman ko sirf request bhejne ke liye nahi, automated API suite ki tarah use karta hoon" — yahi difference hai clicker aur tester mein.
API chaining kya hai — example do.
Ek API ka response agli API ka input banta hai. Classic flow: (1) POST /login → response se token nikalo → pm.environment.set("token", jsonData.token), (2) POST /orders — header mein Bearer {{token}} → order_id save karo, (3) GET /orders/{{order_id}} — verify karo. End-to-end business flow API level par test ho gaya — UI se 10x fast. Interview mein yahi login→create→verify chain zubani explain karna aana chahiye.
Auth types kaunse hote hain API testing mein?
(1) Basic auth — username:password base64 mein (sirf HTTPS par), (2) API key — header/query mein fixed key, (3) Bearer token/JWT — login se mila token har request ke header mein (expiry test karna mat bhoolo — expired token par 401 aana chahiye), (4) OAuth 2.0 — third-party access ka flow (concept: user Google se login kare, app ko token mile — password kabhi share nahi hota). Negative auth cases hi asli testing hai: no token, expired token, dusre user ka token (authorization bypass — serious bug), tampered JWT.
Ek API ke liye negative test cases batao.
POST /users example par: required field missing (400 + clear error message aani chahiye), galat data type (age = "abc"), boundary (name 1 char / 500 chars), duplicate (same email dobara — 409), invalid format (email bina @), extra unexpected fields, galat method (GET on POST endpoint — 405), malformed JSON (400), no auth (401), dusre ka resource access (403), bahut bada payload, SQL/script injection strings fields mein. Har case mein sirf status nahi — error RESPONSE ka structure bhi verify karo. Yeh list interview mein jitni fluent, utna experience dikhta hai.
📱 Mobile Tester — Complete Guide
Devices, mobile-specific cases, ADB, Appium — app testing ka field.
⬆ Jobs MapMobile-specific test cases kaunse hote hain jo web mein nahi?
(1) Interruptions — call/SMS/notification aane par app ka behaviour + wapas resume, (2) network transitions — WiFi→4G→offline→wapas (data loss/crash toh nahi?), (3) background/foreground — 10 min background ke baad state, (4) permissions — deny karne par graceful handling (crash nahi), settings se revoke, (5) orientation change har screen par, (6) battery — low battery/battery saver mode, (7) different screen sizes/notch, (8) app upgrade — purane version se update par data safe? (9) install/uninstall/reinstall, (10) OS versions matrix. Yeh list interview mein fluent bolna = mobile experience proof.
Real device aur emulator kab kya use karte ho?
Emulator: development-time functional checks, screen sizes, free + fast. Real device: performance (asli CPU/memory), battery/heating, camera/GPS/sensors, network real conditions, gestures ka feel, release sign-off HAMESHA real devices par. Device matrix strategy: analytics se apne top 8-10 devices (OS + screen combos) — sab test karna impossible hai. Cloud device farms (BrowserStack/Firebase Test Lab type) ka naam lo — coverage bina devices kharide.
ADB ke kaunse commands use karte ho?
adb devices (connected devices), adb install app.apk / adb uninstall package, adb logcat (crash ka reason yahin milta hai — crash bug mein logcat attach karna pro habit hai), adb shell (device ke andar), adb shell screencap (screenshot), adb push/pull (files transfer), adb shell dumpsys battery/meminfo (battery/memory stats). "Crash aaya toh main logcat se stack trace nikaal kar bug mein daalta hoon — developer ka aadha kaam wahin ho jaata hai" — yeh line mobile testing interview mein gold hai.
Appium ka basic architecture samjhao.
Appium = mobile ka Selenium — same WebDriver protocol. Test script → Appium server → device par native automation framework (Android: UiAutomator2, iOS: XCUITest) → app. Capabilities se batate ho kaunsa device/app (platformName, deviceName, app path/package). Locators: accessibility id (best — dev se lagwao), id, xpath (slow, last option). Ek hi test code Android + iOS par chal sakta hai agar locators accessibility ids hon — cross-platform hi Appium ka selling point hai.
🗄️ ETL / Data Tester — Complete Guide
Data pipelines, SQL-heavy validation — banking/insurance ka regular demand.
⬆ Jobs MapETL testing mein kya-kya validate karte ho?
(1) Count validation — source vs target records (rejected records ka hisaab ke saath), (2) Data completeness — koi record/column drop toh nahi hua, (3) Transformation logic — mapping document ke rules verify (jaise: status 'A' → 'Active', amount = qty × rate), (4) Duplicates — target mein duplicate keys nahi, (5) Nulls/defaults — required fields mein null nahi, defaults sahi lage, (6) Data types/truncation — string cut toh nahi hui, dates ka format, (7) Incremental load — sirf naya/changed data aaya, purana duplicate nahi hua, (8) Referential integrity — orphan records nahi. Mapping document hi ETL tester ki bible hai — yeh bolna mat bhoolo.
Source vs target comparison ki SQL kaise likhte ho?
Patterns bolo: Count: SELECT COUNT(*) dono taraf + rejected/error table ka count — total match hona chahiye. Missing records: source MINUS target (ya LEFT JOIN WHERE target.key IS NULL). Duplicates: SELECT key, COUNT(*) FROM target GROUP BY key HAVING COUNT(*) > 1. Column-level compare sample par: JOIN karke jahan source.col <> target.col. Aggregate checks: SUM(amount) source vs target — bade tables par full compare ki jagah smart hai. Yeh 5 query patterns hi ETL testing ka 80% kaam hai — likhne ki practice karke jao.
Incremental load testing kaise karoge?
Scenario-based: (1) Day-1 full load verify karo, (2) source mein controlled changes karo — 2 naye records INSERT, 2 UPDATE, 1 DELETE, (3) incremental run ke baad verify: naye aaye, updated records ka naya version aaya (SCD Type 1 overwrite ya Type 2 history — mapping ke hisaab se), deleted ka handling (soft delete flag?), (4) re-run same batch — duplicates NAHI banne chahiye (idempotency), (5) late-arriving data ka case. SCD Type 1 vs Type 2 ka difference pata hona chahiye — Type 2 mein purana record close hota hai (end_date) aur naya version insert — data warehouse interviews ka favourite.
Data warehouse concepts — fact aur dimension kya hai?
Fact table: measurable events/numbers — sales_amount, quantity (badi, transactions), dimension tables: context — customer, product, date, region (chhoti, descriptive). Star schema: beech mein fact, chaaron taraf dimensions — analyst-friendly. Surrogate keys (warehouse ki apni IDs) vs natural keys. Tester ke liye matlab: fact-dimension joins ke baad orphan facts check karna (dimension key jo exist nahi karti), aggregations reports se match karna. Itna concept ETL tester interview ke liye kaafi hai — modeling designer ka kaam hai, validation aapka.
🎮 Game Tester — Complete Guide
Functionality, gameplay, compliance — passion ka professional roop.
⬆ Jobs MapGame testing normal app testing se kaise alag hai?
Types: (1) Functionality — menus, saves, purchases, crashes (normal QA jaisa), (2) Gameplay/balance — difficulty curve, economy (coins kamana vs kharchna balanced hai?), fun-factor feedback, (3) Compatibility — devices/GPU range, (4) Performance — FPS drops, loading times, memory (lambi session mein heating), (5) Multiplayer — sync, lag, disconnection recovery, (6) Compliance — platform ke rules (console certification requirements, store policies). "Game 'kaam karta hai' aur 'khelne mein maza aata hai' — dono alag test hain" — yeh samajh hi game QA hai.
Game bug report mein extra kya hota hai?
Normal report + : video clip (game bugs words mein samjhana mushkil — recording default habit), exact build number (roz nayi builds aati hain), level/mission/checkpoint, save file attach (us state par pahunchne ke ghante bachte hain developer ke), repro rate (gameplay bugs aksar intermittent), device + graphics settings, FPS us waqt. Severity game context mein: progression blocker (aage badh hi nahi sakte) = critical, visual glitch = low. "Save file + video + build number" — yeh trio bolo, experienced lagoge.
FPS aur performance testing games mein kaise karte ho?
Target FPS devices ke tier se (flagship 60, budget 30 stable), tools se monitor (platform profilers, overlay tools), heavy scenes identify karo — bahut effects/characters wale moments, wahan drops log karo scene + settings ke saath. Memory: lambi session (soak) mein badhti jaa rahi hai = leak; heating/battery drain bhi note karo. Loading times har device tier par. "Stable 30 FPS bhi fluctuating 45 se behtar experience hai" — smoothness consistency ka point bolo.
Game testing mein career kaise banaoge — sirf khelna kaafi hai?
Honest answer: entry-level game testing repetitive hai (same level 50 baar) — passion + patience dono chahiye. Growth ke raste: QA lead, automation (game engines ke test frameworks), performance specialist, ya game design/production mein shift (QA game ka sabse gehra gyaan rakhta hai). Standing out: bug reports ki quality, ek-do published games ke credits, game engines (Unity/Unreal) ki basic samajh. "Main gamer se game professional banna chahta hoon — QA best entry hai" — is frame se answer karo.
👔 QA Lead Track — Complete Guide
Estimation, strategy, metrics, team — management ka raasta.
⬆ Jobs MapTesting effort ka estimation kaise karte ho?
(1) WBS — testing ko tasks mein todo (test design, execution cycles, automation, regression, retesting buffer), (2) historical data — pichle similar module mein kitna laga tha (sabse reliable), (3) 3-point estimation — (Optimistic + 4×Most likely + Pessimistic)/6, (4) buffers explicitly — defect retesting ~30%, environment issues. Ratio thumb: 1 test case design ~15-20 min, execution ~10-15 min complexity se. "Estimate commitment ban jaata hai isliye main assumptions ke saath deta hoon — 'yeh estimate 2 test cycles maan kar hai'" — yeh line lead-level hai.
Test strategy aur test plan mein difference?
Strategy: organization/project level ka HIGH-LEVEL approach — kya automate hoga, kaunse environments, entry/exit criteria ka philosophy, tools, risk approach (kam badalta hai). Plan: specific release/feature ka document — scope (kya test hoga/nahi hoga), schedule, resources, kaun kya karega, specific risks. Strategy = constitution, plan = is election ka manifesto. Interview mein dono ke 5-5 contents gin do — clarity dikhegi.
Kaunse QA metrics track karte ho — aur kaunse metric se bachte ho?
Track: defect leakage (production escapes ÷ total — QA effectiveness ka #1 metric), requirement/test coverage, defect density module-wise (hotspots dikhte hain), automation coverage + pass stability, cycle time. Bachne wala: "tester ne kitne bugs nikale" ko performance metric banana — log severity inflate karte hain, dev-QA jung hoti hai. "Metrics ko signal ki tarah use karta hoon, target banate hi log metric ko game karna shuru kar dete hain" — Goodhart's law ka yeh practical roop bolo, senior lagoge.
Release kal hai, testing aadhi hui hai — lead ke roop mein kya karoge?
(1) Risk-based ruthless prioritization — critical business flows + naye changes + payment/data-loss areas pehle, (2) team ko repurpose karo — automation wale bhi manual par, (3) transparent status stakeholders ko: "yeh test hua ✔, yeh nahi hua, yeh risks hain" — sign-off WITH known risks, decision business ka, (4) go/no-go recommendation dene ki himmat — data ke saath "P1 area untested hai, main release recommend nahi karta" bolna bhi lead ka kaam hai, (5) baad mein RCA — is situation mein aaye kyun. Pressure mein transparency — yahi answer chahiye interviewer ko.
HR Round Model Answers
// 06 — QA-SPECIFIC HR
Developer nahi ban paaye isliye testing mein aaye ho?
Yeh sawal QA freshers ko provoke karne ke liye aata hai. Calm + positive: "Nahi, maine testing consciously choose kiya — mujhe cheezein todna aur edge cases sochna naturally pasand hai. Achha tester hona alag skill hai — system ko user ki tarah aur attacker ki tarah dono nazar se dekhna." Defensive mat bano, confident raho.
Manual se automation mein kyun shift ho rahe ho?
"Manual testing ne mujhe test design aur user thinking sikhaya — ab main us base par automation add kar raha hoon taaki regression fast ho aur main exploratory testing par zyada time de sakoon. Maine [Selenium/Playwright + course/project] kiya hai." Manual ko chhota mat dikhaao — dono ka value bolo.
Tell me about yourself.
"Maine [degree] kiya hai, [X saal] manual + automation testing ka experience hai, [domain — banking/ecommerce] applications test ki hain. Selenium-Java framework par kaam kiya hai aur API testing Postman se karta hoon. Mujhe quality ownership lena pasand hai — mera last project zero critical production escapes ke saath release hua." Domain ka naam lena QA mein bahut matter karta hai.
Salary Guide (Approx, India 2026)
// 07 — MANUAL VS AUTOMATION KA GAP DEKHO
| Level | Manual QA | Automation / SDET |
|---|
| Fresher | ₹3 – 4.5 LPA | ₹4 – 7 LPA |
| 2-5 yrs | ₹5 – 9 LPA | ₹8 – 18 LPA |
| 5-10 yrs | ₹8 – 14 LPA | ₹15 – 30+ LPA |
Career advice: Manual + automation + API + SQL — yeh combo aapko "complete QA" banata hai. Sirf manual par 5 saal rukna salary ceiling laga deta hai. Selenium ya Playwright mein se ek + ek programming language (Java/Python) — bas itna hi chahiye automation shift ke liye.