Mu Sigma Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About Mu Sigma hiring for Software Testing roles
Mu Sigma is a decision science and analytics company with its main delivery centre in Bengaluru. It works with large enterprises on analytics problems in areas like marketing, supply chain and risk. It typically hires freshers as trainee decision scientists, with a selection process known for aptitude, puzzles and group discussions.
For Software Testing roles, this Mu Sigma practice set focuses most on Accessibility & Usability Testing (6), Test Case Design (5), STLC and Test Planning (5), Mobile Testing (4). It has 1 easy, 31 medium, 8 hard questions, so you can start easy and work up to the harder ones.
Company type
Analytics
Headquarters
Northbrook, Illinois, USA
Main India offices
Bengaluru
Mu Sigma Software Testing interview process
Online assessment (aptitude + reasoning)
Video or written communication test
Group discussion
Technical and HR interview
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for Mu SigmaStart 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.
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.
03
What is the pesticide paradox and how do you counter it?
The pesticide paradox says that if you run the same tests again and again, they stop finding new defects, just as pests become resistant to the same pesticide. To counter it, regularly review and update test cases, add new scenarios from recent production bugs, vary test data, and mix scripted runs with exploratory sessions. Rotating testers across modules also brings fresh eyes and new ideas.
Model answer: Most users in India now use services first on their phones, so mobile quality directly affects customers. In my project I tested a college event app on four phones and found that the registration button was hidden by the keyboard on small screens. Fixing it raised sign-ups. I enjoy the variety of devices, networks and real-life situations that mobile testing involves.
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.
08
What is the difference between a test strategy and a test plan?
A test strategy is a high-level document, often at organisation or product level, that defines the general approach: test levels, types, tools, environments, automation approach and standards. It changes rarely. A test plan is project or release specific: scope, schedule, resources, entry and exit criteria, risks and deliverables. The plan follows the strategy and applies it to a particular release.
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.
12
How would you add basic security testing to a team that has no security process?
Start with low-cost steps. Add an OWASP-based security checklist to the definition of done for stories touching login, payments or personal data. Train testers on access control, injection and session checks. Add automated dependency and vulnerability scans to the CI pipeline. Include negative authorization tests in API suites. Arrange a penetration test before major releases and track security bugs separately with clear severity rules.
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.
15
What is the difference between a test suite and a test run?
Talk to developers and users, explore the product, review similar systems, create notes and mind maps, confirm assumptions and write test cases as you learn.
17
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.
18
How do you test touch target size and gestures for accessibility in a mobile app?
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.
19
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.
20
How would you choose a device matrix for testing an app in India?
Use the app's analytics, or market data if it is a new app, to find the top devices, OS versions and screen sizes. In India, cover a strong share of budget and mid-range Android phones with low RAM, a few manufacturers' custom Android skins, the two or three latest Android versions, and recent iPhones if iOS is supported. Add a tablet if relevant. Review the matrix each quarter and use a cloud device lab for wider coverage.
21
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.
22
Search works fine in QA but is very slow in production. Could a missing database index be the reason, and how do you check?
Yes, very likely. An index lets the database find rows quickly, like the index of a book. With a small QA table, a full table scan is still fast, but with millions of production rows it becomes slow. Compare indexes on the searched columns in both environments and ask a developer to check the query plan. Test key queries on production-size data in staging, and include data volume in future performance checks.
23
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.
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.
25
What is the difference between statement coverage and branch coverage?
Statement coverage measures the percentage of code statements executed by tests. Branch coverage measures whether every decision outcome, true and false, has been executed. Branch coverage is stronger: for 'if (amount > 1000) applyDiscount()', one test with 1500 gives 100 percent statement coverage, but you need a second test with 500 to cover the false branch. 100 percent branch coverage implies 100 percent statement coverage, not the other way round.
26
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.
27
A feature passed all your test cases, but users say it is confusing. What went wrong?
The tests verified the specification but did not validate the user experience. The test cases probably checked only functional outcomes and missed usability: unclear labels, too many steps or poor error messages. Next time, add usability heuristics to reviews, do exploratory sessions as a real user persona and involve users in UAT or demos. Log the current feedback as improvement items with clear examples.
28
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.
29
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.
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.
31
A report shows duplicate rows after a new release. How do you investigate in the database?
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.
32
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.
Severity is impact on the system; priority is urgency of the fix. A crash in a rare report is high severity, low priority; a spelling mistake in the logo is low severity, high priority.
SUS is a standard ten-question survey that users answer on a five-point agree to disagree scale after using a product. The answers are converted to a score from 0 to 100. A score around 68 is considered average, above about 80 is good and below 50 signals serious usability problems. It is quick and comparable across releases, but it gives a score, not reasons, so teams pair it with observation notes.
35
A CAPTCHA on the signup page blocks screen reader users. What do you recommend?
Log it as a high-severity accessibility bug because it fully blocks a group of users from signing up. An image-only CAPTCHA fails WCAG unless an alternative is offered. Recommend options such as invisible or risk-based bot checks, an email or OTP verification step, an audio alternative plus another modality, and rate limiting on the server. Retest the full signup with NVDA and TalkBack after the change.
A QA lead reviews requirements and plans testing, including scope, estimates, resources and risks. They assign work, set standards for test cases and bug reports, and review test artefacts. During execution, they track progress, run triage and remove blockers. At the end, they give a clear release recommendation, prepare closure reports and drive lessons learned. They also mentor the team and improve the process over time.
37
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.
38
Write a simple Playwright test in TypeScript that logs in and checks the dashboard heading.
Backward compatibility testing checks that a new version still works with older versions of things it depends on or that depend on it. Examples: a new app version opens files and data created by the old one, a new API version still serves older mobile app versions that users have not updated, and an upgraded database keeps old records readable. It prevents breaking existing users when only some parts of the system are upgraded.
40
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.
Tips to crack the Mu Sigma Software Testing interview
Practise puzzles, logical reasoning and quantitative aptitude, which feature prominently in Mu Sigma assessments.
Prepare for group discussions by practising structured arguments on business and analytics topics.
Learn basic analytics concepts and show curiosity about solving ambiguous problems, which Mu Sigma emphasises.
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; Mu Sigma interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the Mu Sigma Software Testing interview?
Candidates usually go through 4 stages: Online assessment (aptitude + reasoning); Video or written communication test; Group discussion; Technical and HR interview. 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 Mu Sigma Software Testing interview?
This practice set leans on Accessibility & Usability Testing (6), Test Case Design (5), STLC and Test Planning (5), Mobile Testing (4). Revise those first, then practise explaining one or two of your own projects end to end, because most Mu Sigma interviewers ask you to walk through real work.
Are these the exact questions asked at Mu Sigma?
No. These are curated practice questions that match the skills and difficulty usually tested in analytics interviews like Mu Sigma's. They are not a leaked or verified list of past questions.
Where does Mu Sigma hire Software Testing professionals in India?
Mu Sigma has large teams in Bengaluru. Openings and locations change often, so check the Mu Sigma careers page and filter by city and experience.