Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Target hiring for Software Testing roles
Target is a large US retailer operating stores and digital commerce. Target in India, based in Bengaluru, supports technology, data science, supply chain, merchandising and finance for the US business. It hires for software engineers, quality engineers, data engineers, data scientists and business analysts. Most teams work closely with US-based counterparts.
For Software Testing roles, this Target practice set focuses most on Mobile Testing (6), Accessibility & Usability Testing (6), Agile, SQL and API Testing (5), Test Case Design (5). It has 3 easy, 30 medium, 7 hard questions, so you can start easy and work up to the harder ones.
Company type
E-commerce & consumer tech
Headquarters
Minneapolis, Minnesota, USA
Main India offices
Bengaluru
Target Software Testing interview process
Online assessment (coding or analytics)
Technical round 1
Technical round 2 or case round
Hiring manager round
HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for TargetStart 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
Write a Postman test script that checks the status is 201 and the response contains an id.
pm.test('Status is 201', function () {
pm.response.to.have.status(201);
});
pm.test('Response has id', function () {
const body = pm.response.json();
pm.expect(body).to.have.property('id');
pm.expect(body.id).to.be.a('number');
});
02
How do you test a mobile app when the device storage is almost full?
Fill the device storage close to the limit, then install or update the app and confirm a clear message if it cannot proceed. Inside the app, try downloads, photo capture, caching and saving drafts. The app should show a helpful error, not crash or corrupt data. Also check what happens to the local database when a write fails, and whether the app recovers after space is freed.
QA does not decide which version wins, but makes sure the experiment is trustworthy. Verify both variants work end to end, users are split in the agreed ratio, each user sees the same variant consistently across sessions, and analytics events fire correctly for each group. Also check that turning the experiment off returns everyone to the default. A broken tracking event can make the whole experiment's result wrong.
07
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.
Do not copy raw production data into test environments. Use synthetic data generated for the test cases, or masked production data where names, phone numbers, emails, ID numbers and card details are replaced while formats and relationships are kept. Restrict access to test databases and record the data rules in the test plan. This keeps testing realistic and follows India's data protection law and company policy.
10
How do you test battery and memory usage of a mobile app?
Run typical user sessions on a real device and measure battery drain, CPU and memory with platform profiling tools or the device's battery statistics. Compare with the previous version. Look for background work continuing after the app is closed, GPS left on, frequent network polling and memory that keeps growing, which signals a leak. Test on low-RAM devices too, where the OS kills heavy apps quickly.
Data-driven testing runs the same test steps many times with different input and expected values taken from a table, CSV, JSON or spreadsheet. For example, one login test can run with valid users, locked users, wrong passwords and blank fields. It reuses the logic, makes adding cases easy and maps well to equivalence partitioning and boundary values from manual design. Tools support it through parameterised tests, such as pytest.mark.parametrize.
12
How do you test form accessibility, including labels and error messages?
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.
13
A screen reader announces 'button, button, button' on a toolbar. What is the bug and how do you report it?
The toolbar uses icon-only buttons without accessible names, so users hear the role but not the purpose. Report it with the page, the screen reader and browser versions, the exact announcement and the expected one, such as 'Bold, toggle button, not pressed'. Reference WCAG 4.1.2 Name, Role, Value. The fix is an aria-label or visually hidden text on each button, plus a tooltip that also helps sighted users.
14
What is a go or no-go meeting and what does QA present?
A go or no-go meeting is held before release to decide whether to deploy. QA presents test coverage against scope, pass and fail counts, open defects by severity with their impact, known issues and workarounds, any untested areas and the overall risk. QA gives a recommendation, but the business owner decides. The decision and accepted risks should be recorded in the meeting notes.
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.
16
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.
17
Design EP and BVA tests for a password that must be 8 to 16 characters and contain at least one digit.
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.
18
SQL: check that no user has more than one active subscription.
-- Business rule: at most one ACTIVE subscription per user
SELECT user_id, COUNT(*) AS active_count
FROM subscriptions
WHERE status = 'ACTIVE'
GROUP BY user_id
HAVING COUNT(*) > 1;
-- Expected result: no rows
Situation: a wallet refund screen showed success for every test. Task: I wanted to confirm the balance logic. Action: I queried the wallet_transactions table and saw two refund rows when I double-clicked the submit button, though the UI showed one. I logged it with both query outputs and the steps. Result: developers added an idempotency key, and the team added a database check to our regression checklist.
21
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.
22
A user fills a long form, switches to another app and comes back. What should you test?
Check that the form data is still there when the user returns after a few seconds and after a longer time. Test when the OS kills the app in background due to low memory, which you can force with developer options, and confirm the app restores state or at least warns the user. Also check session timeout behaviour and that sensitive screens are hidden in the recent apps view if required.
Mutation testing measures the quality of a test suite. A tool makes small changes, called mutants, to the code, such as changing greater than to greater than or equal, and runs the tests. If a test fails, the mutant is killed; if all tests still pass, the mutant survived, which shows a weak spot in the tests. The mutation score is killed mutants divided by total mutants. It is strong but slow, so teams apply it to critical modules.
Defect age is how long a defect stays open, measured either in time, from the date it was logged to the date it was closed, or in phases, from the phase where it was introduced to the phase where it was found. High defect age signals slow fixing or triage. Phase-based age shows how late defects are caught; a requirement defect found in UAT has a high age and is costly.
25
Which accessibility laws and standards matter for products used in India and abroad?
In India, the Rights of Persons with Disabilities Act 2016 requires accessible information and communication technology, and government sites follow the GIGW guidelines, which align with WCAG. Abroad, the US uses the ADA and Section 508, Europe uses EN 301 549, and the European Accessibility Act applies to many digital products and services from June 2025. Most of these point to WCAG AA as the practical testing target.
26
Why is orientation and screen size testing important?
Mobile users have many screen sizes, resolutions, notches and foldable screens, and they rotate their phones. Rotation can recreate the screen and lose entered data if not handled. Test portrait and landscape on key screens, small and large phones and tablets, and check text does not cut off, buttons stay reachable and the keyboard does not hide input fields. Check entered form data survives rotation.
27
How do you test API error handling for invalid input?
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.
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.
29
Your automated accessibility scan shows zero errors. Is the page accessible?
Not necessarily. Automated tools catch only a part of WCAG issues, such as missing labels and contrast. A clean scan still needs manual checks: keyboard-only navigation, focus order, a screen reader pass, meaningful alt text and link names, error handling, zoom and reflow and dynamic content. Report the result as 'no automated violations found' and add the manual checklist outcome before claiming conformance.
30
A web app gets slower the longer a user keeps it open. How do you check for a memory leak as a manual tester?
A memory leak happens when an application keeps holding memory it no longer needs, so usage grows the longer it runs. A manual tester may notice the app getting slower over a long session, a browser tab using more and more memory in Task Manager or the browser's memory panel, or a mobile app crashing after repeatedly opening and closing a screen. Report the steps, duration and memory readings over time.
31
How do you plan testing for a feature that depends on a third-party service?
Identify the integration points and the service's sandbox, limits and test data. Plan to test with a mock or stub early for our logic and error handling, then against the real sandbox for integration. Include failure scenarios: timeout, slow responses, invalid data and the service being down. Add the dependency to the risk list, with contacts and a fallback plan, and confirm production credentials and monitoring before go-live.
32
Tell me about a time you found a usability problem that the requirements did not mention.
Situation: while testing a leave application form, every test case passed. Task: I still felt the flow was confusing. Action: I noticed the date picker started on Sunday and the half-day option was hidden under 'More', so I asked two colleagues to apply for leave while I watched; both made mistakes. I logged a usability suggestion with notes. Result: product moved the option and support queries dropped.
33
SQL: how do you test a foreign key defined with ON DELETE CASCADE?
-- Create a parent and child, delete the parent, child rows must disappear
INSERT INTO customers (id, name) VALUES (501, 'Cascade Test');
INSERT INTO orders (id, customer_id, total) VALUES (7001, 501, 250);
DELETE FROM customers WHERE id = 501;
SELECT COUNT(*) FROM orders WHERE customer_id = 501;
-- Expected: 0
-- Also test inserting an order for a non-existent customer: it must fail
34
What is mobile app testing and what extra checks does it need?
A bug bash is a short, time-boxed session where people from across the team, including developers, product and support, test the product together to find as many issues as possible before a release. To run one, share a build, scope and test accounts, assign focus areas, give a simple bug template and a shared board, then triage findings at the end. It brings fresh eyes and finds usability issues formal tests miss.
Cause-effect graphing is a black box technique that models input conditions (causes) and output actions (effects) with logical relations like AND, OR and NOT. The graph is converted into a decision table, and each column becomes a test case. It is useful when outputs depend on combinations of inputs, such as loan approval based on income, age and credit score. It helps find missing or contradictory rules in the requirement.
38
What is the difference between a known issue and an open bug at release time?
An open bug is any defect not yet resolved. A known issue is an open bug that the team has consciously agreed to release with, after assessing its impact, and has documented in release notes or support notes, often with a workaround. Every known issue is an open bug, but not every open bug should ship. QA makes sure known issues are listed and approved by the product owner.
39
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.
40
What is the difference between a defect and a production incident?
A defect is a flaw in the software that makes it behave differently from the requirement, whether found in testing or production. A production incident is an event that disrupts or degrades service for users, such as an outage or a failed payment flow. An incident may be caused by a defect, but also by infrastructure, configuration or third-party failures. Incidents are handled by an incident process first, then linked to defects for the fix.
Tips to crack the Target Software Testing interview
Prepare retail cases on store inventory, promotions and same-day delivery services like Drive Up and Order Pickup.
Practise SQL and Python on sales and inventory data, including forecasting basics.
Read about Target's values and its focus on guest experience to support behavioural answers.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; Target interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Target Software Testing interview?
Candidates usually go through 5 stages: Online assessment (coding or analytics); Technical round 1; Technical round 2 or case round; Hiring manager round; HR round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the Target Software Testing interview?
This practice set leans on Mobile Testing (6), Accessibility & Usability Testing (6), Agile, SQL and API Testing (5), Test Case Design (5). Revise those first, then practise explaining one or two of your own projects end to end, because most Target interviewers ask you to walk through real work.
Are these the exact questions asked at Target?
No. These are curated practice questions that match the skills and difficulty usually tested in e-commerce & consumer tech interviews like Target's. They are not a leaked or verified list of past questions.
Where does Target hire Software Testing professionals in India?
Target has large teams in Bengaluru. Openings and locations change often, so check the Target careers page and filter by city and experience.