IBM Software Testing Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About IBM hiring for Software Testing roles
IBM is a global technology company offering hybrid cloud, AI through watsonx, software such as Red Hat, infrastructure and IBM Consulting services. Its India Software Labs and IBM Consulting teams form one of its largest workforces outside the US. It hires in India for software developers, test engineers, data engineers, data scientists and consultants.
For Software Testing roles, this IBM practice set focuses most on STLC and Test Planning (9), Bug Life Cycle and Jira (5), Testing Types (4), Test Case Design (4). It has 18 easy, 22 medium questions, so you can start easy and work up to the harder ones.
Company type
IT services
Headquarters
Armonk, New York, USA
Main India offices
Bengaluru, Pune, Hyderabad, Kolkata, Gurugram
IBM Software Testing interview process
Online assessment (cognitive games + coding)
English language test
Technical interview
Managerial or HR round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for IBMStart 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.
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.
04
What is the role of a manual tester in a software team?
A manual tester understands requirements, writes test scenarios and test cases, prepares test data, executes tests on each build, logs clear bug reports and retests fixes. They also do exploratory testing, join stand-ups and reviews, and give a quality status before release. Beyond finding bugs, a good manual tester represents the end user and raises usability or requirement gaps early, when they are cheap to fix.
05
What happens in the requirement analysis phase of STLC?
In requirement analysis, the testing team studies the requirements to understand what needs to be tested. They identify testable requirements, clarify doubts with the business analyst or client, decide test types needed, note automation candidates and look at environment needs. The outputs are a list of questions, a requirement traceability matrix draft and an automation feasibility note. Problems found here are the cheapest to fix.
06
How do you test password policy and account lockout?
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.
A test readiness review is a checkpoint before formal test execution starts, where the team confirms everything needed is in place. It checks that the build is deployed and smoke tested, the environment and test data are ready, test cases are reviewed and approved, access and tools work, and entry criteria are met. It prevents wasted days when execution starts and testers discover a missing service or empty database.
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.
11
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.
12
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.
It means that finding and fixing many defects does not guarantee success if the system itself does not meet user needs. A bug-free product built on wrong or misunderstood requirements is still a failure. For example, a perfectly working report that shows the wrong business metric is useless to the client. This is why testers validate against real user expectations, not just the written specification.
14
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.
System testing tests the complete, integrated application against the requirements in an environment close to production. It is done by the testing team after integration testing and before UAT. It covers functional testing of all features plus non-functional aspects such as performance, security, usability and compatibility. It is black box testing, so the tester checks behaviour from the user's point of view without looking at the code.
16
How do you test location-based features in a mobile app?
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.
17
How do you run a moderated usability test session?
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.
Usually yes. Status codes should reflect the result so clients and monitoring can react correctly; an error with 200 can hide failures and break retries. A validation error should return 400 or 422, a missing resource 404 and a server failure 500. Check the API contract first: some legacy APIs document this pattern. If it is not documented, log it as a defect with the request and response attached.
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.
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.
A keyboard trap is when focus moves into a component and the user cannot move out using the keyboard, for example an embedded video player or date picker that captures Tab forever. Mouse users never notice, but keyboard and screen reader users are stuck and must reload the page. It fails WCAG criterion 2.1.2. Test every widget by tabbing in and out, and check that Escape closes popups and returns focus.
Test deliverables are the documents and artefacts produced during testing and shared with stakeholders. Before testing: test plan, test strategy and estimates. During testing: test scenarios, test cases, test data, traceability matrix, execution logs and bug reports. After testing: test summary report, closure report, metrics and lessons learned. The test plan should list which deliverables are expected so nothing is missed at sign-off.
25
Which basic Git commands should a manual tester learn before working on automation?
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.
26
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.
A performance baseline is a set of measurements of the current system under a known load, such as response times, throughput, error rate and resource usage. Every new build or release is compared with it to spot regressions. For example, if the checkout API had p95 of 800 milliseconds at 200 users last release and now shows 1.5 seconds, the change needs investigation. A benchmark compares against an industry or competitor standard.
Defect removal efficiency shows how many defects the team found before release. DRE = defects found before release divided by (defects found before release plus defects found after release), multiplied by 100. If QA found 90 bugs and users reported 10, DRE is 90 percent. A falling DRE means testing is missing more defects, and the escaped bugs should be analysed to improve test coverage.
29
What are components, labels and fix versions in Jira?
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.
30
What is the difference between a test case and a test scenario?
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.
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.
An emulator imitates both the hardware and software of a device, as with the Android emulator, so it behaves close to a real phone. A simulator imitates only the software environment, as with the iOS simulator, and does not reproduce the hardware. Both are free and fast for early testing. Real devices are needed for camera, battery, sensors, actual performance, network behaviour and final sign-off.
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.
39
When should you reopen a bug and when should you log a new one?
Reopen the bug when the same issue, with the same steps and expected result, still fails after the fix. Log a new bug when the fix works but a different problem appears, even in the same screen, or when the original bug has already been closed in a past release. Link the new bug to the old one. Mixing different problems in one reopened ticket confuses tracking and metrics.
40
What is the difference between smoke testing in CI and full regression?
Smoke tests run on every build for quick feedback; full regression runs less often, such as nightly or before release.
Tips to crack the IBM Software Testing interview
Practise IBM's game-based cognitive assessments, which test pattern recognition, memory and numerical reasoning quickly.
Learn basics of hybrid cloud, Red Hat OpenShift and watsonx, which IBM promotes as core strategic areas.
Revise SQL, Python or Java fundamentals and be ready to explain one project in depth.
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; IBM interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the IBM Software Testing interview?
Candidates usually go through 4 stages: Online assessment (cognitive games + coding); English language test; Technical interview; Managerial or 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 IBM Software Testing interview?
This practice set leans on STLC and Test Planning (9), Bug Life Cycle and Jira (5), Testing Types (4), Test Case Design (4). Revise those first, then practise explaining one or two of your own projects end to end, because most IBM interviewers ask you to walk through real work.
Are these the exact questions asked at IBM?
No. These are curated practice questions that match the skills and difficulty usually tested in it services interviews like IBM's. They are not a leaked or verified list of past questions.
Where does IBM hire Software Testing professionals in India?
IBM has large teams in Bengaluru, Pune, Hyderabad, Kolkata, Gurugram. Openings and locations change often, so check the IBM careers page and filter by city and experience.