QA hiring in 2026 is bifurcated along a fault line most Indian staffing agencies handle badly. On one side, clients want a manual QA who thinks exhaustively about edge cases and writes reproducible bug reports. On the other, clients want an SDET who writes Playwright, Cypress, or Selenium automation, integrates it into CI, and keeps the flake rate under 2 percent. Very different jobs, very different salary bands. Senior SDET in Bangalore earns 25 to 45 lakhs; senior manual QA at the same level earns 12 to 20 lakhs. Many CVs claim both; most claim neither honestly. The single most effective filter is simple: hand them a feature description (login form, shopping cart, file upload) and ask for 15 test cases in 5 minutes. Strong QA engineers hit 15 easily and spill into edge cases. Weak ones stop at 6 happy-path variations. The guide below gives rubrics for both tracks plus questions that surface real test thinking rather than certification memorization.
Generates 10 to 15 test cases from a feature description including edge cases, error paths, adversarial inputs, not just happy path. Signature skill of a strong QA, cannot be taught in a six-week course. Live exercise under timer separates the top 20 percent in five minutes.
Writes reproducible bug reports with specific steps, expected behavior, actual behavior, environment (OS, browser, version, device), screenshots or logs. Unsung skill. Ask for a redacted sample bug they filed last month.
Understands the product domain enough to spot business-logic bugs, not just UI glitches. QA testing a payments feature should know the charge-authorization-capture flow. Ramp-up speed on a new domain is a signal of general quality.
For SDET roles: two or more years hands-on with Selenium, Playwright, Cypress, or equivalent. Has built a test framework from scratch or meaningfully contributed to one. Understands page object model, test data management, parallelization. Live code review of a test script filters most CVs quickly.
SDETs integrate tests into GitHub Actions, GitLab CI, Jenkins, or similar. Know how to keep flaky tests out of the main build. Understand the cost of a slow test suite on engineering velocity.
Postman, REST-assured, Karate, or Pact for contract testing. Catches regressions cheaper and faster than UI tests. Strong signal for microservices-heavy clients in Bangalore and Hyderabad.
JMeter, k6, Locust, or Gatling. Basic load test design — difference between spike, soak, and stress testing. Rare in the Indian QA pool; premium skill.
OWASP Top 10 awareness, basic injection and XSS testing, understanding of how authentication and authorization can break. Does not need to be a pentester but should know what to look for.
Appium, Detox, Firebase Test Lab, or BrowserStack for real device testing. Critical for clients shipping native or React Native apps to Indian users with wide device diversity.
Axe, WAVE, or manual screen-reader testing. Increasingly important as Indian companies serve US and EU clients with ADA and EAA compliance requirements.
I just built a login form with email and password. Tell me 15 test cases I should write for it. Go.
What to listen for
Happy path, empty fields, invalid email format, wrong password, account locked after N attempts, SQL injection (single quote), XSS (script tag), very long password, browser autofill, back button after login, multiple simultaneous sessions, expired session, special characters, network timeout, case sensitivity. Strong candidates hit 12 to 15 easily and keep going.
Walk me through a bug you caught in the last 6 months that everyone else missed. Why did they miss it, and how did you find it?
What to listen for
Specific bug with business impact, specific investigation approach (exploratory testing, production log analysis, customer complaint triage), honest reflection on why the team missed it. Strong candidates have a favorite bug story they love telling.
How do you decide what to automate versus what to leave manual? Give me the framework you use in your head.
What to listen for
Cost of flakiness, frequency of execution, criticality, stability of the UI. Regression suite worth automating; one-time launch feature usually not. Exploratory and usability testing are inherently manual. Strong candidates describe cases where they chose NOT to automate.
A test passes locally on your machine but fails in the CI pipeline. Walk me through how you debug this.
What to listen for
Environment differences (OS, browser version, timezone), timing issues, test data state, parallel execution conflicts, network dependencies, flaky selectors. Not "I just rerun it until it passes." Strong candidates mention specific tools — CI logs, screenshots on failure, video recording.
A developer says "this is not a bug, it is by design." You strongly believe it is a bug. How do you handle this without escalating to managers?
What to listen for
Document with specific user impact and edge case, escalate through the product or business lens rather than technical, frame as "does this match what the user expects" rather than "you are wrong." Does not get political. Senior QA engineers win this argument diplomatically.
The flakiest test you ever had to debug. What was the root cause, and how did you fix it permanently?
What to listen for
Specific flakiness root cause — timing (waiting for async), shared test state, network instability, external dependency rate limit, browser quirk. Strong answer includes the permanent fix, not just "I added a retry."
You are joining a product team with no automated tests and a slow, painful manual regression cycle. Your plan for the first 90 days?
What to listen for
Prioritizes. Builds smoke test suite for critical paths first. Does not try to automate everything. Involves developers in test writing from week one. Measures flake rate, runtime, bug escape rate. Weak: "I would automate all regression tests in the first month."
How do you stay current with QA practices and tools? Name the last three things you learned.
What to listen for
Specific newsletters (Ministry of Testing, Applitools blog), conferences (STAReast, TestBash), books. Strong signal if they mention trying a new tool in their current role. Weak: "I read articles on LinkedIn."
Score each candidate against these weighted criteria. Total: 100%.
| Criterion | Weight | Signal |
|---|---|---|
| Test design thinking | 30% | Generates broad test cases including edge cases without prompting. Thinks about adversarial inputs, error paths, interaction effects. Can defend why a particular test matters. |
| Bug reporting quality | 20% | Writes reproducible reports with full environment context, screenshots or logs, suspected root cause. Uses consistent template. |
| Automation depth (SDET track) | 20% | Built and maintained test automation at scale. Understands framework architecture, data management, CI integration. Has kept flake rate under control. |
| Domain literacy | 15% | Understands product domain well enough to spot business-logic bugs, not just UI glitches. Ramps up on new domains quickly. |
| Communication and collaboration | 15% | Productive disagreement with developers. Calm escalation. Writes clear status updates on testing progress. Does not get political. |
CV says "Selenium expert" but cannot describe the architecture of a real test framework — page objects, data builders, test runners
Generates only three or four test cases for a simple feature under timer, even with prompting — weak test design instinct
Has never debugged a flaky test and does not know what causes test flakiness beyond "sometimes the test fails"
Bug reports are one-line descriptions without reproduction steps, expected vs actual, or environment details
Strict "developers versus QA" mindset — treats the relationship as adversarial, will struggle on modern product teams
Upload QA Engineer CVs and let AI score every candidate against the same 42-point evidence rubric.
Try CVPRO Free