Software Testing Interview Questions in Visakhapatnam
36 practice questions with answers for Software Testing interviews in Visakhapatnam.
Software Testing jobs in Visakhapatnam
Visakhapatnam (Vizag) has a developing IT market with delivery centres, start-ups and IT parks around Rushikonda. Many local candidates also apply to Hyderabad and remote roles, so a mix of service and product styles is common.
Below are 36 questions that match the mix of service, product and domain employers hiring software testers in Visakhapatnam.
Solved for VisakhapatnamStart 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 is data integrity and what are its main types?
Data integrity means data stays accurate and consistent through its life. Entity integrity: every row has a unique, non-null primary key. Referential integrity: a foreign key always points to an existing parent row, such as every order pointing to a real customer. Domain integrity: values stay within allowed types and ranges, enforced by data types, CHECK and NOT NULL constraints. User-defined integrity covers business rules, such as an order total never being negative.
02
Write test cases for live order tracking in a food delivery app.
Verify each status change appears in order: placed, accepted, preparing, picked up and delivered. Check the rider's location updates on the map at the expected interval. Test the estimated time updates when there is a delay. Verify notifications for each status. Check behaviour when the network drops and recovers, when the app is reopened, and when the order is cancelled midway. Confirm tracking stops after delivery and the rating screen appears.
03
What is colour contrast ratio and what values does WCAG require?
Contrast ratio compares the brightness of text and its background, from 1:1 to 21:1. WCAG AA requires at least 4.5:1 for normal text and 3:1 for large text, which is about 18 point or 14 point bold. User interface parts such as input borders and icons need 3:1. AAA raises text to 7:1. Testers check this with a contrast checker or browser developer tools, including placeholder, disabled and hover states.
A development model where each development phase has a matching testing phase, such as requirements with acceptance tests and design with integration tests.
06
A user updates their phone number in the app, but the old number still appears in reports. What do you check?
First query the main users table to see whether the update was saved. If it was, check where the report reads from: a view, a reporting copy, a cache or a nightly ETL table. The report may simply be stale until the next refresh, which may be by design. If the main table still has the old value, check the API request, the update query and any errors in logs, then log a bug with both query results.
Valid login, wrong password, empty fields, case sensitivity, max length, SQL-injection strings, password masking, 'remember me', lock-out after N attempts and the forgot-password link.
08
How do you test biometric login with fingerprint or face unlock?
Test enabling biometrics in app settings after a password login. Verify login with a registered fingerprint or face, and failure with an unregistered one, falling back to PIN or password after the allowed attempts. Remove or add a fingerprint in device settings and check the app asks for re-authentication. Test devices without biometric hardware, disabled biometrics and app behaviour after an OS update or reinstall.
Sprint planning (estimate test effort), daily stand-up (status and blockers), sprint review (demo) and retrospective (improve). Testers clarify acceptance criteria early and test within the sprint.
Shift-left means starting testing activities earlier in the life cycle: reviewing requirements, joining design discussions and writing tests before code is complete. A defect found in requirements may cost a short conversation to fix, while the same defect found in production may need a hotfix, data correction and customer support. Testers shift left by asking questions in grooming, defining acceptance criteria and reviewing designs.
12
Release is tomorrow and you can't test everything. What now?
Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.
13
How do you handle pressure when many bugs are found close to a release?
Model answer: Situation: two days before a release, we found 15 new bugs in checkout. Task: help the team decide what to fix. Action: I stayed calm, retested each one quickly, ranked them by user impact, and shared a clear list in triage with must-fix and can-wait items. Result: we fixed five critical bugs, released on time with documented known issues, and no critical issue reached users.
1. Open and close by click and keyboard. 2. Select one, then several options; all show as chips or a count. 3. Deselect an option. 4. Select all and clear all, if available. 5. Search inside the list filters options. 6. Maximum selection limit is enforced with a message. 7. Required field shows an error if none selected. 8. Saved selection persists after refresh. 9. Long option names do not break layout. 10. Screen reader announces selected state.
Testing shows presence of defects, exhaustive testing is impossible, test early, defects cluster, the pesticide paradox, testing is context-dependent and absence-of-errors is a fallacy.
19
You join a project in the middle of a release. How do you plan your testing?
Spend the first day learning the scope: read the release notes, user stories and test plan, and ask the lead what is at risk. Get access to the environment, tracker and test repository. Pick up a clearly defined module, run its existing test cases to learn the application and note gaps. Ask questions early in stand-up. Within a few days, take ownership of retesting and regression for that module.
A regression bug is a feature that worked before but broke after a new change, such as login failing after a profile page update. It is usually treated with higher priority because it affects existing users. In Jira, add a label such as regression, set the affected version and link it to the story or change that caused it. Tracking these labels over time shows where regression coverage is weak.
23
Your test repository has many duplicate and outdated test cases. How do you clean it up?
Export the cases and group them by module and requirement. Mark duplicates, merge them into one well-written case, and retire cases for removed features. Check which cases have not been executed or failed in months and confirm whether they are still valid. Link the remaining cases to requirements so gaps are visible. Do it module by module with peer review, and set a rule that every story update also updates its test cases.
24
How is back-end database testing different from front-end UI testing?
UI testing checks what the user sees and does: screens, buttons, messages and flows. Database testing checks what happens underneath: whether the right rows are inserted, updated or deleted, whether constraints hold and whether data stays consistent across tables. A screen can show a success message while the database saved a wrong amount or nothing at all. So testers combine both, using SQL to confirm that every important UI action leaves the database in the expected state.
25
Tell me about a disagreement with a developer about a bug's severity.
Model answer: Situation: I logged a bug where the invoice PDF showed the wrong GST number, and the developer marked it minor because the screen value was correct. Task: get the right priority. Action: I explained that customers use the PDF for tax filing and showed the requirement. Result: the product owner agreed it was major, it was fixed before release, and we added PDF checks to regression.
26
A page loads slowly only for some users. How do you investigate as a manual tester?
Collect details from affected users: location, device, browser, network and time. Try to reproduce with similar conditions using browser network throttling. Use the browser developer tools network tab to find slow requests, large files or failing calls, and compare with a fast user. Check whether those users have more data, like a long order history. Share the slow request, timing and conditions in the bug for the developers.
27
An automated test keeps failing because an element's ID is generated differently on every build. What do you do?
Stop using the dynamic ID. Look for a stable alternative: the element's role and visible name, its label, a stable attribute, or a relative locator based on a nearby fixed element. The best long-term fix is asking developers to add a data-testid attribute. Avoid partial matches on random strings, which can break again. Then update the locator in the page object so every test using it is fixed at once.
28
How would you test a web page you have never seen before in 30 minutes?
Spend five minutes understanding its purpose and main user flows. Then run a quick smoke check of the main flow end to end, test key inputs with valid, invalid and boundary values, check links, buttons and error messages, and try the page on a second browser and a mobile width. Keep short notes and take screenshots as you go. Report the top issues by risk at the end, not every small cosmetic point.
29
What is the difference between retesting and regression testing?
Retesting, or confirmation testing, checks that a specific bug that was fixed now works, using the same steps as the original bug. Regression testing checks that the fix or a new change has not broken other, previously working features. Retesting is planned for failed cases only, while regression covers a wider set of passing cases. Retesting usually comes first, then regression around the changed area.
30
Describe how you contributed in a sprint retrospective to improve quality.
Model answer: Situation: our sprints kept ending with stories stuck in testing. Task: suggest a fix in the retrospective. Action: I showed that most stories reached QA in the last two days and proposed smaller stories, early test case sharing and developers deploying to QA daily. Result: the team tried it next sprint, and the number of stories carried over dropped from five to one.
Open the dialog with the keyboard. Focus should move into it, usually to the first field or heading, and the screen reader should announce it as a dialog with its title. Tab must stay inside the dialog while it is open and the page behind must not be reachable. Escape and the close button should close it, and focus must return to the button that opened it. Also check it reads correctly when zoomed.
32
What is the difference between DELETE and TRUNCATE?
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.
34
A training portal is adding recorded video lessons and podcasts. What accessibility checks do you run?
Check that prerecorded videos have accurate, synchronised captions, not just auto-generated ones with errors, and that audio-only content like podcasts has a transcript. Important visual information that is not spoken should have audio description or be covered in the transcript. Media should not autoplay with sound, and player controls must work by keyboard and be announced by screen readers. Also check that nothing flashes more than three times per second.
35
How do you decide which automated tests run on every pull request and which run nightly?
Pull request checks must be fast, usually under ten to fifteen minutes, and highly reliable, so they include unit tests, API tests for changed services and a small UI smoke set of critical flows. The full UI regression, cross-browser runs, long data-driven suites and performance checks run nightly or before release. Tag tests by suite, measure run times and flakiness, and move tests between suites based on value and speed.
36
The UI shows the correct order total, but the database has a different value. What do you check?
Note the order ID and compare the UI value, the API response and the database value to find where they differ. Check if the UI calculates the total on the screen instead of using the saved value, whether taxes, discounts or rounding are applied at different layers and whether a later update job changed the record. Log the bug with all three values, because invoices and reports will use the database figure.
Few big employers listed in Visakhapatnam?
Many Visakhapatnam candidates also apply to teams in Hyderabad and to remote or hybrid roles. Practise the Hyderabad set as well.
Which companies hire Software Testing professionals in Visakhapatnam?
Companies with large offices in Visakhapatnam include many IT services and product firms. Use their company pages below to practise employer-specific sets.
Are Software Testing interviews in Visakhapatnam different from other cities?
The questions depend more on the company than the city. Visakhapatnam's mix of employers decides the style: Many local candidates also apply to Hyderabad and remote roles, so a mix of service and product styles is common
How do I find Software Testing jobs in Visakhapatnam?
Shortlist companies with Visakhapatnam offices, keep your CV focused on Software Testing projects, apply on company career pages and job portals with the Visakhapatnam filter, and practise the questions on this page before each interview.