36 practice questions with answers for Software Testing interviews in Lucknow.
Software Testing jobs in Lucknow
Lucknow's tech job market is smaller but growing, led by IT-services delivery centres, government-tech projects and start-ups. Many Lucknow candidates target Noida and Gurgaon roles or remote jobs, so interviews follow the NCR pattern.
Below are 36 questions that match the mix of service, product and domain employers hiring software testers in Lucknow.
Solved for LucknowStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
✓ 3 questions free • Unlock the rest in seconds
01
What are focus order and visible focus, and how do you test them?
Focus order is the sequence in which keyboard focus moves through interactive elements; it should follow the visual reading order. Visible focus means the focused element clearly shows a ring or highlight. Test by pressing Tab through the page and watching where focus goes. Common bugs are focus jumping to the footer, focus going behind an open dialog and designers removing the outline with CSS, leaving keyboard users lost.
Check that each requirement is clear, complete, consistent and testable. Look for vague words like fast or user-friendly, missing error handling, undefined limits, conflicting rules and missing roles or states. For each requirement ask how you would test it and what the expected result is. Record questions in a review log and get answers from the business analyst before writing test cases, so ambiguity does not turn into defects later.
04
What basic security checks do you do for a mobile app?
Check that sensitive data like tokens and personal details are not stored in plain text on the device or written to logs. Verify all traffic uses HTTPS and the app rejects invalid certificates. Check session timeout, logout clearing data and that sensitive screens block screenshots if required. Test behaviour on rooted or jailbroken devices if the policy needs it, and that API keys are not visible in the app package.
05
What is mobile app testing and what extra checks does it need?
Run the report query with GROUP BY on the business key and HAVING COUNT(*) > 1 to find which records repeat. Then check whether the duplicates exist in the base table or are created by the query, usually a new join to a one-to-many table such as addresses. Compare the query before and after the release. Include the duplicate keys, the count and the suspected join in the bug report.
08
Explain three usability heuristics with examples from a web app.
Visibility of system status: after clicking Pay, show a progress indicator so users do not click again. Error prevention: disable the Submit button until required fields are valid, or ask for confirmation before deleting an account. Recognition rather than recall: show recently searched items and saved addresses instead of making users remember them. Other heuristics include consistency, user control with undo, and clear help for recovering from errors.
09
What is the difference between a test suite and a test run?
Answer with strengths and honesty. For example: I am strong at understanding requirements, designing test cases with techniques like boundary values and finding bugs through exploratory testing, which automation depends on to be useful. I also write SQL and test APIs in Postman. I am learning Playwright and have automated a few smoke tests, so I can grow into automation while adding value from the first week.
11
Tell me about a time you had to learn SQL or API testing quickly for a project.
Model answer: Situation: in my first project, testers had to verify orders in the database, and I knew only basic SELECT. Task: become useful within a week. Action: I practised joins on a copy of the test database every evening and asked a senior to review my queries. Result: by the second sprint I was validating order data on my own and caught a missing tax column bug.
Trigger the email from each event, such as signup or order placed, and verify it arrives at the right address within the expected time. Check subject, sender name, personalised fields, amounts and links. Click every link and confirm it opens the right page. Check the layout on desktop and mobile mail apps, the unsubscribe option where required, and that no email is sent for failed or cancelled actions. Use a test mailbox tool in QA.
A position-based XPath such as /html/body/div[3]/div[2]/button breaks whenever a developer adds a wrapper div or reorders the layout, even though the feature still works. That creates false failures and maintenance work. Locators based on a dedicated data-testid attribute or the accessible role and name, like a button named Submit, stay valid through design changes and describe intent clearly. Testers should ask developers to add test IDs.
15
SQL: find orders that have an order date in the future.
-- Orders cannot be placed in the future
SELECT id, order_date, status
FROM orders
WHERE order_date > CURRENT_TIMESTAMP;
-- Expected result: no rows. If rows appear, check time zone handling and input validation.
The test basis is the set of documents and knowledge from which test cases are derived. It includes requirement specifications, user stories with acceptance criteria, design documents, wireframes, API contracts, business rules and even existing system behaviour. A good test basis lets you trace each test case back to a requirement. If the test basis is weak or missing, testers must clarify it before or while testing.
Components are fixed sub-parts of a project, such as Payments or Login, often with a default owner. Labels are free-text tags, such as regression or ui, that anyone can add for grouping. Fix version is the release in which the issue is planned to be fixed, while affects version is where the bug was found. Testers use these fields to filter bugs and to build release-wise reports.
19
What is SQL injection and how can a tester check for it at a basic level?
SQL injection happens when user input is added directly into a database query, letting an attacker change the query to read or modify data. A tester can enter inputs like a single quote or ' OR '1'='1 in login, search and URL parameters and watch for database errors, unexpected results or a login bypass. Only test in approved environments. The real fix is parameterised queries, not input filtering alone.
20
Tell me about a time you pushed for an accessibility fix the team wanted to postpone.
Situation: before a release, I found the payment form errors were not announced by screen readers and not reachable by keyboard. Task: the team wanted to defer it. Action: I recorded a short NVDA video showing a user could not finish payment, linked it to WCAG and our customer commitments, and proposed a small fix. Result: the fix took half a day, shipped in the release and we added keyboard checks to our definition of done.
Won't Fix means the bug is acknowledged as real, but the team decides not to fix it, usually because the impact is very low, the feature is being retired or the cost of fixing is higher than the benefit. The decision is made by the product owner, often in triage with dev and QA leads. The tester should make sure the reason is recorded and, if user-facing, documented as a known issue.
22
How do you break a requirement into testable conditions?
Read the requirement and identify inputs, outputs, business rules, user roles and states. Turn each rule into a condition with an expected result, then add negative and boundary conditions. For example, 'users can withdraw up to 10,000 per day' becomes: withdraw below the limit, exactly at the limit, above the limit, multiple withdrawals adding up to the limit, and the limit resetting the next day. Each condition then becomes one or more test cases.
23
A manager says the app has 50,000 daily users, so the load test must run 50,000 virtual users at once. How do you respond?
Explain that daily users are not concurrent users. Of 50,000 users a day, only a fraction are active at the same moment, and even they pause between actions because of think time. Use analytics to find the real peak concurrency and request rate, for example 1,500 concurrent users at peak hour, and model that with a safety margin. Running 50,000 users clicking at once tests a load that never happens and wastes effort.
Test monitoring compares actual testing progress with the plan, using metrics like test cases executed, pass rate, open defects and effort spent. Test control is the action taken when monitoring shows a gap, such as re-prioritising tests, adding testers, changing the schedule or tightening entry criteria. For example, if half the time has passed but only a quarter of cases are executed, the lead must act and inform stakeholders.
25
How do you capture logs from an Android device for a bug report?
Enable developer options and USB debugging, connect the phone and confirm it is visible with adb devices. Clear old logs with adb logcat -c, reproduce the bug, then save logs with adb logcat -d > crash_log.txt, filtering by the app package or error level if needed. For a crash, search for FATAL EXCEPTION. Attach the log, device model, OS version, app version and a screen recording to the bug.
A locator tells the automation tool how to find an element on the page so it can click, type or check it. Common types are ID, name, CSS selector, XPath, link text, and in modern tools role-based locators such as a button with name Login, plus label, placeholder and test ID locators. A good locator is unique, readable and unlikely to change when the page design changes.
Normalization organises tables to reduce duplicate data, for example storing the customer address once in a customers table instead of repeating it in every order. Testers should understand it because it explains where data lives and which joins are needed to verify a screen. It also shows risk: in a denormalized report table, the same value is copied in many places, so updates must be tested to confirm every copy changes.
30
What is the difference between a story, epic, task and bug in JIRA?
A flaky test passes and fails on the same code without any change. Common causes are timing problems such as fixed sleeps or missing waits, tests depending on each other or on shared data, unstable locators, animations, third-party services, test order in parallel runs and environment issues like slow servers. Flaky tests destroy trust in the suite, so teams quarantine them, find the root cause and fix it rather than adding retries forever.
Recovery testing checks how well the system recovers from crashes, hardware failures, network loss or other failures. For example, kill the server during a file upload, or disconnect the network during payment, and verify the system restores a consistent state, does not lose or duplicate data and resumes or shows a clear message. It also measures recovery time against agreed targets, which matters for banking and healthcare systems.
33
What is heuristic evaluation and how is it different from a usability test with users?
Heuristic evaluation is an expert review where a few evaluators inspect the interface against known usability principles, such as Nielsen's ten heuristics, and list problems with severity. It is fast and cheap and needs no participants. A usability test watches real users perform tasks and shows where they actually struggle. Heuristic reviews find many obvious issues early, but they can miss problems that only real users with real goals reveal.
1. Correct current password and valid new password: success, old password stops working. 2. Wrong current password: error, no change. 3. New password same as current: rejected if policy says so. 4. New and confirm fields do not match: error. 5. New password below minimum or above maximum length: error. 6. Missing digit or special character: policy message. 7. Other active sessions are logged out. 8. Confirmation email or alert is sent. 9. Password fields are masked.
Turn on the screen reader, for example NVDA with a browser, and listen rather than look. Navigate by headings to check the structure is logical, by landmarks to find main regions and by Tab through controls. Each control should announce a clear name, role and state, such as 'Subscribe, checkbox, not checked'. Check images, form errors, dynamic updates like cart counts and dialogs. Note exactly what was announced in bug reports.
36
Write a CSS selector and an XPath for a Login button that has the attribute data-testid='login-btn' and the text Login.
/* CSS selector using the test id */
button[data-testid='login-btn']
// XPath using the test id
//button[@data-testid='login-btn']
// XPath using the visible text
//button[normalize-space()='Login']
Which companies hire Software Testing professionals in Lucknow?
Companies with large offices in Lucknow include HCLTech. Use their company pages below to practise employer-specific sets.
Are Software Testing interviews in Lucknow different from other cities?
The questions depend more on the company than the city. Lucknow's mix of employers decides the style: Many Lucknow candidates target Noida and Gurgaon roles or remote jobs, so interviews follow the NCR pattern
How do I find Software Testing jobs in Lucknow?
Shortlist companies with Lucknow offices, keep your CV focused on Software Testing projects, apply on company career pages and job portals with the Lucknow filter, and practise the questions on this page before each interview.