Interview Questions

Software testing is evaluating a product to find defects and check it meets requirements and user needs. It reduces the risk of failures in production, protects users and reputation, and gives the team confidence to release.

Verification asks “are we building the product right?” — reviews of requirements, designs and code against specifications. Validation asks “are we building the right product?” — executing the software to check it meets user needs.

Requirement analysis, test planning, test case design, test environment setup, test execution, and test closure. Each phase has entry and exit criteria and produces deliverables such as the test plan, test cases and the closure report.

A test scenario is a high-level “what to test” (e.g. “User can log in”). A test case is a detailed “how to test”: preconditions, steps, test data and expected result.

Severity is the technical impact of a defect on the system; priority is how urgently it should be fixed. A typo in the company name on the home page is low severity but high priority; a crash in a rarely used admin report may be high severity but lower priority.

Defects cluster at the edges of input ranges, so test values on and around each boundary. For an age field accepting 18–60, test 17, 18, 19, 59, 60 and 61.

Smoke testing is a broad, shallow check that a new build’s critical functions work so deeper testing can start. Sanity testing is a narrow, focused check after a fix or small change that the specific area now works.

Regression testing re-checks existing functionality after changes to make sure nothing broke. Select tests covering the changed area, high-risk and frequently used features, and areas with past defects; automate the stable, repetitive ones.

New → Assigned → Open → Fixed → Retest → Verified → Closed. Alternatives include Rejected, Duplicate, Deferred and Reopened when a retest fails.

A clear, specific title; environment and build; exact steps to reproduce; expected versus actual result; severity; and evidence such as screenshots, videos, logs or the API request and response. One bug per report.

An RTM maps each requirement to its test cases (and often to defects). It shows coverage gaps, helps assess the impact of requirement changes and proves to stakeholders that every requirement was tested.

Check status codes, response bodies and schemas, headers, authentication and authorisation, validation errors for bad input, boundary values, and side effects in the database. Use Postman collections with environments and simple test scripts.