Manual Testing Interview Questions

SDLC stands for Software Development Life Cycle. It is a structured framework that defines the process of developing software from inception to retirement. The goal of SDLC is to produce high-quality software that meets or exceeds customer expectations, is completed within time and cost constraints, and is maintainable over time. SDLC includes phases such as: Requirement Gathering, System Design, Implementation (Coding), Testing, Deployment, Maintenance. Each phase has specific deliverables and review processes to ensure quality and consistency.

The standard phases of SDLC are: 1) Requirement Gathering and Analysis – Stakeholders and business analysts collect functional and non-functional requirements. 2) System Design – Architects and designers create high-level and low-level design documents based on requirements. 3) Implementation (Coding) – Developers write code according to design specifications. 4) Testing – QA teams validate the software against requirements using various testing techniques. 5) Deployment – The software is released to production or staging environments. 6) Maintenance – Post-deployment support includes bug fixes, performance improvements, and feature enhancements. Each phase may involve feedback loops and documentation to ensure traceability and accountability.

SDLC provides a systematic approach to software development, ensuring: • Predictability in timelines and deliverables • Quality assurance through structured testing and reviews • Risk mitigation by identifying issues early • Cost control through efficient resource planning • Stakeholder alignment via documentation and checkpoints Without SDLC, software projects risk scope creep, missed deadlines, poor quality, and customer dissatisfaction.

A tester plays a critical role throughout SDLC, especially in: • Requirement Analysis – Reviewing requirements for testability and identifying ambiguities • Test Planning – Defining scope, objectives, resources, and schedules for testing • Test Case Design – Creating detailed test cases and scenarios based on requirements • Test Execution – Running test cases, logging defects, and validating fixes • Regression Testing – Ensuring new changes don't break existing functionality • Test Closure – Summarizing test results, metrics, and lessons learned Testers also collaborate with developers, business analysts, and product owners to ensure quality is built into the product from the start.

SDLC covers the entire software development process while STLC focuses only on testing-related activities. SDLC: • Scope: Entire software development process • Phases: Requirement, Design, Coding, Testing, Deployment, Maintenance • Participants: Developers, Analysts, Testers, PMs • Deliverables: Software product, design docs, codebase STLC: • Scope: Only testing-related activities • Phases: Requirement Analysis, Test Planning, Test Case Design, Execution, Closure • Participants: QA/Test Engineers • Deliverables: Test cases, defect logs, test reports In short, SDLC is broader, while STLC is a subset focused on ensuring the product meets quality standards.

STLC stands for Software Testing Life Cycle. It defines a systematic process followed by QA teams to ensure software quality. STLC begins with requirement analysis and ends with test closure activities. It ensures that testing is planned, executed, and documented in a structured way. Key Objectives of STLC: • Identify defects early • Ensure requirement coverage • Deliver a stable and reliable product • Provide metrics and insights for improvement STLC is a subset of SDLC, focused entirely on testing activities.

The standard phases of STLC are: 1) Requirement Analysis • Understand and analyze requirements for testability • Identify test types (functional, non-functional, etc.) 2) Test Planning • Define scope, objectives, resources, timelines • Identify risks and mitigation strategies • Select tools and environments 3) Test Case Development • Design test cases and test data • Review and baseline test cases 4) Test Environment Setup • Prepare hardware/software configurations • Validate environment readiness 5) Test Execution • Execute test cases • Log defects and track them to closure 6) Test Closure • Finalize test summary reports • Archive test artifacts • Conduct retrospectives Each phase has entry and exit criteria to ensure quality and completeness.

A test plan is a formal document that outlines the strategy, scope, approach, resources, and schedule for testing activities. Contents of a Test Plan: • Objectives and scope • Test items and features to be tested • Testing approach (manual, automation, types) • Entry and exit criteria • Resource allocation • Schedule and milestones • Risk analysis and mitigation • Deliverables and responsibilities It serves as a blueprint for the entire testing process and aligns stakeholders.

A test case is a set of conditions or steps used to validate a specific feature or functionality of the software. Components of a Test Case: • Test Case ID • Title/Description • Preconditions • Test Steps • Test Data • Expected Result • Actual Result • Status (Pass/Fail) • Comments Test cases ensure repeatability, traceability, and coverage of requirements.

Smoke testing is a preliminary test to check whether the basic functionalities of an application are working after a build. Purpose: • Validate stability of the build • Catch showstopper defects early • Decide whether to proceed with detailed testing Example: Login, dashboard load, basic navigation — if these fail, the build is rejected. It's often automated and run in CI/CD pipelines.

A defect is any deviation from expected behavior in the software. It occurs when the application does not perform as intended due to incorrect logic, missing functionality, or design flaws. Examples: • Login fails with valid credentials • Incorrect calculation in invoice • UI misalignment on mobile devices Defects are identified during testing and must be reported, tracked, and resolved.

The defect life cycle defines the states a defect goes through from identification to closure. Typical Stages: • New: Defect is logged • Assigned: Assigned to developer • Open: Developer starts analysis • Fixed: Code is updated • Retest: QA retests the fix • Verified: Fix is confirmed • Closed: Defect is resolved • Rejected/Deferred/Duplicate: Based on triage decisions Each stage is tracked in tools like JIRA, Bugzilla, or Azure DevOps.

Severity indicates the impact of the defect on the application's functionality. Levels: • Critical: System crash, data loss • High: Major functionality broken • Medium: Minor functionality affected • Low: Cosmetic issues, typos Severity is usually assigned by the QA team based on technical impact.

Priority defines the urgency of fixing the defect, based on business needs. Levels: • High: Must be fixed immediately • Medium: Fix in next cycle • Low: Can be deferred Priority is often set by the project manager or product owner, considering release timelines.

Severity is the impact on functionality while Priority is the urgency to fix. • Severity: Assigned by QA/Testers • Priority: Assigned by PM/Product Owner Example: Login fails (High Severity) but Fix before release (High Priority). A defect can be high severity but low priority (e.g., crash in rarely used module) or low severity but high priority (e.g., typo on homepage).

Agile testing is a continuous and iterative approach to testing that aligns with Agile development principles. Testing begins early and is integrated throughout the development cycle. Key Features: • Continuous feedback • Collaboration with developers and stakeholders • Flexibility to changing requirements • Early defect detection • Automation and exploratory testing Agile testing ensures quality is built in, not just tested at the end.

Agile Testing vs Traditional Testing: • Timing: Continuous, early vs After development • Documentation: Lightweight vs Heavy and formal • Collaboration: High (daily stand-ups, retrospectives) vs Limited • Flexibility: High vs Low • Feedback: Fast and iterative vs Delayed Agile testing is adaptive and collaborative, while traditional testing is sequential and rigid.

In Agile, testers are active team members involved in: • Reviewing user stories and acceptance criteria • Participating in sprint planning and retrospectives • Designing and executing test cases • Pairing with developers for unit and integration testing • Automating regression suites • Performing exploratory and risk-based testing Testers help ensure continuous quality and fast feedback.

A user story is a short, simple description of a feature from the end-user's perspective. Format: 'As a [user], I want to [action] so that [benefit].' Example: 'As a shopper, I want to apply a coupon during checkout so that I get a discount.' User stories guide development and testing by focusing on value and behavior.

Acceptance criteria are conditions that must be met for a user story to be considered complete. Example for login story: • Valid credentials allow access • Invalid credentials show error • Password is masked • Login button is disabled until fields are filled They help testers design focused and relevant test cases.

I approach it with collaboration and evidence. I ensure the defect report is clear, reproducible, and includes logs/screenshots. I then: • Reproduce the issue in front of the developer • Refer to the requirement or acceptance criteria • Discuss the impact on users • Stay objective and avoid blame If disagreement persists, I escalate to the QA lead or product owner for resolution. The goal is quality, not conflict.

I immediately: • Log the defect with high severity and priority • Inform the QA lead, PM, and stakeholders • Provide impact analysis and reproduction steps • Suggest mitigation (e.g., rollback, hotfix, deferral) Release decisions depend on risk vs business urgency, but I always advocate for user safety and product stability.

I use risk-based testing and focus on: • Core functionalities • High-impact areas • Recently changed modules • Customer-facing features • Known defect-prone areas I also run smoke tests, sanity checks, and exploratory testing to maximize coverage with minimal effort.

I ensure coverage by: • Creating a Requirement Traceability Matrix (RTM) • Designing test cases for all functional and non-functional requirements • Including boundary, negative, and edge cases • Reviewing with peers and stakeholders • Tracking metrics like requirement coverage and defect leakage Coverage is a continuous goal, not a one-time task.

I bring: • Attention to detail — I catch subtle issues others miss • Analytical thinking — I design effective test cases • Curiosity — I explore beyond the obvious • Communication skills — I collaborate and report clearly • Persistence — I dig deep into tough bugs • Process discipline — I follow best practices and improve continuously Manual testing is not just clicking — it's critical thinking, empathy, and precision.