QA/SDET Theory & Behavioral Interview Questions¶

A comprehensive collection of 60 theory and behavioral interview questions for QA Engineers and Software Development Engineers in Test (SDET).

Table of Contents¶

• Part 1: Software Development & Testing Lifecycles (Q1-8)
• Part 2: Defect Management (Q9-16)
• Part 3: Types of Testing (Q17-28)
• Part 4: Test Design & Documentation (Q29-36)
• Part 5: API Testing Concepts (Q37-44)
• Part 6: Testing Principles & Best Practices (Q45-50)
• Part 7: Behavioral & Situational Questions (Q51-60)
• Interview Tips

Part 1: Software Development & Testing Lifecycles¶

Q1. What is SDLC? Explain its phases.¶

Answer:

SDLC (Software Development Life Cycle) is a systematic process for planning, creating, testing, and deploying software applications. It provides a structured approach to software development.

Phases of SDLC:

flowchart LR
    A[1. Requirement<br>Gathering] --> B[2. Planning/<br>Analysis]
    B --> C[3. Design]
    C --> D[4. Development]
    D --> E[5. Testing<br>& Deployment]
    E --> F[6. Maintenance]
    F -.-> A

Q2. What is STLC? Explain its phases.¶

Answer:

STLC (Software Testing Life Cycle) is a sequence of specific activities conducted during the testing process to ensure software quality goals are met. It defines what testing activities to perform and when.

Phases of STLC:

flowchart LR
    A[1. Requirement<br>Analysis] --> B[2. Test<br>Planning]
    B --> C[3. Test Case<br>Design]
    C --> D[4. Environment<br>Setup]
    D --> E[5. Test<br>Execution]
    E --> F[6. Test Cycle<br>Closure]

Q3. What is the difference between SDLC and STLC?¶

Answer:

Q4. What is Agile methodology?¶

Answer:

Agile is an iterative and incremental approach to software development that emphasizes flexibility, collaboration, customer feedback, and rapid delivery of working software.

Core Values (Agile Manifesto):

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Key Principles:

• Deliver working software frequently (weeks, not months)
• Welcome changing requirements, even late in development
• Business and developers work together daily
• Build projects around motivated individuals
• Face-to-face conversation is the most effective communication
• Working software is the primary measure of progress
• Sustainable development pace
• Continuous attention to technical excellence
• Simplicity - maximize work not done
• Self-organizing teams
• Regular reflection and adaptation

Common Agile Frameworks:

• Scrum
• Kanban
• XP (Extreme Programming)
• SAFe (Scaled Agile Framework)
• Lean

Q5. Explain Scrum framework and its ceremonies.¶

Answer:

Scrum is an Agile framework for developing, delivering, and sustaining complex products through iterative cycles called Sprints.

Scrum Roles:

Scrum Artifacts: - Product Backlog: Prioritized list of all desired features - Sprint Backlog: Items selected for current sprint - Increment: Potentially shippable product at sprint end

Scrum Ceremonies (Events):

Sprint Cycle:

flowchart LR
    subgraph Sprint["Sprint (2-4 weeks)"]
        A[Sprint<br>Planning] --> B[Daily Work +<br>Standups]
        B --> C[Sprint Review +<br>Retrospective]
    end
    C -.->|Next Sprint| A

Q6. What is the difference between Waterfall and Agile?¶

Answer:

When to use Waterfall:

• Requirements are well-understood and stable
• Project has strict regulatory requirements
• Fixed budget and timeline constraints

When to use Agile:

• Requirements are unclear or likely to change
• Quick time-to-market is important
• Customer feedback is valuable

Q7. What is DevOps and CI/CD?¶

Answer: DevOps:

DevOps is a set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and deliver high-quality software continuously.

Key DevOps Practices:

• Continuous Integration (CI)
• Continuous Delivery/Deployment (CD)
• Infrastructure as Code (IaC)
• Monitoring and Logging
• Collaboration and Communication

CI/CD Pipeline:

flowchart LR
    subgraph CI["Continuous Integration"]
        A[Code Commit] --> B[Build]
        A1[Version Control<br>Git] -.-> A
        B1[Compile<br>Package<br>Artifacts] -.-> B
    end
    subgraph CD["Continuous Delivery"]
        B --> C[Test]
        C --> D[Deploy]
        C1[Unit Tests<br>Integration<br>E2E Tests] -.-> C
        D1[Staging<br>Production] -.-> D
    end

Popular CI/CD Tools:

• Jenkins, GitHub Actions, GitLab CI
• CircleCI, Travis CI, Azure DevOps
• AWS CodePipeline, Google Cloud Build

Q8. What is the role of QA in Agile teams?¶

Answer: In Agile teams, QA is integrated throughout the development process rather than being a separate phase at the end.

Key Responsibilities:

Shift-Left Approach:

flowchart LR
    subgraph Traditional
        T1[Requirements] --> T2[Design] --> T3[Development] --> T4[Testing] --> T5[Deployment]
        T4 -.- QA1[QA here]
    end

flowchart LR
    subgraph Agile
        A1[Requirements] --> A2[Design] --> A3[Development] --> A4[Testing] --> A5[Deployment]
        QA2[QA involved throughout] -.- A1 & A2 & A3 & A4
    end

QA in Agile vs Traditional:

Part 2: Defect Management¶

Q9. What is the Defect Life Cycle?¶

Answer:

The Defect Life Cycle (Bug Life Cycle) is the journey of a defect from its discovery to its closure. It defines the various states a bug goes through during its lifetime.

Defect Life Cycle Diagram:

flowchart TD
    NEW[NEW] --> REJECTED[REJECTED]
    NEW --> DUPLICATE[DUPLICATE]
    NEW --> ASSIGNED[ASSIGNED]
    ASSIGNED --> OPEN[OPEN]
    OPEN --> DEFERRED[DEFERRED]
    OPEN --> FIXED[FIXED]
    OPEN --> NOTABUG[NOT A BUG]
    FIXED --> RETEST[PENDING RETEST]
    RETEST --> REOPEN[REOPEN]
    RETEST --> VERIFIED[VERIFIED]
    REOPEN --> OPEN
    VERIFIED --> CLOSED[CLOSED]

Defect States Explained:

Q10. What is the difference between Defect Severity and Priority?¶

Answer:

Severity Levels:

Priority Levels:

Severity vs Priority Matrix:

Q11. What are the components of a Defect Report?¶

Answer: A good defect report contains all information needed to understand, reproduce, and fix the bug.

Essential Components:

Optional Components:

• Module/Feature area
• Test case reference
• Root cause (after analysis)
• Resolution notes
• Related defects

Q12. What is Defect Triage?¶

Answer: Defect Triage is a process where defects are reviewed, prioritized, and assigned to ensure the most critical issues are addressed first.

Triage Meeting Participants:

• QA Lead/Manager
• Development Lead
• Product Owner
• Project Manager

Triage Process:

flowchart TD
    A[1. Review New Defects] --> B{2. Valid Bug?}
    B -->|NO| C[Reject/Close]
    B -->|YES| D{3. Duplicate?}
    D -->|YES| E[Mark as Duplicate]
    D -->|NO| F[4. Assess Severity & Priority]
    F --> G[5. Assign to Developer]
    G --> H[6. Schedule for Fix]

Decisions Made During Triage:

• Is it a valid defect?
• What is the correct severity/priority?
• Who should fix it?
• When should it be fixed?
• Should it be deferred?

Q13. What is Root Cause Analysis (RCA)?¶

Answer: Root Cause Analysis is a systematic process for identifying the underlying cause of a defect rather than just addressing symptoms.

Common RCA Techniques: 1. 5 Whys Technique:

%%{init: {'theme': 'base'}}%%
flowchart TB
    P[🔴 Problem: App crashed during checkout]

    P --> W1
    W1["❓ Why 1: Why did it crash?"]
    A1["💥 Null pointer exception in payment module"]
    W1 --> A1

    A1 --> W2
    W2["❓ Why 2: Why was there a null pointer?"]
    A2["📭 Credit card object was null"]
    W2 --> A2

    A2 --> W3
    W3["❓ Why 3: Why was credit card null?"]
    A3["📡 API returned empty response"]
    W3 --> A3

    A3 --> W4
    W4["❓ Why 4: Why did API return empty?"]
    A4["⏱️ Timeout due to slow response"]
    W4 --> A4

    A4 --> W5
    W5["❓ Why 5: Why was response slow?"]
    A5["🗄️ Database query had no index"]
    W5 --> A5

    A5 --> RC[🎯 Root Cause: Missing database index]

    style P fill:#ffcdd2,stroke:#c62828
    style RC fill:#c8e6c9,stroke:#2e7d32

2. Fishbone Diagram (Ishikawa):

flowchart LR
    A[People] --> D[DEFECT]
    B[Process] --> D
    C[Technology] --> D
    E[Environment] --> D

3. Pareto Analysis: Focus on the 20% of causes creating 80% of defects.

Q14. What is the difference between Defect Prevention and Defect Detection?¶

Answer:

Defect Prevention Activities:

• Code reviews and pair programming
• Requirements reviews
• Design reviews
• Coding standards enforcement
• Static code analysis
• Training and knowledge sharing
• Root cause analysis of past defects
• Process improvements

Defect Detection Activities:

• Unit testing
• Integration testing
• System testing
• Regression testing
• Exploratory testing
• User acceptance testing

Cost of Defects by Phase:

xychart-beta
    title "Cost to Fix Defects by Phase"
    x-axis [Requirements, Design, Development, Testing, Production]
    y-axis "Cost ($)" 0 --> 10000
    bar [10, 100, 500, 1000, 10000]

Q15. What are common Defect Metrics?¶

Answer:

Example Calculations:

Defect Density:
- 50 defects found in 10,000 lines of code
- Defect Density = 50/10 = 5 defects per KLOC

DRE:
- 95 defects found during testing
- 5 defects found in production
- DRE = 95/(95+5) × 100 = 95%

Q16. How do you write a good Bug Report?¶

Answer: Characteristics of a Good Bug Report:

• Accurate - Correctly describes the issue
• Complete - Contains all necessary information
• Concise - No unnecessary details
• Reproducible - Steps clearly recreate the issue
• Objective - Factual, no opinions or blame

Best Practices: 1. Write Clear Titles:

Bad:  "Error on page"
Good: "500 Error when submitting contact form with empty email field"

2. Provide Detailed Steps:

Bad:
1. Go to site
2. Try to login
3. Doesn't work

Good:
1. Navigate to https://example.com/login
2. Enter username: testuser@email.com
3. Enter password: Test123!
4. Click "Sign In" button
5. Observe error message

3. Include Evidence:

• Screenshots with annotations
• Screen recordings
• Console logs
• Network request/response
• Error messages (exact text)

4. Specify Environment:

Browser: Chrome 120.0.6099.130
OS: macOS Sonoma 14.2
Device: MacBook Pro M1
Environment: Staging (https://staging.example.com)
Build: v2.3.1-beta

5. One Bug Per Report: Don't combine multiple issues.

Part 3: Types of Testing¶

Q17. What is the difference between Functional and Non-Functional Testing?¶

Answer:

Functional Testing Types:

Non-Functional Testing Types:

Q18. What is the difference between Verification and Validation?¶

Answer:

Verification Activities:

• Requirements review
• Design review
• Code review
• Walkthrough
• Inspection
• Static analysis

Validation Activities:

• Unit testing
• Integration testing
• System testing
• User acceptance testing
• Beta testing

Example:

Building a Calculator App:

Verification: "Did we implement addition correctly per the spec?"
- Code review confirms + operator follows specification
- Design review confirms UI matches mockups

Validation: "Can users actually add numbers easily?"
- User testing shows users can perform addition
- UAT confirms it meets business requirements

Q19. What is the difference between Black-box, White-box, and Gray-box Testing?¶

Answer:

Visual Representation: Black-box Testing: Tester knows Input/Output only

flowchart LR
    Input --> System["System<br>[Internal Hidden]<br>? ? ?"]
    System --> Output

White-box Testing: Tester knows all code paths

flowchart LR
    Input --> A --> B --> Output
    A --> C --> D
    B --> D

Gray-box Testing: Tester knows some internals

flowchart LR
    Input --> A["A<br>[Known]"] --> Hidden["?<br>[Hidden]"] --> Output

Black-box Techniques:

• Equivalence Partitioning
• Boundary Value Analysis
• Decision Table Testing
• State Transition Testing
• Use Case Testing

White-box Techniques:

• Statement Coverage
• Branch/Decision Coverage
• Path Coverage
• Condition Coverage

Q20. Explain Unit, Integration, System, and Acceptance Testing.¶

Answer: Testing Levels Pyramid:

block-beta
    columns 1
    block:top
        UAT["UAT (User Acceptance Testing)"]
    end
    block:system
        SYS["System Testing"]
    end
    block:integration
        INT["Integration Testing"]
    end
    block:unit
        UNIT["Unit Testing"]
    end

    style UAT fill:#e1f5fe
    style SYS fill:#b3e5fc
    style INT fill:#81d4fa
    style UNIT fill:#4fc3f7

Unit Testing:

// Testing a single function
function add(a, b) {
    return a + b;
}

// Unit test
test('add function', () => {
    expect(add(2, 3)).toBe(5);
    expect(add(-1, 1)).toBe(0);
});

Integration Testing:

• Big Bang: Integrate all modules at once
• Incremental: Integrate one by one
• Top-down: Start from main module
• Bottom-up: Start from lowest modules
• Sandwich: Both approaches combined

System Testing:

• Tests complete integrated system
• Validates functional and non-functional requirements
• Performed in environment similar to production

Acceptance Testing:

• Alpha Testing: Done internally at developer's site
• Beta Testing: Done by real users at customer's site
• UAT: User Acceptance Testing against business requirements

Q21. What is the difference between Smoke Testing and Sanity Testing?¶

Answer:

Smoke Testing Example:

%%{init: {'theme': 'base'}}%%
flowchart LR
    A[🚀 New Build<br/>Deployed] --> B{Run Smoke Tests}

    B --> C[✅ App launches]
    B --> D[✅ Login works]
    B --> E[✅ Navigation works]
    B --> F[✅ Key feature works]
    B --> G[✅ DB connection]

    C & D & E & F & G --> H{All Pass?}

    H -->|Yes| I[✅ Proceed with<br/>Detailed Testing]
    H -->|No| J[❌ Reject Build<br/>Report to Dev]

    style I fill:#c8e6c9,stroke:#2e7d32
    style J fill:#ffcdd2,stroke:#c62828

Sanity Testing Example:

%%{init: {'theme': 'base'}}%%
flowchart TB
    A[🐛 Bug Fix Deployed<br/>Password reset email not sending] --> B[Sanity Test Steps]

    B --> C[1️⃣ Click Forgot Password]
    C --> D[2️⃣ Enter Email]
    D --> E[3️⃣ Submit]
    E --> F[4️⃣ Check Email Received]
    F --> G[5️⃣ Click Reset Link]
    G --> H[6️⃣ Reset Password]

    H --> I{Pass?}
    I -->|Yes| J[✅ Continue<br/>Regression Testing]
    I -->|No| K[❌ Return to<br/>Development]

    style A fill:#fff3e0,stroke:#e65100
    style J fill:#c8e6c9,stroke:#2e7d32
    style K fill:#ffcdd2,stroke:#c62828

Q22. What is the difference between Regression Testing and Retesting?¶

Answer:

Visual Comparison: Regression Testing: Test multiple features to ensure no side effects

flowchart LR
    subgraph All Features
        A["Feature A<br>[Test]"]
        B["Feature B<br>[Test]"]
        C["Feature C<br>[Test]"]
        D["Feature D<br>[Test]"]
        E["Feature E<br>[Test]"]
        F["Feature F<br>[Test]"]
    end

Retesting: Test only the specific bug that was fixed

flowchart LR
    subgraph Features
        A[Feature A]
        B[Feature B]
        C[Feature C]
        D[Feature D]
        E["BUG FIX<br>[Test]"]
        F[Feature F]
    end
    style E fill:#90EE90

Regression Testing Strategies:

• Complete Regression: Run all tests (time-consuming)
• Selective Regression: Run tests for affected areas only
• Priority-based: Run critical tests first

Q23. What is the difference between Alpha and Beta Testing?¶

Answer:

Testing Flow:

flowchart LR
    A[Development] --> B[Alpha Testing]
    B --> C[Beta Testing]
    C --> D[Production Release]
    B -.- B1[Internal testers]
    C -.- C1[External users]

Alpha Testing:

• First phase of user testing
• White-box and black-box techniques
• Both functional and reliability testing
• Bugs can be addressed immediately

Beta Testing:

• Also called "field testing"
• Real-world usage scenarios
• Wider hardware/software combinations
• Feedback through surveys, bug reports
• May be open (anyone) or closed (selected users)

Q24. What is the difference between Static and Dynamic Testing?¶

Answer:

Static Testing Techniques:

• Code reviews
• Peer reviews
• Walkthroughs
• Inspections
• Static code analysis tools (SonarQube, ESLint)
• Checklist reviews

Dynamic Testing Techniques:

• Unit testing
• Integration testing
• System testing
• Performance testing
• All testing that runs code

Static Analysis Tools:

flowchart LR
    A[Code] --> B[Static Analyzer]
    B --> C[Report]
    C -.- D["• Code smells<br>• Security flaws<br>• Style issues<br>• Complexity<br>• Dead code"]

Benefits of Static Testing:

• Find defects early (cheaper to fix)
• No test environment needed
• Can review non-executable artifacts
• Improves code quality and maintainability

Q25. What is the difference between Exploratory Testing and Scripted Testing?¶

Answer:

Exploratory Testing Approach:

flowchart TD
    subgraph Session["Exploratory Testing Session (60 min)"]
        Charter["Charter: Explore login functionality<br>focusing on security and edge cases"]
        Charter --> A[Learn the feature]
        A --> B[Design tests on-the-fly]
        B --> C[Execute tests]
        C --> D[Document findings]
        D --> E[Adapt based on discoveries]
        E -.-> B
    end

When to Use Each:

Session-Based Test Management (SBTM):

• Charter: Mission for the session
• Time-box: Fixed duration (60-120 min)
• Session notes: Document findings
• Debrief: Review what was learned

Q26. What are the types of Performance Testing?¶

Answer:

flowchart TB
    subgraph Performance["Performance Testing Types"]
        A[Load Testing]
        B[Stress Testing]
        C[Spike Testing]
        D[Endurance Testing]
        E[Volume Testing]
        F[Scalability Testing]
    end

Load Patterns:

Key Metrics:

• Response time
• Throughput (requests/second)
• Error rate
• CPU/Memory usage
• Concurrent users supported

Tools: JMeter, Gatling, LoadRunner, k6, Locust

Q27. What is Security Testing?¶

Answer: Security Testing identifies vulnerabilities, threats, and risks in a software application to prevent malicious attacks and data breaches.

OWASP Top 10 Vulnerabilities (2021):

Types of Security Testing:

Common Security Test Cases:

• SQL Injection attempts
• Cross-Site Scripting (XSS)
• Authentication bypass
• Session management flaws
• File upload vulnerabilities
• Authorization checks
• Sensitive data exposure

Tools: OWASP ZAP, Burp Suite, Nessus, Metasploit

Q28. What is Usability and Accessibility Testing?¶

Answer: Usability Testing:

Tests how easy and user-friendly the application is for end users.

Usability Factors:

• Learnability: How easy for first-time users?
• Efficiency: How quickly can tasks be completed?
• Memorability: How easy to remember how to use?
• Errors: How many errors do users make?
• Satisfaction: How pleasant is the experience?

Accessibility Testing:

Tests if the application is usable by people with disabilities.

WCAG Guidelines (Web Content Accessibility Guidelines):

Accessibility Checks:

• Screen reader compatibility
• Keyboard-only navigation
• Color contrast ratios
• Text resizing
• Alt text for images
• Form labels
• Focus indicators

Tools:

• Usability: UserTesting, Hotjar, Maze
• Accessibility: WAVE, axe, Lighthouse, NVDA

Part 4: Test Design & Documentation¶

Q29. What is the difference between Test Case and Test Scenario?¶

Answer:

Example - Login Feature: Test Scenario:

TS001: Verify user login functionality

Test Cases derived from scenario:

Relationship:

flowchart TD
    A[Requirements] --> B["Test Scenarios<br>(What to test)"]
    B --> C["Test Cases<br>(How to test)"]
    C --> D["Test Scripts<br>(Automated tests)"]

Q30. What are Test Case Design Techniques?¶

Answer: 1. Boundary Value Analysis (BVA):

Tests at the edges of input ranges.

Test values: 17, 18, 19, 59, 60, 61

2. Equivalence Class Partitioning (ECP):

Divides inputs into groups expected to behave similarly.

3. Decision Table Testing:

Tests combinations of conditions and actions.

4. State Transition Testing:

Tests system states and transitions.

stateDiagram-v2
    [*] --> Locked
    Locked --> Unlocked : Enter correct PIN
    Unlocked --> Timeout : Idle 30s
    Timeout --> Unlocked : User activity

5. Error Guessing:

Based on tester's experience and intuition about likely errors.

Q31. What is Requirement Traceability Matrix (RTM)?¶

Answer: RTM is a document that maps requirements to test cases, ensuring all requirements are covered by tests.

RTM Structure:

Types of Traceability:

Forward Traceability:
Requirements → Test Cases
(Ensures all requirements are tested)

Backward Traceability:
Test Cases → Requirements
(Ensures all tests map to requirements)

Bi-directional Traceability:
Requirements ↔ Test Cases
(Both directions)

Benefits:

• Ensures 100% requirement coverage
• Identifies gaps in testing
• Shows impact of requirement changes
• Helps in test prioritization
• Facilitates audit compliance

Q32. What are the components of a Test Plan?¶

Answer: A Test Plan is a document describing the scope, approach, resources, and schedule of testing activities.

IEEE 829 Test Plan Structure:

Q33. What is the difference between Test Strategy and Test Plan?¶

Answer:

Test Strategy Includes:

• Testing objectives and scope
• Testing types to be used
• Test environment requirements
• Testing tools
• Risk analysis approach
• Defect management process
• Test metrics
• Roles and responsibilities

Test Plan Includes:

• Features to test
• Specific test cases
• Resource allocation
• Detailed schedule
• Entry/exit criteria
• Risk mitigation for this project

Relationship:

Test Strategy (Organization Level)
         ↓
    Test Plan (Project Level)
         ↓
    Test Cases (Test Level)

Q34. What are Entry and Exit Criteria?¶

Answer: Entry Criteria: Conditions that must be met before testing can begin.

Exit Criteria: Conditions that must be met before testing can end.

Example:

Entry Criteria for System Testing:
✓ Integration testing complete
✓ Build 2.3.0 deployed to staging
✓ Test environment verified
✓ Test data loaded
✓ All P1 defects from integration fixed

Exit Criteria for System Testing:
✓ All test cases executed
✓ Pass rate ≥ 95%
✓ No open P1 or P2 defects
✓ All P3 defects documented
✓ Test summary report approved

Q35. What is Risk-Based Testing?¶

Answer: Risk-Based Testing prioritizes testing activities based on the probability and impact of failures.

Risk Assessment:

Risk = Probability × Impact

Risk Matrix:

Risk Categories:

Risk-Based Testing Process: 1. Identify Risks: List potential problem areas 2. Assess Risks: Rate probability and impact 3. Prioritize: Focus on high-risk areas 4. Mitigate: Allocate more testing to risky areas 5. Monitor: Track risks throughout project

Benefits:

• Optimize limited testing time
• Focus on what matters most
• Better resource allocation
• Informed go/no-go decisions

Q36. What are Test Estimation Techniques?¶

Answer:

Three-Point Estimation Example:

Task: Write test cases for login feature

Optimistic (O): 2 days (everything goes smoothly)
Most Likely (M): 4 days (normal conditions)
Pessimistic (P): 8 days (complications arise)

Estimate = (O + 4M + P) / 6
         = (2 + 16 + 8) / 6
         = 26 / 6
         = 4.3 days

Part 5: API Testing Concepts¶

Q37. What is API? Explain REST vs SOAP.¶

Answer: API (Application Programming Interface):

A set of rules and protocols that allows different software applications to communicate with each other.

flowchart LR
    A["Client<br>(Frontend)"] <-->|"API<br>Request/Response"| B["Server<br>(Backend)"]

REST vs SOAP Comparison:

REST Example:

GET /api/users/123 HTTP/1.1
Host: api.example.com

Response:
{
    "id": 123,
    "name": "John Doe",
    "email": "john@example.com"
}

SOAP Example:

<soap:Envelope>
    <soap:Body>
        <GetUser>
            <UserId>123</UserId>
        </GetUser>
    </soap:Body>
</soap:Envelope>

Q38. What are HTTP Methods?¶

Answer:

Idempotent: Same request produces same result when repeated. Safe: Doesn't modify server state.

CRUD Operations Mapping:

PUT vs PATCH:

PUT /users/123
{
    "name": "John",
    "email": "john@email.com",
    "phone": "1234567890"
}
// Replaces entire resource

PATCH /users/123
{
    "phone": "9876543210"
}
// Updates only specified field

Q39. What are HTTP Status Codes?¶

Answer: Status Code Categories:

Common Status Codes:

Q40. What is the structure of HTTP Request and Response?¶

Answer: HTTP Request Structure:

HTTP Response Structure:

Common Headers:

Q41. What are API Authentication Methods?¶

Answer:

1. Basic Authentication:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
                     (base64 of "username:password")

2. API Key:

// In header
X-API-Key: abc123xyz

// In query parameter
GET /api/users?api_key=abc123xyz

3. Bearer Token:

Authorization: Bearer eyJhbGciOiJIUzI1NiIs...

4. OAuth 2.0 Flow:

sequenceDiagram
    participant User
    participant AuthServer as Auth Server
    participant Resource as Resource Server
    User->>AuthServer: 1. Request access
    AuthServer->>User: 2. User grants permission
    User->>AuthServer: 3. Exchange code for token
    AuthServer->>User: 4. Access token returned
    User->>Resource: 5. Use token to access API

5. JWT (JSON Web Token):

Header.Payload.Signature

eyJhbGciOiJIUzI1NiIs...    // Header (algorithm)
.eyJzdWIiOiIxMjM0NTY3...   // Payload (claims)
.SflKxwRJSMeKKF2QT4f...    // Signature (verification)

Q42. What are the types of API Testing?¶

Answer:

Common API Test Scenarios:

Q43. What should you validate in API Testing?¶

Answer: Validation Checklist:

Example Validations:

// Status code validation
expect(response.status).toBe(200);

// Response body validation
expect(response.body.user.name).toBe("John");
expect(response.body.user.email).toContain("@");

// Schema validation
expect(response.body).toMatchSchema(userSchema);

// Response time validation
expect(response.time).toBeLessThan(2000);

// Header validation
expect(response.headers['content-type']).toContain('application/json');

// Array validation
expect(response.body.users).toHaveLength(10);
expect(response.body.users[0]).toHaveProperty('id');

Q44. What are common API Testing Tools?¶

Answer:

Postman Collection Structure:

%%{init: {'theme': 'base'}}%%
flowchart TB
    C[📁 Collection] --> A[📂 Auth]
    C --> U[📂 Users]
    C --> P[📂 Products]

    A --> A1[🔑 Login]
    A --> A2[🚪 Logout]

    U --> U1[👤 Get User]
    U --> U2[➕ Create User]
    U --> U3[🗑️ Delete User]

    P --> P1[📋 List Products]
    P --> P2[🔍 Get Product]

    style C fill:#e3f2fd,stroke:#1565c0
    style A fill:#fff3e0,stroke:#e65100
    style U fill:#e8f5e9,stroke:#2e7d32
    style P fill:#fce4ec,stroke:#c2185b

REST Assured Example (Java):

given()
    .header("Authorization", "Bearer " + token)
    .contentType(ContentType.JSON)
.when()
    .get("/api/users/123")
.then()
    .statusCode(200)
    .body("name", equalTo("John Doe"))
    .body("email", containsString("@"));

Python requests Example:

import requests

response = requests.get(
    "https://api.example.com/users/123",
    headers={"Authorization": "Bearer token"}
)

assert response.status_code == 200
assert response.json()["name"] == "John Doe"

Part 6: Testing Principles & Best Practices¶

Q45. What are the Seven Principles of Software Testing?¶

Answer:

Detailed Explanations: 1. Testing Shows Presence of Defects:

Testing CAN prove: Bugs exist in software
Testing CANNOT prove: Software is bug-free

2. Exhaustive Testing is Impossible:

Login form with:
- Email (infinite possibilities)
- Password (infinite possibilities)
- Browser (100+ options)
- OS (50+ options)
Total combinations = Infinite!

3. Early Testing (Shift Left):

Cost to fix defect:
Requirements: $1
Design: $5
Development: $10
Testing: $50
Production: $500+

4. Defect Clustering (Pareto Principle):

80% of defects found in 20% of modules
→ Focus testing on high-risk modules

5. Pesticide Paradox:

Same tests run repeatedly → No new bugs found
Solution: Regularly review and update test cases

Q46. What is the Testing Pyramid?¶

Answer: The Testing Pyramid is a framework that suggests how to balance different types of tests.

block-beta
  columns 5
  space:2 ui["UI/E2E Tests<br/>10% | Slow | Expensive"]:1 space:2
  space:1 api["API/Integration Tests<br/>20% | Medium Speed"]:3 space:1
  unit["Unit Tests<br/>70% | Fast | Cheap"]:5

  style ui fill:#e8eaf6,stroke:#9fa8da,color:#3949ab
  style api fill:#e3f2fd,stroke:#90caf9,color:#1565c0
  style unit fill:#e0f2f1,stroke:#80cbc4,color:#00796b

Why This Shape: Unit Tests (Base):

• Test individual functions/methods
• Fast feedback (milliseconds)
• Easy to maintain
• Run frequently
• High coverage

Integration/API Tests (Middle):

• Test component interactions
• Moderate speed (seconds)
• Verify contracts between services
• Good balance of coverage and speed

UI/E2E Tests (Top):

• Test complete user workflows
• Slow (minutes)
• Brittle, prone to flakiness
• High maintenance cost
• Reserve for critical paths

block-beta
  columns 5
  ui["UI Tests - Many | Slow | Expensive"]:5
  space:1 api["API Tests - Few"]:3 space:1
  space:2 unit["Unit - Almost None"]:1 space:2

  style ui fill:#ffebee,stroke:#ef9a9a,color:#c62828
  style api fill:#fff8e1,stroke:#ffe082,color:#f57f17
  style unit fill:#e8f5e9,stroke:#a5d6a7,color:#2e7d32

Q47. What is Shift-Left Testing?¶

Answer: Shift-Left Testing means moving testing activities earlier in the development lifecycle.

%%{init: {'theme': 'base'}}%%
flowchart LR
    subgraph traditional["Traditional Approach"]
        direction LR
        R1[Requirements] --> D1[Design] --> Dev1[Development] --> T1[Testing] --> Dep1[Deployment]
    end

    subgraph shiftleft["Shift-Left Approach"]
        direction LR
        R2[Requirements] --> D2[Design] --> Dev2[Development] --> T2[Testing] --> Dep2[Deployment]
        QA1([🧪]) -.-> R2
        QA2([🧪]) -.-> D2
        QA3([🧪]) -.-> Dev2
        QA4([🧪]) -.-> T2
    end

    style T1 fill:#c8e6c9,stroke:#2e7d32
    style R2 fill:#e3f2fd,stroke:#1565c0
    style D2 fill:#e3f2fd,stroke:#1565c0
    style Dev2 fill:#e3f2fd,stroke:#1565c0
    style T2 fill:#e3f2fd,stroke:#1565c0

Shift-Left Practices:

Shift-Left vs Shift-Right:

%%{init: {'theme': 'base'}}%%
flowchart LR
    subgraph left["⬅️ Shift-Left (Earlier Testing)"]
        L1[Requirements Reviews]
        L2[Design Reviews]
        L3[TDD/BDD]
        L4[Unit Tests]
        L5[Static Analysis]
    end

    subgraph center[" "]
        DEV[Development<br/>Lifecycle]
    end

    subgraph right["Shift-Right ➡️ (Production Testing)"]
        R1[Feature Flags]
        R2[A/B Testing]
        R3[Canary Deployments]
        R4[Chaos Engineering]
        R5[Production Monitoring]
    end

    left --> center --> right

    style left fill:#e3f2fd,stroke:#1565c0
    style right fill:#fff3e0,stroke:#e65100
    style center fill:#f5f5f5,stroke:#757575

Q48. What is the difference between Test Coverage and Code Coverage?¶

Answer:

Code Coverage Types:

Example:

function calculate(a, b, operation) {    // Line 1
    if (operation === 'add') {           // Line 2 (branch)
        return a + b;                     // Line 3
    } else if (operation === 'subtract') {// Line 4 (branch)
        return a - b;                     // Line 5
    }                                     // Line 6
    return 0;                             // Line 7
}

// Test: calculate(2, 3, 'add')
// Statement coverage: 4/7 = 57%
// Branch coverage: 1/3 = 33%

Q49. When should you stop testing?¶

Answer: Testing is theoretically infinite. Use these criteria to decide when to stop:

Exit Criteria Based:

• All planned test cases executed
• Required pass rate achieved
• No critical/high defects open
• Code coverage targets met
• Stakeholder sign-off obtained

Risk-Based:

• Remaining risk acceptable to business
• High-risk areas thoroughly tested
• Diminishing returns on bug discovery

Resource-Based:

• Budget exhausted
• Time deadline reached
• Resources unavailable

Practical Indicators: When the defect discovery rate flattens (finding fewer new bugs over time), consider stopping testing.

Decision Matrix:

Q50. What is the difference between Quality Assurance and Quality Control?¶

Answer:

QA Activities:

• Define testing processes
• Create standards and guidelines
• Conduct process audits
• Training and mentoring
• Process improvement
• Metrics and reporting

QC Activities:

• Test case design
• Test execution
• Defect logging
• Code reviews
• Inspections
• Product verification

Relationship:

flowchart TB
    subgraph QM["Quality Management"]
        direction TB
        subgraph QA["Quality Assurance (QA)"]
            direction TB
            subgraph QC["Quality Control (QC)"]
                QCact["Testing, Inspection, Verification"]
            end
            QAact["Processes, Standards, Audits, Training"]
        end
        QMact["Strategy, Planning, Governance"]
    end

Part 7: Behavioral & Situational Questions¶

Q51. Tell me about yourself (for QA/SDET role).¶

Answer Framework (STAR for introduction): Structure:

1. Current role and experience
2. Key skills and achievements
3. Why QA/SDET
4. Why this company/role

Q52. Describe a challenging bug you found.¶

Answer Framework (STAR Method): Situation: Context and background Task: Your responsibility Action: What you did Result: Outcome and impact

Q53. How do you handle tight deadlines?¶

Answer: Key Points to Cover:

1. Prioritization approach
2. Communication strategy
3. Risk management
4. Quality balance

Q54. How do you prioritize test cases?¶

Answer: Prioritization Factors:

Q55. Describe a conflict with a developer and how you resolved it.¶

Answer Framework (STAR Method):

Q56. How do you stay updated with testing trends?¶

Answer: Resources and Methods:

Q57. Why do you want to be an SDET?¶

Answer:

Q58. Describe a time you improved a process.¶

Answer Framework (STAR Method):

Q59. How do you handle ambiguous requirements?¶

Answer:

Q60. What's your approach to learning a new tool?¶

Answer:

Interview Tips¶

General Tips¶

1. Use STAR Method:
2. Situation: Set the context
3. Task: Describe your responsibility
4. Action: Explain what you did (focus here)

5. Result: Share the outcome with metrics

6. Be Specific:

7. Use numbers and metrics
8. Name specific tools and technologies

9. Give concrete examples

10. Know Your Resume:

11. Be ready to discuss any item listed
12. Have examples for each skill claimed

13. Prepare for deep dives on projects

14. Ask Clarifying Questions:

15. For technical questions, clarify assumptions

16. For behavioral questions, confirm the scenario

17. Think Aloud:

18. Share your reasoning process
19. Interviewers want to see how you think

Technical Preparation¶

Questions to Ask the Interviewer¶

1. "What does a typical day look like for a QA/SDET on this team?"
2. "What's the test automation strategy and tech stack?"
3. "How does QA collaborate with development and product?"
4. "What are the biggest quality challenges the team faces?"
5. "What does career growth look like for this role?"
6. "How do you measure testing success?"

Red Flags to Avoid¶

Final Checklist¶

Good luck with your interview!