STLC and Test Planning Interview Questions for Software Testing

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

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.

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

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

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.

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.

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.

Re-run the test once to confirm the failure and rule out wrong data or environment issues. Capture evidence such as screenshots, logs and the build number. Check for an existing bug, then log a new one with clear steps and link it to the test case. Mark the test as failed, and mark dependent tests as blocked if they cannot run. After the fix, retest and run related regression.

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.

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

A suite is a collection of related test cases; a run is one execution of a set of tests against a build.

Scope (in and out), objectives, approach, environments, schedule, roles, entry/exit criteria, risks and mitigation, deliverables and tools.

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

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

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

The inputs used in tests. Prepare using valid, invalid and boundary values from production-like but masked data, spreadsheets or generators.

Test execution rate, pass percentage, defect density, defect leakage, defect rejection ratio, requirement coverage and automation coverage.

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 grid mapping requirements to test cases and defects, proving every requirement is tested.

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.

Suspension criteria define when testing should be paused because continuing would waste effort, for example when a blocker bug stops the main flow, the build fails smoke testing or the environment is down. Resumption criteria define what must happen to restart, such as a new build that passes smoke testing or the environment restored. Writing these down avoids arguments and shows clearly why testing time was lost.

In sprint planning, review each story's acceptance criteria and estimate test effort, including test data and regression. Write test cases in the first days while development starts. Ask for early builds so testing is spread across the sprint, not crowded at the end. Keep time for regression and bug retesting in the last two or three days. Track progress on the board and raise risks in stand-up.

Rank test cases by business risk and usage: critical flows like login, payment and data saving first, then new features, then high-risk regression from past defects, and cosmetic checks last. Run smoke testing immediately to avoid wasting time on a broken build. Share the reduced plan with the lead and product owner so they know what will not be covered, and get agreement on the remaining risk.

Escalate immediately with the impact on the schedule. While it is down, prepare test data, review and update test cases, and test what you can elsewhere: API tests against another environment, UI on a developer machine or a staging copy. Track the lost hours in the status report. When the environment returns, run smoke first, then the prioritised list, and ask whether the release date or scope needs to change.

Test monitoring compares actual testing progress with the plan, using metrics like test cases executed, pass rate, open defects and effort spent. Test control is the action taken when monitoring shows a gap, such as re-prioritising tests, adding testers, changing the schedule or tightening entry criteria. For example, if half the time has passed but only a quarter of cases are executed, the lead must act and inform stakeholders.

Spend the first day learning the scope: read the release notes, user stories and test plan, and ask the lead what is at risk. Get access to the environment, tracker and test repository. Pick up a clearly defined module, run its existing test cases to learn the application and note gaps. Ask questions early in stand-up. Within a few days, take ownership of retesting and regression for that module.

Model answer: Situation: I was supporting two products whose releases fell in the same week. Task: deliver both without dropping quality. Action: I listed tasks by release date and risk, agreed priorities with both leads, blocked focus time for each product and shared daily status. I also asked a teammate to take retesting on one project. Result: both releases went out on time with no critical escapes.

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.

I agree the split with the team at sprint planning. Testing new stories manually comes first because it blocks the sprint goal. I then automate the stable flows from the previous sprint, so scripts are not rewritten while features change. For example, I block two afternoons a week for automation and report progress in stand-up. If a release is at risk, I pause automation and tell the lead openly.

Break the work into modules and test cases, use past velocity or three-point estimation (optimistic, likely, pessimistic), add time for test data, environment issues, retesting and regression, and keep a risk buffer.

Shift left with early reviews, improve test design, automate regression, use better test data, add monitoring and learn from escaped defects.

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

Three-point estimation uses an optimistic (O), most likely (M) and pessimistic (P) estimate for each task. The weighted formula is (O + 4M + P) divided by 6. If testing a module would take 4 days at best, 6 days most likely and 14 days at worst, the estimate is (4 + 24 + 14) / 6 = 7 days. It includes uncertainty in a single number and is often combined with a work breakdown of test activities.

Product risks are about the quality of the software itself: features that may fail and harm users, such as wrong interest calculation or a data leak. They decide what to test more deeply. Project risks are about running the test project: late builds, unstable environments, missing skills, unclear requirements or tight deadlines. They decide how to plan, with mitigations like buffers, backup environments or training.

Model answer: Situation: a regulatory change had to go live in ten days. Task: lead four testers. Action: I split work by risk, put our strongest tester on the calculation engine, ran daily 15-minute bug triage with developers and shared a single status dashboard. I also automated the repeated tax checks. Result: we released on the deadline with zero critical defects, and the client used our test evidence for their audit.

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.

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.

A go or no-go meeting is held before release to decide whether to deploy. QA presents test coverage against scope, pass and fail counts, open defects by severity with their impact, known issues and workarounds, any untested areas and the overall risk. QA gives a recommendation, but the business owner decides. The decision and accepted risks should be recorded in the meeting notes.

Keep a tiered regression suite: a smoke set for every build, a core set of critical flows for every release and a full set run on a rotation or before major releases. Each month, add impact-based tests from the release changes and cases for recent production bugs. Automate stable, repeated cases and keep manual effort for new or changing areas. Schedule regression early enough to fix and retest found issues.

Do not copy raw production data into test environments. Use synthetic data generated for the test cases, or masked production data where names, phone numbers, emails, ID numbers and card details are replaced while formats and relationships are kept. Restrict access to test databases and record the data rules in the test plan. This keeps testing realistic and follows India's data protection law and company policy.

Model answer: Situation: a loan app release was planned on Friday, but the EMI schedule showed wrong values for some tenures. Task: give an honest recommendation. Action: I presented the failing cases, the number of affected customers and the compliance risk in the go or no-go meeting, and proposed a three-day delay with a fix plan. Result: management agreed, the fix shipped on Monday, and no complaints came in.

Testing is complete when agreed exit criteria are met, not when the bug count is zero. Check that planned tests ran, critical and high bugs are fixed or formally accepted, and remaining open bugs have workarounds and low user impact. Present the list with risk to the product owner, who decides on release. Record accepted bugs as known issues, so nothing is hidden and they are planned for a later release.

State the goals, such as cutting regression time and giving pull request feedback within fifteen minutes. Define the split across unit, API and UI layers, the tools and language, which suites run on each pull request, nightly and before release, and who writes and maintains tests. Add entry rules for automating a case, reporting, flaky test handling and environments. Review metrics every quarter and adjust.