Software testing (QA)
30 important interview questions.

Answer

Software testing checks whether an application works as expected and finds defects before users do. It reduces the risk of failures, protects the company's reputation and saves money — bugs found late, in production, cost far more to fix than bugs found early.

Answer

• Verification: "Are we building the product right?" Reviews of requirements, designs and code against specifications, often without running the software.
• Validation: "Are we building the right product?" Running the software to confirm it meets the user's actual needs.

Answer

SDLC (Software Development Life Cycle) covers the whole process of building software: requirements, design, development, testing, deployment and maintenance. STLC (Software Testing Life Cycle) is the testing part: requirement analysis, test planning, test case design, environment setup, test execution and test closure.

Answer

• Error (mistake): a human mistake, such as a developer misreading a requirement.
• Defect (bug): the flaw that mistake creates in the code.
• Failure: what the user sees when the defective code runs and the system behaves wrongly.

Answer

• Black-box: test inputs and outputs without looking at the code.
• White-box: test with knowledge of the internal code — paths, branches, conditions.
• Grey-box: partial knowledge, such as knowing the database structure while testing through the UI.

Answer

1. Testing shows that defects are present, not that there are none.
2. Exhaustive testing is impossible — prioritise by risk.
3. Test early; defects are cheaper to fix early.
4. Defects cluster in a few modules.
5. Repeating the same tests stops finding new bugs (the pesticide paradox), so update tests.
6. Testing depends on context — a banking app isn't tested like a game.
7. A bug-free system that doesn't meet user needs is still a failure.

Answer

New → Assigned → Open → Fixed → Retest → Closed. Along the way a defect can also be Rejected (not a bug), Deferred (fix later), marked Duplicate, or Reopened if the retest fails.

Answer

• Severity: how badly the defect affects the system (technical impact).
• Priority: how soon it should be fixed (business urgency).

Example: a spelling mistake in the company name on the home page is low severity but high priority. A crash in a rarely used report is high severity but may be lower priority.

Answer

A clear title, environment (build, browser, device), steps to reproduce, expected result, actual result, severity, and evidence such as screenshots, videos or logs. The developer should be able to reproduce it without asking you questions.

Answer

• Smoke testing: a quick, broad check of a new build's critical features to decide if it's stable enough for detailed testing.
• Sanity testing: a quick, narrow check that a specific fix or change works, before deeper regression testing.

Answer

• Retesting: run the failed test again to confirm a specific defect is fixed.
• Regression testing: run a wider set of tests to make sure the change didn't break anything that used to work.

Regression suites are the first candidates for automation.

Answer

• Functional: does the feature do what it should? Login, search, payment flow.
• Non-functional: how well does it work? Performance, load, security, usability, compatibility.

Answer

User Acceptance Testing is done by end users or the client, usually in the final stage, to confirm the software meets business needs in real-world scenarios. Alpha testing happens at the developer's site; beta testing is done by real users in their own environment.

Answer

Automate tests that are repeated often (regression, smoke), stable, data-driven or tedious to do by hand. Don't automate one-time tests, features that change constantly, or checks that need human judgement such as usability and visual design.

Answer

Selenium WebDriver is an open-source tool that controls real browsers (Chrome, Firefox, Edge) through code, so you can automate web UI tests. It supports Java, Python, C#, JavaScript and more, and is usually combined with a test framework such as TestNG, JUnit or pytest.

Answer

ID, name, class name, tag name, link text, partial link text, CSS selector and XPath. Prefer a unique, stable ID, then CSS selectors. Use XPath when you need to find elements by text or move up the DOM. Avoid long absolute XPaths, which break when the page changes.

Answer

• Implicit wait: a global timeout for finding any element.
• Explicit wait: waits for a specific condition on a specific element, such as "clickable" — the most reliable choice.
• Fluent wait: an explicit wait with a custom polling interval and exceptions to ignore.

Avoid fixed Thread.sleep() calls; they make tests slow and flaky.

Answer

A design pattern where each page of the app has a class holding its locators and actions (such as login(user, pass)). Tests call those methods instead of using locators directly. When the UI changes, you update one page class instead of every test.

Answer

Send requests with Postman or code (REST Assured, pytest with requests) and check:

• Status codes (200, 201, 400, 401, 404, 500)
• Response body and its schema
• Headers and response time
• Authentication and authorisation
• Error handling for invalid and missing input

// REST Assured (Java)
given().header("Authorization", "Bearer " + token)
.when().get("/api/users/1")
.then().statusCode(200).body("name", equalTo("Anu"));

Answer

Find the cause instead of just re-running: usually timing (use explicit waits), shared or changing test data (make each test create its own data), test order dependency, or an unstable environment. Quarantine a flaky test until it's fixed so it doesn't hide real failures.

Answer

Automated tests run on every commit or pull request in a pipeline (Jenkins, GitHub Actions, GitLab CI). Fast unit and API tests run first; slower UI tests run later or nightly. A failing test stops the pipeline, so broken code doesn't reach production.

Answer

Many fast unit tests at the bottom, fewer API and integration tests in the middle, and a small number of slow UI end-to-end tests at the top. This gives fast feedback and stable suites. An "ice-cream cone" — mostly UI tests — is slow and fragile.