Intuit Software Testing Interview Questions & Answers

Unit, integration, system and acceptance testing, moving from individual components to the complete product in front of users.

Positive cases use valid inputs to confirm expected behaviour; negative cases use invalid inputs to confirm the system handles errors gracefully.

A regular review where QA, development and product assess new bugs and decide severity, priority, owner and target release.

Assess impact and risk, discuss with product and dev, decide to fix, defer with a workaround or delay release, and document the decision.

A final document summarising what was tested, defects found and open, metrics, lessons learned and the recommendation for release.

Defects found after release that testing should have caught; leakage % = defects in production / total defects x 100.

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

Verifying the application works across different hardware, software and settings combinations.

A set of steps with inputs and expected results. Components: ID, title, preconditions, steps, test data, expected result, actual result and status.

A human error causes a defect in the code, and when that defect is executed it produces a failure visible to users.

A language to query databases. Testers use it to verify data saved by the application, prepare test data and check backend results.

Keep tests modular, prioritise by risk, use exploratory testing, automate stable parts and keep close contact with product owners.

The observation that a small number of modules contain most defects, so testing should focus on those areas.

The hardware, software, data and configuration where testing happens, set up to mirror production as closely as practical.

Finding why a defect was introduced, such as unclear requirements or missed reviews, to prevent similar defects in future.

DELETE removes selected rows and can be rolled back; TRUNCATE quickly removes all rows and resets the table.

Success, failure and pending flows, timeouts, refunds, double-click payments, every method (UPI, cards, net banking), rounding, security (no card data stored) and reconciliation with bank reports.

Learning, test design and execution at the same time, without scripted cases — time-boxed sessions with a charter (e.g. 'explore checkout with coupons'), noting bugs and ideas. Great for finding edge cases.

Use mocks or stubs from the API contract such as Swagger, write test cases early and validate again when the real service is available.

Code is built and tested automatically on each change; tests are quality gates that stop faulty builds from moving forward.

They let testers verify totals and counts per category, such as the number of orders per customer, and compare them with the UI or reports.

Smoke testing checks that the critical features of a new build work (broad and shallow). Sanity testing checks that a specific fix or area works after a change (narrow and deep).

A document defining scope, approach, resources, schedule, entry and exit criteria, risks and deliverables of testing.

For a field accepting 1–100: valid class 1–100 (test 50), invalid below 1 (test −5), invalid above 100 (test 150). One value represents each class.

Functional testing checks what the system does (login, checkout). Non-functional testing checks how well it does it (performance, security, usability, compatibility).

200 OK, 201 Created, 204 No Content, 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error.

Static testing reviews documents and code without executing; dynamic testing executes the software to observe behaviour.

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

A team meeting at the end of a sprint to discuss what went well, what did not and what to improve next.

Check SQL injection, brute-force lockout, password masking, session timeout, HTTPS, cookie flags, error messages not revealing users and password reset flow.

Reproduce and assess impact, inform stakeholders, help developers fix and verify in staging, run regression and check monitoring after the hotfix, then do a post-mortem.

Status code, response body and schema, headers, response time, error messages for invalid input, authentication (401/403) and that data is saved in the database.

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.

The extent of requirements or code exercised by tests. Measure requirement coverage with a traceability matrix and code coverage with tools.

Test 17, 18, 19, 59, 60 and 61.

Risk-based testing: cover critical user flows, recent changes and high-defect areas first. Clearly communicate the untested risks and get stakeholder sign-off.

Prioritising tests by the likelihood and impact of failure, so critical areas get the most coverage when time is limited.

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.

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

Entry criteria are conditions that must be met to start testing (build ready, environment set); exit criteria define when testing can stop (pass rate, no critical defects).

A defect that stops testing or release of a feature because no workaround exists, so it is highest priority.

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

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.

By business criticality, usage frequency, defect history, risk and dependencies, running high-priority cases first.

Verification: are we building the product right? (reviews, walkthroughs — no code run). Validation: are we building the right product? (actual testing against user needs).

Statuses like To Do, In Progress, In Review, Ready for QA, Done and Reopened, with transitions that depend on the team's configuration.

SDLC is the full software development life cycle; STLC is the testing life cycle: requirement analysis, test planning, test design, environment setup, execution and closure.

Re-check the requirement, reproduce with clear steps and evidence (screenshots, logs), discuss with the BA/PO and record the final decision.

Clear, concise, independent, repeatable, traceable to a requirement, with precise expected results and tested data.

TDD writes unit tests before code to drive design; BDD describes behaviour in business language scenarios that become automated acceptance tests.

Peer review for clarity, coverage of requirements, correct expected results, test data and traceability, then update and baseline them.

Checking the application works across browsers, devices, operating systems, screen sizes and network conditions.

Checking that people with disabilities can use the product, using screen readers, keyboard navigation, colour contrast and WCAG guidelines.

A scenario is a high-level thing to test (user logs in); test cases are the detailed steps and data that verify it.

A model with many fast unit tests at the base, fewer API or integration tests in the middle and a small number of UI tests at the top.

New → Assigned → Open → Fixed → Retest → Verified → Closed, with Reopened, Rejected, Deferred and Duplicate as side paths.