Practical Software Testing Interview Questions

Verify inserted, updated and deleted rows match UI actions, check constraints, duplicates, NULLs and totals with COUNT and SUM queries.

Basic operations, division by zero, decimals, large numbers, order of operations, clear and backspace, repeated operations and memory keys.

Add, remove, update quantity, price and tax calculation, coupon codes, stock limits, cart persistence after login and checkout navigation.

Allowed and disallowed formats, size limits, empty file, duplicate names, special-character names, cancel upload, slow network and multiple files.

Send page, size, sort and filter parameters, then verify counts, order, boundaries (first, last, empty page) and invalid parameter handling.

Valid keyword, partial match, no results, special characters, very long text, empty search, case sensitivity, spelling errors, suggestions and speed of results.

Valid transfer, insufficient balance, daily limit, wrong beneficiary, OTP failure, network drop mid-transaction, duplicate click and statement update.

Mandatory fields, email format, password rules, duplicate email, terms checkbox, captcha, confirmation email and field length limits.

Moves to the chosen floor, doors open and close, door sensor stops closing on obstruction, overload alarm, emergency button, behaviour in a power cut, max capacity and the floor display.

Valid card and PIN, wrong PIN, three failed attempts, amount above balance, amount above daily limit, invalid denomination, machine out of cash, network failure and receipt printing.

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.

Check access with valid, expired and missing tokens, role-based permissions, error codes and that sensitive data is never exposed.

Create a request with method, URL, headers and body, send it, check status and body, add test scripts and save it in a collection.

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.

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.

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.

Length partitions: below 8 (invalid), 8 to 16 (valid), above 16 (invalid). Boundaries: 7, 8, 9, 15, 16 and 17 characters. Digit partitions: contains a digit (valid), no digit (invalid). Sample tests: 'abc1234' with 7 characters is rejected, 'abcdefg1' with 8 is accepted, a 16-character value with a digit is accepted, 17 characters is rejected, and 'abcdefgh' with no digit is rejected. Also test empty input and spaces.

Verify reset with a registered email sends a link. Verify an unregistered email shows a generic message without revealing whether the account exists. Check the link opens the reset page and expires after the defined time. Check the link works only once. Validate new password rules and that confirm password must match. Verify login works with the new password and fails with the old one. Check resend limits and that other sessions are logged out.

Verify a correct OTP within validity logs the user in. Verify a wrong OTP shows an error and an expired OTP is rejected. Check the OTP length and that only digits are allowed. Test resend: it is disabled during the countdown, and the old OTP stops working after resend. Check the maximum number of wrong attempts locks verification. Verify auto-read on mobile, paste support, and behaviour when the network drops during submission.

Apply a valid coupon and check the discount and final amount. Test invalid, expired and not-yet-active coupons. Check minimum order value, maximum discount cap and category restrictions. Verify one-time-use coupons cannot be reused and that only one coupon applies if stacking is not allowed. Check case sensitivity and leading or trailing spaces. Remove the coupon and confirm the total resets. Change cart items after applying and verify the discount is recalculated.

Verify a valid date is accepted and saved in the right format. Check the minimum age rule, such as 18 years, using boundary dates of exactly 18 today and one day short. Reject future dates and impossible dates like 30 February. Test leap year dates like 29 February 2004. Check manual typing and the picker give the same result, the field is mandatory if required, and the date displays correctly after saving.

First ask what type of pen and who the users are. Functional: it writes smoothly, ink flows without leaking, the cap or click mechanism works and the ink colour matches the label. Non-functional: comfort of grip, writing length before ink runs out, performance at different temperatures and on different paper. Negative: dropping it, pressing hard, leaving it uncapped. Safety: the cap is non-toxic and has an air hole. This shows structured thinking, not just a list.

Send and receive text messages and check order and timestamps. Test sent, delivered and read status. Send emojis, long messages, links and attachments within and over the size limit. Check messages sent while offline are queued and delivered on reconnect. Verify blocking a user stops messages. Test notifications when the app is in background. Check chat history after reinstall or on a second device, and that deleted messages disappear for both users if supported.

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.

A duplicate bug is a new report for a problem that is already logged. Before raising a bug, search the tracker by key words, module, error message and recent open bugs, and ask teammates working on the same area. If a similar bug exists, add your extra information, such as another browser or data set, as a comment instead of a new ticket. This keeps the backlog clean and saves triage time.

Save filters for common views such as my open bugs, bugs ready for retest, blockers in the current sprint and bugs by fix version. Add them to a dashboard with gadgets like pie charts by priority, created versus resolved trend and a sprint bug list. Share the dashboard with the team so status is visible without manual reports. Testers start their day from the ready-for-retest filter.

Create test cases as linked issues or in a test management add-on and link each one to its story with a tests relationship. When a test fails, create the bug from the test execution or link it to both the test and the story with is blocked by or relates to. Use the same fix version for all. A story then shows its tests and open bugs, which makes sign-off and the traceability report easy.

Start with preconditions: environment, build number, user role and the exact data state, such as an account with two pending orders and zero wallet balance. Mention how to create the data or give the test account ID. Then list numbered steps with exact inputs and finish with expected and actual results. If the data is hard to set up, attach the SQL used or a database screenshot so the developer can recreate it quickly.

Use analytics to pick browsers and versions that most real users have, plus the ones listed in the requirement, usually the latest two versions of major desktop and mobile browsers. Run the main flows on each and check layout, fonts, forms, date pickers, file upload and JavaScript errors in the console. Use responsive mode for screen sizes, and real devices or a cloud device lab for mobile browsers.

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.

Check alignment, spacing, fonts, colours and images against the design. Verify text is not cut off or overlapping, buttons and links look clickable and show hover and disabled states, and error messages appear in the right place. Check responsive behaviour on different screen widths and zoom levels. Confirm icons and images load and have alt text. Compare with the design file and take screenshots for any differences.

Include the date, build or release, and planned versus executed test cases with pass, fail, blocked and not run counts. List new bugs by severity, open critical bugs with owners, retests done and any blockers such as environment downtime or missing data. Add a short note on risk and the plan for the next day. Keep it to one page so managers can read it in two minutes.

Three-point estimation uses an optimistic (O), most likely (M) and pessimistic (P) estimate for each task. The weighted formula is (O + 4M + P) divided by 6. If testing a module would take 4 days at best, 6 days most likely and 14 days at worst, the estimate is (4 + 24 + 14) / 6 = 7 days. It includes uncertainty in a single number and is often combined with a work breakdown of test activities.

In sprint planning, review each story's acceptance criteria and estimate test effort, including test data and regression. Write test cases in the first days while development starts. Ask for early builds so testing is spread across the sprint, not crowded at the end. Keep time for regression and bug retesting in the last two or three days. Track progress on the board and raise risks in stand-up.

Keep a tiered regression suite: a smoke set for every build, a core set of critical flows for every release and a full set run on a rotation or before major releases. Each month, add impact-based tests from the release changes and cases for recent production bugs. Automate stable, repeated cases and keep manual effort for new or changing areas. Schedule regression early enough to fix and retest found issues.

Execution progress = test cases executed divided by total planned test cases, multiplied by 100. Pass rate = test cases passed divided by test cases executed, multiplied by 100. For example, if 200 cases are planned, 150 are executed and 120 passed, progress is 75 percent and pass rate is 80 percent. Report blocked cases separately because they are neither passed nor failed.

Check that the app asks for permission only when the feature is used, with a clear reason. Test allow, deny, and deny with do not ask again. When denied, the app must not crash and should explain how to enable it in settings. Revoke permission from settings while the app is in background and return. Test allow only once or only while using the app options on newer OS versions.

Verify notifications arrive when the app is in foreground, background and closed. Check title, text, icon and that tapping opens the right screen with the correct data. Test with notifications disabled at OS level and inside app settings. Check behaviour after logout, reinstall and on multiple devices with the same account. Test grouping of many notifications, time-sensitive ones, and that no notification shows private data on the lock screen.

Install a fresh build and verify first-launch screens and permissions. Test install with low storage. Update from the previous production version and check that login, settings, saved data and offline content are kept and migrations work. Test a forced update prompt if the app has one. Uninstall and reinstall, and confirm local data is cleared while server data returns after login. Check the app size is reasonable.

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.

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.

Test with location permission allowed, denied and approximate only. Use mock location tools to simulate different cities and moving routes. Verify the app shows nearby results correctly, updates location while moving and handles GPS turned off. Check accuracy indoors and with weak GPS, battery impact of continuous tracking and that background location is used only if needed and explained to the user.

Switch the device to dark mode and check every screen: text must remain readable, icons and images visible, and no white flashes during navigation. Switch back while the app is open. Then increase the system font size to the largest setting and confirm text does not overlap or get cut off and buttons remain usable. Also test display size or zoom settings and both orientations.

Open developer tools and use the network tab with cache disabled to see each request's size and time, and the total load time. Look for very large images or scripts, slow API calls and requests that fail or repeat. Use throttling to simulate slow 3G or 4G. Run the built-in performance audit tool to get scores for load speed and suggestions. Record the numbers so you can compare with later builds.

Check that a new session ID is created after login, and that the session expires after the defined idle time. Verify logout invalidates the session on the server, so pressing back or reusing the old cookie does not work. Check that cookies use Secure, HttpOnly and SameSite flags. Test concurrent logins if they are limited, and that changing the password ends other sessions. Session IDs must not appear in URLs.

Try passwords that break each rule: too short, no digit, no special character and common passwords, and check clear messages. Verify the password is masked and not shown in the URL or logs. Enter the wrong password up to the limit and confirm the account locks for the defined time or until reset. Check that the error message does not reveal whether the username exists and that the lockout counter resets after a successful login.

Check that responses return only needed fields, with no passwords, password hashes, full card numbers, full ID numbers or internal keys. Verify personal data is masked where required, for example only the last four digits of a phone number. Look at application and browser console logs for tokens or personal data. Check error responses do not expose stack traces, SQL or server versions. Raise any leak as a high-severity bug.

First read what the trigger should do and when it fires, such as AFTER UPDATE on the salary column writing a row to an audit table. Then perform the event that should fire it and query the target table to confirm the expected row and values. Also perform events that should not fire it and confirm nothing happens. Check multi-row updates, NULL values and rollback: if the main statement fails, the trigger's changes must not remain.

Get the migration script or change list. Compare the schema before and after: new tables and columns, data types, lengths, default values, NULL rules, indexes and constraints. Check that existing data was migrated correctly, for example a new status column filled for old rows. Run the main app flows to confirm queries still work. Finally, confirm the rollback script works on a copy, so the release can be reversed safely.

Create your own data with a clear prefix or tag, such as emails starting with qa_ravi_, or IDs in a reserved range. Insert data through the app or API where possible so it follows real rules, and keep SQL setup scripts in version control. After testing, delete only your tagged rows, or run inside a transaction and roll back. Never edit shared master data without telling the team.

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.

Put the mouse away. Press Tab and Shift+Tab to move through every link, button and field, and check that the order is logical and the focus outline is always visible. Use Enter and Space to activate buttons and links, arrow keys for menus, radio groups and sliders, and Escape to close dialogs. Check that nothing traps focus, hidden items do not receive focus and a skip to main content link works.

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.

Check that every field has a visible label tied to it, so clicking the label focuses the field and a screen reader announces it. Required fields must be indicated in text, not only by colour or an asterisk without explanation. Submit with errors and check that messages are specific, appear next to the field, are announced by the screen reader and focus moves to the first error. Also check autocomplete for name, email and address.

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.

Set browser zoom to 200 percent and check that all text is readable and no content or buttons are cut off. Then zoom to 400 percent, or use a 1280 pixel wide window, which gives a 320 CSS pixel viewport; content should reflow into one column without horizontal scrolling, except for things like data tables and maps. Also increase text spacing and the operating system font size to check that labels do not overlap.

Define goals and three to five realistic tasks, such as 'Book a train ticket for next Friday'. Recruit participants who match real users. In the session, explain that you are testing the product, not them, ask them to think aloud, and avoid hinting even when they struggle. Record the screen with consent, note where they hesitate or fail, and finish with a short questionnaire. Then group findings by severity and frequency.

Give a clear title, such as 'Checkout: Place Order button not reachable by keyboard'. Include the page URL, browser, operating system and assistive technology with versions. Write exact steps, what was announced or happened, and what was expected. Add the WCAG success criterion, such as 2.1.1 Keyboard, and the user impact. Attach a screenshot or audio recording, and suggest a fix when obvious. Severity should reflect whether users are fully blocked.

Check that buttons and icons are large enough to tap without hitting neighbours: Android guidance is 48 by 48 dp and iOS is 44 by 44 points. Test with large font settings and one-handed use. Any action using complex gestures, such as swipe to delete or pinch, must have a simple tap alternative. Then turn on TalkBack and VoiceOver and confirm each control can be focused, named and activated.

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.

Send requests with missing required fields, wrong data types, values beyond limits, invalid formats such as a bad email, unknown fields and an empty or malformed JSON body. The API should return a 4xx code such as 400 or 422, a clear error message that names the field, and no stack trace or database details. Also check that nothing was partly saved in the database after the failed request.

Pick a small set of stable, high-value regression cases first. Review each one: make steps precise, remove judgement-based checks and define clear expected results. Prepare test data that the script can create and clean up. Build reusable page objects and helpers for common steps like login. Automate, run several times to confirm stability, then link each script to its manual case ID and mark the manual case as automated.

Start with: git clone to copy the test repository; git pull to get the latest changes; git checkout -b feature/login-tests to create a branch; git status and git diff to see changes; git add and git commit -m to save work with a message; and git push to send the branch so you can raise a pull request for review. Also learn to resolve simple merge conflicts and never commit passwords.

Most frameworks support this through configuration. In Playwright, set screenshot to only-on-failure, video to retain-on-failure and trace to on-first-retry in the config, then open the trace viewer to step through actions, network calls and the page state. In Selenium, call save_screenshot in a teardown hook when a test fails. Store these artefacts in CI so anyone can debug the failure without rerunning it.