QA Knowledge Base

Answer:

Software Testing is the process of evaluating and verifying that a software application or system meets specified requirements and works as expected. It involves executing software components using manual or automated tools to identify bugs, gaps, or missing requirements.

Key Objectives:

• Quality Assurance: Ensure the product meets quality standards
• Bug Detection: Identify defects before production release
• Verification: Confirm the product works as per specifications
• Validation: Ensure it meets user needs and expectations
• Risk Mitigation: Reduce the risk of software failures in production

Why It's Important:

1. Cost Efficiency: Finding bugs early is cheaper than fixing them in production
2. Security: Identifies vulnerabilities before they can be exploited
3. Customer Satisfaction: Delivers a reliable, high-quality product
4. Compliance: Ensures adherence to industry standards and regulations
5. Performance: Validates that the system performs well under expected load

Answer:

Test Scenario:

• High-level description of what to test
• One-liner statement covering multiple test cases
• Derived from use cases or requirements
• Example: "Verify login functionality"

Test Case:

• Detailed step-by-step instructions
• Includes preconditions, test steps, test data, and expected results
• Derived from test scenarios
• Example: "Verify login with valid username and password"

Example Comparison:

Test Scenario: Verify user login functionality

Test Cases derived from above scenario:

1. TC001: Login with valid username and valid password
2. TC002: Login with valid username and invalid password
3. TC003: Login with invalid username and valid password
4. TC004: Login with empty username and password fields
5. TC005: Verify "Forgot Password" functionality

Key Difference: A test scenario is "what to test" while a test case is "how to test".

Advantages:

• Speed: Automated tests run much faster than manual tests
• Reusability: Test scripts can be reused across different versions
• Reliability: Eliminates human error in repetitive tasks
• Coverage: Can execute thousands of test cases in parallel
• CI/CD Integration: Seamlessly integrates with continuous integration pipelines
• Cost-Effective: Reduces long-term testing costs for regression testing
• 24/7 Execution: Tests can run unattended overnight or on weekends

Disadvantages:

• Initial Investment: High upfront cost for tools, training, and setup
• Maintenance: Scripts require updates when UI or functionality changes
• Limited Scope: Not suitable for exploratory, usability, or ad-hoc testing
• Tool Limitations: Some scenarios are difficult or impossible to automate
• False Positives: Flaky tests can produce unreliable results
• Skill Requirement: Requires programming knowledge and technical expertise

Best Practice:

Use automation for repetitive, regression, and data-driven tests. Combine with manual testing for exploratory, usability, and new feature testing for optimal coverage.

Answer:

SDLC (Software Development Life Cycle):

• Complete process of software development from planning to deployment
• Includes all phases: Requirements, Design, Development, Testing, Deployment, Maintenance
• Focuses on building the entire software product
• Involves all stakeholders: developers, testers, business analysts, etc.

STLC (Software Testing Life Cycle):

• Subset of SDLC focused specifically on testing activities
• Phases: Requirement Analysis, Test Planning, Test Case Development, Environment Setup, Test Execution, Test Closure
• Focuses on ensuring quality through systematic testing
• Primarily involves QA team and test managers

Key Relationship:

STLC is a part of SDLC. While SDLC covers the entire software development process, STLC specifically deals with the testing phase and its sub-activities. STLC runs in parallel with SDLC phases to ensure quality at every stage.

STLC Phases:

1. Requirement Analysis: Understand testable requirements
2. Test Planning: Define test strategy and resources
3. Test Case Development: Create detailed test cases
4. Environment Setup: Prepare test environment
5. Test Execution: Run tests and log defects
6. Test Closure: Analyze results and document learnings

Answer:

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

Common Bug States:

1. New: Bug is logged and posted for the first time
2. Assigned: Bug is assigned to a developer for fixing
3. Open: Developer starts working on the bug
4. Fixed: Developer has fixed the bug and marked it as fixed
5. Pending Retest: Bug is fixed and waiting for tester to verify
6. Retest: Tester is retesting the bug fix
7. Verified: Tester confirms the bug is fixed
8. Closed: Bug is closed after verification
9. Reopened: Bug still exists after fix, sent back to developer
10. Rejected: Bug is not valid or not reproducible
11. Deferred: Bug fix is postponed to future release
12. Duplicate: Bug is already reported

Typical Flow:

New → Assigned → Open → Fixed → Pending Retest → Retest → Verified → Closed

Alternative Paths:

• If bug persists: Retest → Reopened → Assigned
• If invalid: New → Rejected → Closed
• If duplicate: New → Duplicate → Closed
• If postponed: New → Deferred

Answer:

Regression Testing is the process of retesting a software application after changes (bug fixes, enhancements, or new features) to ensure that existing functionality still works correctly and no new defects have been introduced.

When to Perform Regression Testing:

• After Bug Fixes: Verify the fix doesn't break other features
• New Feature Addition: Ensure new code doesn't impact existing functionality
• Code Refactoring: Validate that optimization doesn't introduce bugs
• Environment Changes: After infrastructure or configuration updates
• Before Release: Final validation before production deployment
• Integration: When integrating with third-party systems

Types of Regression Testing:

1. Complete Regression: Re-execute all test cases
2. Partial Regression: Test only affected modules
3. Unit Regression: Test at code/unit level
4. Regional Regression: Test specific region/module

Best Practices:

• Automate regression test suites for efficiency
• Prioritize test cases based on risk and impact
• Maintain a regression test suite that's regularly updated
• Use version control for test scripts

Answer:

Smoke Testing:

• Purpose: Verify basic/critical functionality works
• Scope: Broad but shallow - covers major features
• When: After receiving a new build
• Goal: Determine if build is stable enough for detailed testing
• Coverage: Wide coverage, minimal depth
• Execution: Usually automated
• Example: Can users login? Can they navigate? Can they logout?

Sanity Testing:

• Purpose: Verify specific functionality after changes
• Scope: Narrow but deep - focuses on specific area
• When: After minor bug fixes or small changes
• Goal: Verify the fix works and related functionality is intact
• Coverage: Narrow coverage, more depth
• Execution: Usually manual
• Example: If password reset was fixed, test all password-related features

Key Differences:

Answer:

Integration Testing is the process of testing the interfaces and interaction between integrated components or modules. It verifies that different modules work together as expected when combined.

Integration Testing Approaches:

1. Big Bang Integration:

• All modules are integrated simultaneously and tested together
• Pros: Quick to implement
• Cons: Difficult to isolate defects, late defect detection

2. Top-Down Integration:

• Testing starts from top-level modules and progresses downward
• Uses stubs for lower-level modules not yet developed
• Pros: Early prototype, critical modules tested first
• Cons: Requires stubs, lower-level issues found late

3. Bottom-Up Integration:

• Testing starts from lowest-level modules and progresses upward
• Uses drivers for higher-level modules
• Pros: Easier to create test conditions, no stubs needed
• Cons: Critical modules tested late, requires drivers

4. Sandwich/Hybrid Integration:

• Combination of top-down and bottom-up approaches
• Tests from both ends simultaneously
• Pros: Balanced approach, parallel testing possible
• Cons: Complex to manage, requires both stubs and drivers

What to Test:

• Data flow between modules
• Interface compatibility
• Exception handling across modules
• Database interactions
• API integrations

Answer:

System Testing is a level of testing where the complete integrated system is tested to verify that it meets specified requirements. It's performed on the entire system in an environment that closely mirrors production.

Types of System Testing:

1. Functional Testing: Verify system functions as per requirements
2. Performance Testing: Test system speed, scalability, stability
3. Load Testing: Test behavior under expected load
4. Stress Testing: Test beyond normal operational capacity
5. Usability Testing: Evaluate user-friendliness
6. Security Testing: Identify vulnerabilities and security flaws
7. Compatibility Testing: Test across different environments
8. Recovery Testing: Test system's ability to recover from crashes
9. Installation Testing: Verify installation/uninstallation process
10. Migration Testing: Test data migration from old to new system

Characteristics:

• Performed after integration testing
• Tests the system as a whole (black-box testing)
• Conducted in an environment similar to production
• Validates both functional and non-functional requirements
• Performed by independent testing team

Entry Criteria:

• All modules are integrated
• Integration testing is complete
• Test environment is ready
• Test data is prepared

Answer:

User Acceptance Testing (UAT) is the final phase of testing where actual users test the software to verify it meets their business requirements and is ready for production deployment. It's also known as Beta Testing or End-User Testing.

Who Performs UAT:

• End Users: Actual users who will use the system
• Business Analysts: Verify business requirements are met
• Product Owners: Validate product vision and goals
• Client Representatives: Stakeholders from client organization
• Subject Matter Experts (SMEs): Domain experts

Types of UAT:

1. Alpha Testing: Performed at developer's site by internal users
2. Beta Testing: Performed at client's site by end users
3. Contract Acceptance Testing: Based on contract criteria
4. Regulation Acceptance Testing: Verify compliance with regulations
5. Operational Acceptance Testing: Test operational readiness
6. Black Box Testing: Functional validation by users

UAT Process:

1. Analyze business requirements
2. Create UAT test plan
3. Identify test scenarios
4. Create test cases and test data
5. Execute test cases
6. Log defects and track to closure
7. Sign-off and go-live approval

Entry Criteria:

• System testing is complete
• No critical or high-priority defects
• UAT environment is ready
• Test data is prepared
• User training is complete

Exit Criteria:

• All test cases executed
• All critical defects resolved
• Business requirements validated
• Sign-off obtained from stakeholders

Answer:

Black Box Testing:

• Definition: Testing without knowledge of internal code structure
• Focus: Functionality and behavior
• Tester Knowledge: No programming knowledge required
• Techniques: Equivalence Partitioning, Boundary Value Analysis, Decision Tables
• Performed By: QA testers, end users
• Examples: Functional testing, UAT, system testing
• Advantages: Unbiased, user perspective, no code access needed
• Disadvantages: Limited coverage, can't test internal logic

White Box Testing:

• Definition: Testing with full knowledge of internal code structure
• Focus: Internal logic, code paths, algorithms
• Tester Knowledge: Programming knowledge required
• Techniques: Statement Coverage, Branch Coverage, Path Coverage
• Performed By: Developers, technical QA
• Examples: Unit testing, code coverage analysis
• Advantages: Thorough testing, early defect detection, code optimization
• Disadvantages: Time-consuming, requires code access

Grey Box Testing:

• Definition: Combination of black box and white box testing
• Focus: Both functionality and internal structure
• Tester Knowledge: Partial knowledge of internal workings
• Techniques: Matrix testing, regression testing, pattern testing
• Performed By: QA with technical knowledge
• Examples: Integration testing, database testing
• Advantages: Balanced approach, better test coverage
• Disadvantages: Requires both functional and technical skills

Answer:

Positive Testing:

• Definition: Testing with valid inputs to verify system works as expected
• Purpose: Validate that application does what it's supposed to do
• Approach: Test with correct data and valid scenarios
• Expected Result: System should accept input and process correctly
• Example: Login with valid username and password
• Also Known As: Happy path testing

Negative Testing:

• Definition: Testing with invalid inputs to verify system handles errors gracefully
• Purpose: Ensure application doesn't crash with unexpected input
• Approach: Test with incorrect data and invalid scenarios
• Expected Result: System should reject input with appropriate error message
• Example: Login with invalid password, SQL injection attempts
• Also Known As: Error path testing, failure testing

Examples:

Login Functionality:

• Positive: Valid username + valid password → Login successful
• Negative: Valid username + invalid password → Error message
• Negative: Empty fields → Validation error
• Negative: SQL injection in username → Rejected safely

File Upload:

• Positive: Upload valid file type within size limit → Success
• Negative: Upload file exceeding size limit → Error message
• Negative: Upload invalid file type → Rejected
• Negative: Upload without selecting file → Validation error

Best Practice:

Both positive and negative testing are essential. A good test strategy includes 20-30% positive tests and 70-80% negative tests to ensure robust error handling.

Answer:

Functional Testing:

• Definition: Tests what the system does (features and functions)
• Focus: Verify functionality against requirements
• Question: "Does it work as expected?"
• Based On: Functional requirements/specifications
• Testing Type: Black box testing
• Examples:
  • Unit Testing
  • Integration Testing
  • System Testing
  • UAT
  • Smoke Testing
  • Sanity Testing
  • Regression Testing

Non-Functional Testing:

• Definition: Tests how well the system performs (quality attributes)
• Focus: Verify performance, usability, reliability
• Question: "How well does it work?"
• Based On: Non-functional requirements (performance, security, etc.)
• Testing Type: Can be black box or white box
• Examples:
  • Performance Testing
  • Load Testing
  • Stress Testing
  • Security Testing
  • Usability Testing
  • Compatibility Testing
  • Scalability Testing
  • Reliability Testing

Key Differences:

Answer:

Exploratory Testing is a hands-on approach where testers actively explore the application without predefined test cases, simultaneously learning, designing, and executing tests based on their findings.

Key Characteristics:

• Unscripted: No formal test cases written beforehand
• Simultaneous: Learning, test design, and execution happen together
• Creative: Relies on tester's intuition and experience
• Adaptive: Tests evolve based on discoveries
• Time-boxed: Usually performed in sessions (60-120 minutes)

When to Use:

• Limited time for testing
• Incomplete or unclear requirements
• New features or applications
• Complement to scripted testing
• Finding edge cases and unusual scenarios
• After major code changes

Techniques:

1. Session-Based Testing: Time-boxed testing sessions with charters
2. Scenario-Based Testing: Test realistic user scenarios
3. Strategy-Based Testing: Use specific strategies (boundary, error guessing)

Advantages:

• Finds defects missed by scripted testing
• Requires less preparation time
• Adapts to changes quickly
• Leverages tester creativity

Disadvantages:

• Difficult to reproduce defects
• Depends heavily on tester skill
• Hard to measure coverage
• Not suitable for compliance testing

Answer:

Ad-hoc Testing is informal testing performed without any planning, documentation, or expected results. It's random testing to find defects through an unstructured approach.

Characteristics:

• No formal process or documentation
• Completely random and unstructured
• No test cases or test design
• Performed when time is limited
• Relies on tester's intuition
• Usually one-time activity

Types of Ad-hoc Testing:

1. Buddy Testing: Developer and tester work together
2. Pair Testing: Two testers work on same feature
3. Monkey Testing: Random inputs without any pattern

Ad-hoc vs Exploratory Testing:

Answer:

Alpha Testing:

• Location: Performed at developer's site/organization
• Performed By: Internal employees (not the development team)
• Environment: Controlled lab environment
• When: Before releasing to external users
• Purpose: Identify bugs before beta testing
• Feedback: Immediate and direct
• Duration: Shorter, more focused
• Example: Microsoft testing Windows internally before public release

Beta Testing:

• Location: Performed at client's/user's location
• Performed By: Real end users/customers
• Environment: Real-world environment
• When: After alpha testing, before final release
• Purpose: Get real user feedback and find environment-specific issues
• Feedback: Collected through surveys, crash reports
• Duration: Longer, weeks to months
• Example: Public beta programs for apps and games

Types of Beta Testing:

1. Closed Beta: Limited number of users, invitation-only
2. Open Beta: Available to general public
3. Technical Beta: Focus on technical aspects
4. Marketing Beta: Generate buzz and gather market feedback

Answer:

Retesting:

• Purpose: Verify that a specific defect has been fixed
• Scope: Only the failed test case
• When: After developer fixes a bug
• Test Cases: Same test case that found the bug
• Automation: Can be automated but usually manual
• Priority: High priority
• Also Known As: Confirmation testing

Regression Testing:

• Purpose: Ensure existing functionality still works after changes
• Scope: Entire application or affected modules
• When: After any code change (fix, enhancement, new feature)
• Test Cases: All or subset of existing test cases
• Automation: Highly recommended to automate
• Priority: Can be medium to high
• Also Known As: Verification testing

Example Scenario:

Bug: Login button doesn't work with special characters in password

• Retesting: Test login with special characters again to verify the fix
• Regression Testing: Test all login scenarios (valid login, invalid login, forgot password, etc.) to ensure the fix didn't break anything

Key Difference:

Retesting = "Did we fix the bug?"
Regression Testing = "Did the fix break anything else?"

Answer:

Compatibility Testing ensures that the application works correctly across different environments, platforms, browsers, devices, and configurations.

Types of Compatibility Testing:

1. Browser Compatibility:

• Test across different browsers (Chrome, Firefox, Safari, Edge)
• Test different browser versions
• Verify rendering, functionality, and performance

2. Operating System Compatibility:

• Test on Windows, macOS, Linux
• Test different OS versions
• Verify installation and functionality

3. Device Compatibility:

• Test on different devices (desktop, tablet, mobile)
• Test various screen sizes and resolutions
• Verify responsive design

4. Network Compatibility:

• Test on different network types (3G, 4G, 5G, WiFi)
• Test with varying bandwidth
• Verify offline functionality

5. Database Compatibility:

• Test with different database systems (MySQL, PostgreSQL, Oracle)
• Test different database versions
• Verify data integrity

6. Software Compatibility:

• Test integration with third-party software
• Test with different software versions
• Verify backward compatibility

Testing Approach:

1. Identify target platforms and configurations
2. Set up test environments
3. Execute test cases on each configuration
4. Log compatibility issues
5. Verify fixes across all platforms

Answer:

End-to-End Testing validates the complete application flow from start to finish, ensuring all integrated components work together as expected in real-world scenarios.

Key Characteristics:

• Complete Flow: Tests entire user journeys
• Real Environment: Uses production-like setup
• All Layers: Tests UI, API, database, external services
• User Perspective: Simulates actual user behavior

Example E2E Test Scenarios:

1. E-commerce Purchase:
   • Browse products → Add to cart → Checkout → Payment → Order confirmation → Email notification
2. User Registration:
   • Fill form → Email verification → Login → Profile setup → Welcome email
3. Banking Transaction:
   • Login → Check balance → Transfer money → Verify transaction → Logout

E2E Testing Tools:

• Selenium WebDriver
• Cypress
• Playwright
• TestCafe
• Puppeteer

Advantages:

• Validates complete user workflows
• Catches integration issues
• Ensures system works as a whole
• Builds confidence in releases

Challenges:

• Time-consuming to execute
• Complex to maintain
• Requires stable test environment
• Can be flaky due to dependencies

Answer:

Usability Testing evaluates how easy and user-friendly an application is by observing real users as they interact with the product.

Key Aspects to Test:

• Learnability: How easy is it for new users to learn?
• Efficiency: How quickly can users complete tasks?
• Memorability: Can users remember how to use it?
• Errors: How many errors do users make?
• Satisfaction: How pleasant is the experience?

Usability Testing Methods:

1. Moderated Testing: Facilitator guides users through tasks
2. Unmoderated Testing: Users complete tasks independently
3. Remote Testing: Users test from their location
4. In-Person Testing: Users test in a lab setting
5. A/B Testing: Compare two versions

What to Evaluate:

• Navigation and menu structure
• Form design and input fields
• Button placement and labeling
• Error messages clarity
• Visual hierarchy and layout
• Mobile responsiveness
• Accessibility features

Metrics:

• Task completion rate
• Time on task
• Error rate
• User satisfaction score (SUS)
• Net Promoter Score (NPS)

Answer:

API Testing is a type of software testing that validates Application Programming Interfaces (APIs) to ensure they meet expectations for functionality, reliability, performance, and security.

What is Tested in API Testing:

• Functionality: Does the API return correct responses?
• Reliability: Is the API consistently available?
• Performance: How fast does the API respond?
• Security: Is the API protected against threats?
• Data Validation: Are request/response formats correct?
• Error Handling: Does it handle errors gracefully?

Types of API Testing:

1. Functional Testing: Verify API functions work correctly
2. Load Testing: Test API under expected load
3. Security Testing: Check for vulnerabilities
4. Integration Testing: Test API with other systems
5. Validation Testing: Verify data formats and schemas
6. Negative Testing: Test with invalid inputs

Why API Testing is Important:

• APIs are the backbone of modern applications
• Faster than UI testing
• Language-independent testing
• Early detection of issues
• Better test coverage
• Supports CI/CD pipelines

Popular API Testing Tools:

• Postman
• REST Assured
• SoapUI
• JMeter
• Karate DSL

Answer:

REST (Representational State Transfer):

• Type: Architectural style
• Protocol: Uses HTTP/HTTPS
• Data Format: JSON, XML, HTML, plain text
• Performance: Faster, lightweight
• Caching: Supports caching
• Stateless: Each request is independent
• Use Case: Web services, mobile apps, microservices

SOAP (Simple Object Access Protocol):

• Type: Protocol with strict standards
• Protocol: Can use HTTP, SMTP, TCP
• Data Format: Only XML
• Performance: Slower, more overhead
• Caching: No built-in caching
• Stateful: Can maintain state
• Use Case: Enterprise applications, financial services

Key Differences:

• Security: REST uses HTTPS/OAuth; SOAP has built-in WS-Security
• Error Handling: REST uses HTTP status codes; SOAP uses fault elements
• Bandwidth: REST requires less bandwidth
• Flexibility: REST is more flexible; SOAP is more rigid

When to Use REST:

• Public APIs and web services
• Mobile applications
• Microservices architecture
• When performance is critical

When to Use SOAP:

• Enterprise-level security required
• ACID compliance needed
• Formal contracts (WSDL)
• Legacy system integration

Answer:

1. GET:

• Purpose: Retrieve data from server
• Idempotent: Yes (same result on multiple calls)
• Safe: Yes (doesn't modify data)
• Cacheable: Yes
• Body: No request body
• Example: GET /api/users/123

2. POST:

• Purpose: Create new resource
• Idempotent: No (creates new resource each time)
• Safe: No (modifies data)
• Cacheable: Rarely
• Body: Contains data to create
• Example: POST /api/users (with user data in body)

3. PUT:

• Purpose: Update/replace entire resource
• Idempotent: Yes
• Safe: No
• Cacheable: No
• Body: Contains complete updated data
• Example: PUT /api/users/123 (replaces entire user)

4. PATCH:

• Purpose: Partial update of resource
• Idempotent: Can be (depends on implementation)
• Safe: No
• Cacheable: No
• Body: Contains only fields to update
• Example: PATCH /api/users/123 (updates specific fields)

5. DELETE:

• Purpose: Remove resource
• Idempotent: Yes
• Safe: No
• Cacheable: No
• Body: Usually no body
• Example: DELETE /api/users/123

PUT vs PATCH Example:

PUT Request (replaces entire resource):

PUT /api/users/123
{
  "name": "John Smith",
  "email": "john.smith@example.com",
  "age": 31
}

PATCH Request (updates only specified fields):

PATCH /api/users/123
{
  "name": "John Smith"
}

Answer:

HTTP Status Codes are three-digit numbers returned by servers to indicate the result of an HTTP request.

2xx - Success:

• 200 OK: Request successful (GET, PUT, PATCH)
• 201 Created: Resource created successfully (POST)
• 204 No Content: Success but no content to return (DELETE)

4xx - Client Errors:

• 400 Bad Request: Invalid request syntax
• 401 Unauthorized: Authentication required
• 403 Forbidden: Server refuses to authorize
• 404 Not Found: Resource doesn't exist
• 405 Method Not Allowed: HTTP method not supported
• 409 Conflict: Request conflicts with current state
• 422 Unprocessable Entity: Validation errors
• 429 Too Many Requests: Rate limit exceeded

5xx - Server Errors:

• 500 Internal Server Error: Generic server error
• 502 Bad Gateway: Invalid response from upstream server
• 503 Service Unavailable: Server temporarily unavailable
• 504 Gateway Timeout: Upstream server timeout

Testing Scenarios:

• Verify correct status code for each operation
• Test error handling (4xx, 5xx responses)
• Validate response body matches status code
• Check status codes for edge cases

Answer:

1. Basic Authentication:

• Username and password encoded in Base64
• Sent in Authorization header
• Format: Authorization: Basic base64(username:password)
• Pros: Simple to implement
• Cons: Not secure without HTTPS

2. API Key:

• Unique key assigned to each client
• Sent in header, query parameter, or body
• Example: X-API-Key: your-api-key-here
• Pros: Easy to implement and revoke
• Cons: Can be exposed if not handled properly

3. Bearer Token (JWT):

• JSON Web Token containing encoded claims
• Format: Authorization: Bearer <token>
• Self-contained with expiration
• Pros: Stateless, scalable
• Cons: Cannot revoke before expiration

4. OAuth 2.0:

• Industry-standard authorization framework
• Uses access tokens and refresh tokens
• Multiple grant types (authorization code, client credentials)
• Pros: Secure, widely adopted
• Cons: Complex to implement

Testing Authentication:

• Test with valid credentials
• Test with invalid/expired tokens
• Test without authentication
• Test token refresh mechanism
• Verify proper error messages (401, 403)

Answer:

Postman is a popular API testing tool that allows you to create, test, and document APIs through an intuitive interface.

Key Features:

1. Request Building: Select HTTP method, enter URL, add headers/body
2. Collections: Group related API requests together
3. Environment Variables: Store values like base URL, tokens
4. Tests/Assertions: Write JavaScript tests to validate responses
5. Pre-request Scripts: Execute code before sending request
6. Collection Runner: Run multiple requests in sequence
7. Mock Servers: Create mock API responses
8. Documentation: Auto-generate API documentation

Common Test Examples:

// Check status code
pm.test("Status code is 200", () => {
    pm.response.to.have.status(200);
});

// Validate response time
pm.test("Response time < 500ms", () => {
    pm.expect(pm.response.responseTime).to.be.below(500);
});

// Check JSON response
pm.test("Response has user data", () => {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property('name');
    pm.expect(jsonData.name).to.eql('John Doe');
});

// Set environment variable
pm.environment.set("userId", pm.response.json().id);

Best Practices:

• Use environment variables for different environments (dev, staging, prod)
• Organize requests into collections
• Write comprehensive tests for each request
• Use pre-request scripts for dynamic data
• Integrate with CI/CD using Newman (Postman CLI)

Answer:

1. Functional Test Cases:

• Verify API returns correct response for valid request
• Test all HTTP methods (GET, POST, PUT, DELETE, PATCH)
• Validate response status codes
• Verify response body structure and data
• Test with different input combinations
• Validate response headers

2. Negative Test Cases:

• Test with invalid API endpoint
• Test with invalid HTTP method
• Test with missing required parameters
• Test with invalid data types
• Test with out-of-range values
• Test with special characters and SQL injection
• Test with empty/null values

3. Authentication & Authorization:

• Test without authentication token
• Test with invalid/expired token
• Test with valid token
• Test role-based access control
• Test token refresh mechanism

4. Performance Test Cases:

• Verify response time is within acceptable limits
• Test API under load (concurrent users)
• Test with large payload
• Verify API handles timeout scenarios

5. Data Validation:

• Validate JSON/XML schema
• Verify data types in response
• Check for required vs optional fields
• Validate date formats
• Verify enum values

Example Test Case:

Test Case: Create User API

• Endpoint: POST /api/users
• Headers: Content-Type: application/json, Authorization: Bearer token
• Body: {"name": "John", "email": "john@test.com"}
• Expected: Status 201, Response contains user ID
• Validation: User created in database

Answer:

JSON (JavaScript Object Notation):

• Syntax: Lightweight, easy to read
• Data Types: Supports strings, numbers, booleans, arrays, objects, null
• Size: Smaller file size
• Parsing: Faster to parse
• Use Case: Modern web APIs, mobile apps

Example JSON:

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

XML (eXtensible Markup Language):

• Syntax: More verbose, tag-based
• Data Types: Everything is text (requires parsing)
• Size: Larger file size
• Parsing: Slower to parse
• Use Case: Enterprise systems, SOAP APIs, legacy systems

Example XML:

<user>
  <id>123</id>
  <name>John Doe</name>
  <email>john@example.com</email>
  <active>true</active>
</user>

Key Differences:

• Readability: JSON is more readable and concise
• Arrays: JSON has native array support; XML doesn't
• Namespaces: XML supports namespaces; JSON doesn't
• Comments: XML supports comments; JSON doesn't
• Metadata: XML has extensive metadata support via attributes

When to Use JSON:

• RESTful APIs
• Mobile applications
• Web applications
• When performance matters

When to Use XML:

• SOAP web services
• Complex document structures
• When metadata is important
• Legacy system integration

Answer:

API Versioning is the practice of managing changes to an API by creating different versions, allowing backward compatibility while introducing new features or breaking changes.

Why Versioning is Important:

• Prevents breaking existing client applications
• Allows gradual migration to new versions
• Supports multiple client versions simultaneously
• Enables testing new features without affecting production
• Provides clear communication about API changes

Common Versioning Strategies:

1. URI Versioning (Most Common):

GET /api/v1/users
GET /api/v2/users

• Pros: Clear, easy to understand, simple to implement
• Cons: Can lead to URI proliferation

2. Header Versioning:

GET /api/users
Headers: API-Version: 2

• Pros: Clean URIs, flexible
• Cons: Less visible, harder to test in browser

3. Query Parameter Versioning:

GET /api/users?version=2

• Pros: Easy to implement
• Cons: Can be overlooked, pollutes query string

Testing Different API Versions:

• Test all supported versions
• Verify backward compatibility
• Test version-specific features
• Validate proper error handling for unsupported versions
• Check deprecation warnings

Answer:

Rate Limiting is a technique used to control the number of requests a client can make to an API within a specific time period, preventing abuse and ensuring fair usage.

Why Rate Limiting is Important:

• Prevents API abuse and DDoS attacks
• Ensures fair resource distribution
• Protects server from overload
• Manages costs for cloud-based APIs
• Maintains quality of service for all users

Common Rate Limiting Strategies:

• Fixed Window: X requests per minute/hour
• Sliding Window: Rolling time window
• Token Bucket: Tokens replenish over time
• Leaky Bucket: Requests processed at constant rate

Rate Limit Response Headers:

X-RateLimit-Limit: 100
X-RateLimit-Remaining: 75
X-RateLimit-Reset: 1640995200
Retry-After: 60

Testing Rate Limiting:

1. Test Within Limits: Verify API works normally
2. Test Exceeding Limits: Send requests beyond limit
3. Verify Status Code: Should return 429 (Too Many Requests)
4. Check Headers: Validate rate limit headers
5. Test Reset: Verify limits reset after time window
6. Test Different Users: Ensure limits are per-user/per-key

Example Test Scenario:

// Send 100 requests (within limit)
for (let i = 0; i < 100; i++) {
    // Should return 200 OK
}

// Send 101st request (exceeds limit)
// Should return 429 Too Many Requests
// Response should include Retry-After header

Answer:

Selenium is an open-source automation testing framework used for automating web applications across different browsers and platforms.

Selenium Components:

1. Selenium WebDriver:

• Core component for browser automation
• Directly communicates with browsers
• Supports multiple programming languages (Java, Python, C#, JavaScript)
• Supports multiple browsers (Chrome, Firefox, Safari, Edge)
• Most widely used component

2. Selenium IDE:

• Browser extension for record and playback
• Good for quick prototyping
• Limited functionality compared to WebDriver
• Available for Chrome and Firefox

3. Selenium Grid:

• Enables parallel test execution
• Runs tests on multiple machines simultaneously
• Supports different browsers and OS combinations
• Reduces test execution time

Key Features of Selenium:

• Open-source and free
• Cross-browser testing support
• Multiple programming language support
• Integration with testing frameworks (TestNG, JUnit, pytest)
• Large community and extensive documentation
• CI/CD integration support

Basic Selenium WebDriver Example (Python):

from selenium import webdriver
from selenium.webdriver.common.by import By

# Initialize driver
driver = webdriver.Chrome()

# Navigate to URL
driver.get("https://example.com")

# Find element and interact
element = driver.find_element(By.ID, "username")
element.send_keys("testuser")

# Click button
driver.find_element(By.ID, "login").click()

# Close browser
driver.quit()

When to Use Selenium:

• Web application testing
• Cross-browser compatibility testing
• Regression testing
• Data-driven testing
• Continuous integration pipelines

Answer:

Locators are used to identify and interact with web elements on a page. Selenium provides multiple strategies to locate elements.

Types of Locators:

1. ID:

• Most reliable and fastest
• Should be unique on the page
• Example: driver.find_element(By.ID, "username")

2. Name:

• Uses the name attribute
• May not be unique
• Example: driver.find_element(By.NAME, "email")

3. Class Name:

• Uses CSS class attribute
• Often not unique (multiple elements can share same class)
• Example: driver.find_element(By.CLASS_NAME, "btn-primary")

4. Tag Name:

• Uses HTML tag name
• Useful for finding all elements of a type
• Example: driver.find_elements(By.TAG_NAME, "input")

5. Link Text:

• For anchor tags with exact text match
• Example: driver.find_element(By.LINK_TEXT, "Click Here")

6. Partial Link Text:

• For anchor tags with partial text match
• Example: driver.find_element(By.PARTIAL_LINK_TEXT, "Click")

7. CSS Selector:

• Powerful and flexible
• Faster than XPath
• Example: driver.find_element(By.CSS_SELECTOR, "#username")
• Example: driver.find_element(By.CSS_SELECTOR, ".btn-primary")
• Example: driver.find_element(By.CSS_SELECTOR, "input[type='email']")

8. XPath:

• Most powerful but slower
• Can traverse up and down the DOM
• Absolute XPath: //html/body/div/form/input
• Relative XPath: //input[@id='username']
• Example: driver.find_element(By.XPATH, "//button[text()='Submit']")

Best Practices:

1. Prefer ID when available (fastest and most reliable)
2. Use CSS Selector over XPath when possible (better performance)
3. Avoid absolute XPath (brittle, breaks easily)
4. Use data-testid or custom attributes for test automation
5. Keep locators maintainable and readable

Locator Priority (Recommended Order):

1. ID
2. Name
3. CSS Selector
4. XPath (as last resort)

Answer:

Page Object Model (POM) is a design pattern that creates an object repository for web UI elements, separating test logic from page-specific code.

Key Concepts:

• Each web page is represented as a class
• Page elements are defined as variables
• User interactions are defined as methods
• Test scripts use page objects to interact with UI

Benefits of POM:

• Maintainability: Changes in UI require updates in one place only
• Reusability: Page objects can be reused across multiple tests
• Readability: Tests are more readable and understandable
• Separation of Concerns: Test logic separated from page structure
• Reduced Code Duplication: Common actions defined once

Example Without POM:

# Test script (not recommended)
driver.find_element(By.ID, "username").send_keys("user")
driver.find_element(By.ID, "password").send_keys("pass")
driver.find_element(By.ID, "login-btn").click()

Example With POM:

# Page Object Class
class LoginPage:
    def __init__(self, driver):
        self.driver = driver
        self.username_field = (By.ID, "username")
        self.password_field = (By.ID, "password")
        self.login_button = (By.ID, "login-btn")

    def enter_username(self, username):
        self.driver.find_element(*self.username_field).send_keys(username)

    def enter_password(self, password):
        self.driver.find_element(*self.password_field).send_keys(password)

    def click_login(self):
        self.driver.find_element(*self.login_button).click()

    def login(self, username, password):
        self.enter_username(username)
        self.enter_password(password)
        self.click_login()

# Test script (clean and maintainable)
login_page = LoginPage(driver)
login_page.login("user", "pass")

POM Best Practices:

• One page object class per web page
• Keep page objects independent of tests
• Use meaningful method names
• Return page objects for method chaining
• Don't include assertions in page objects
• Use Page Factory for initialization (in Java)

Answer:

Waits in Selenium are used to handle synchronization issues when elements take time to load, preventing test failures due to timing issues.

Types of Waits:

1. Implicit Wait:

• Global wait applied to all elements
• Waits for specified time before throwing NoSuchElementException
• Set once and applies throughout the test
• Not recommended for modern tests

# Python
driver.implicitly_wait(10)  # Wait up to 10 seconds

// Java
driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10));

2. Explicit Wait:

• Wait for specific condition on specific element
• More flexible and recommended
• Can wait for various conditions (visibility, clickability, etc.)
• Throws TimeoutException if condition not met

# Python
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

wait = WebDriverWait(driver, 10)
element = wait.until(EC.presence_of_element_located((By.ID, "myElement")))
element = wait.until(EC.element_to_be_clickable((By.ID, "button")))

3. Fluent Wait:

• More customizable than explicit wait
• Can define polling frequency
• Can ignore specific exceptions

# Python
from selenium.webdriver.support.ui import WebDriverWait

wait = WebDriverWait(driver, timeout=10, poll_frequency=1,
                     ignored_exceptions=[NoSuchElementException])
element = wait.until(EC.presence_of_element_located((By.ID, "myElement")))

Common Expected Conditions:

• presence_of_element_located - Element present in DOM
• visibility_of_element_located - Element visible on page
• element_to_be_clickable - Element visible and enabled
• invisibility_of_element - Element not visible
• text_to_be_present_in_element - Specific text in element
• alert_is_present - Alert is present

Best Practices:

• Prefer explicit waits over implicit waits
• Avoid Thread.sleep() (hard waits)
• Use appropriate expected conditions
• Set reasonable timeout values
• Don't mix implicit and explicit waits

Answer:

Both TestNG and JUnit are popular testing frameworks for Java, but TestNG offers more advanced features for test automation.

Key Differences:

Annotations:

• TestNG: @BeforeSuite, @AfterSuite, @BeforeTest, @AfterTest, @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod
• JUnit: @BeforeAll, @AfterAll, @BeforeEach, @AfterEach (fewer options)

Test Dependencies:

• TestNG: Supports test dependencies using dependsOnMethods
• JUnit: No built-in support for dependencies

Parallel Execution:

• TestNG: Built-in support for parallel execution
• JUnit: Limited parallel execution support

Parameterization:

• TestNG: @DataProvider for complex parameterization
• JUnit: @ParameterizedTest (simpler)

Grouping:

• TestNG: Can group tests and run specific groups
• JUnit: Uses @Tag (less flexible)

Reporting:

• TestNG: Built-in HTML reports
• JUnit: Requires external tools for detailed reports

TestNG Example:

@Test(priority = 1, groups = {"smoke"})
public void loginTest() {
    // Test code
}

@Test(priority = 2, dependsOnMethods = {"loginTest"})
public void dashboardTest() {
    // Test code
}

@DataProvider(name = "testData")
public Object[][] getData() {
    return new Object[][] {{"user1", "pass1"}, {"user2", "pass2"}};
}

@Test(dataProvider = "testData")
public void loginWithData(String username, String password) {
    // Test with different data
}

When to Use:

• TestNG: Complex test suites, parallel execution, data-driven testing, Selenium automation
• JUnit: Simple unit tests, Spring Boot applications, basic testing needs

Answer:

1. Handling Alerts:

JavaScript alerts can be accepted, dismissed, or text can be retrieved/entered.

# Python
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

# Wait for alert
wait = WebDriverWait(driver, 10)
alert = wait.until(EC.alert_is_present())

# Get alert text
alert_text = alert.text

# Accept alert (click OK)
alert.accept()

# Dismiss alert (click Cancel)
alert.dismiss()

# Enter text in prompt
alert.send_keys("Test input")
alert.accept()

2. Handling Multiple Windows/Tabs:

# Get current window handle
main_window = driver.current_window_handle

# Get all window handles
all_windows = driver.window_handles

# Switch to new window
for window in all_windows:
    if window != main_window:
        driver.switch_to.window(window)
        # Perform actions in new window
        driver.close()  # Close new window

# Switch back to main window
driver.switch_to.window(main_window)

3. Handling iFrames:

# Switch to iframe by index
driver.switch_to.frame(0)

# Switch to iframe by name or ID
driver.switch_to.frame("frameName")

# Switch to iframe by WebElement
iframe_element = driver.find_element(By.ID, "iframeId")
driver.switch_to.frame(iframe_element)

# Switch back to main content
driver.switch_to.default_content()

# Switch to parent frame
driver.switch_to.parent_frame()

4. Handling Pop-ups (Browser Notifications):

# Disable notifications in Chrome
from selenium.webdriver.chrome.options import Options

chrome_options = Options()
chrome_options.add_argument("--disable-notifications")
driver = webdriver.Chrome(options=chrome_options)

Best Practices:

• Always wait for alerts before interacting
• Store original window handle before opening new windows
• Always switch back to default content after iframe operations
• Close windows/tabs when done to avoid memory leaks

Answer:

Cypress:

• Architecture: Runs inside the browser
• Language: JavaScript/TypeScript only
• Browsers: Chrome, Edge, Firefox, Electron
• Speed: Faster execution
• Setup: Easier setup, less configuration
• Debugging: Excellent debugging with time-travel
• Waits: Automatic waiting built-in
• Screenshots/Videos: Automatic on failure
• Limitations: No Safari support, single tab only, same-origin policy restrictions

Selenium:

• Architecture: Communicates with browser via WebDriver
• Language: Java, Python, C#, JavaScript, Ruby, etc.
• Browsers: All major browsers including Safari
• Speed: Slower than Cypress
• Setup: More complex setup
• Debugging: More challenging
• Waits: Manual wait configuration needed
• Screenshots/Videos: Requires additional setup
• Advantages: Multi-tab support, cross-domain testing, mobile testing (Appium)

Cypress Example:

describe('Login Test', () => {
  it('should login successfully', () => {
    cy.visit('https://example.com/login')
    cy.get('#username').type('testuser')
    cy.get('#password').type('password123')
    cy.get('#login-btn').click()
    cy.url().should('include', '/dashboard')
    cy.contains('Welcome').should('be.visible')
  })
})

When to Use:

• Cypress: Modern web apps, JavaScript/TypeScript teams, fast feedback, excellent debugging needed
• Selenium: Multi-browser support needed, multiple languages, mobile testing, legacy applications

Answer:

CI/CD integration allows automated tests to run automatically on code changes, providing fast feedback and ensuring quality before deployment.

Common CI/CD Tools:

• Jenkins
• GitHub Actions
• GitLab CI/CD
• Azure DevOps
• CircleCI
• Travis CI

GitHub Actions Example:

name: Run Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: '3.9'

    - name: Install dependencies
      run: |
        pip install -r requirements.txt

    - name: Run tests
      run: |
        pytest tests/ --html=report.html

    - name: Upload test results
      if: always()
      uses: actions/upload-artifact@v2
      with:
        name: test-results
        path: report.html

Jenkins Pipeline Example:

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                git 'https://github.com/your-repo.git'
            }
        }

        stage('Install Dependencies') {
            steps {
                sh 'npm install'
            }
        }

        stage('Run Tests') {
            steps {
                sh 'npm test'
            }
        }

        stage('Generate Report') {
            steps {
                publishHTML([reportDir: 'reports', reportFiles: 'index.html'])
            }
        }
    }

    post {
        always {
            junit 'test-results/*.xml'
        }
    }
}

Best Practices:

• Run tests on every commit/pull request
• Separate test suites (smoke, regression, full)
• Run critical tests first for fast feedback
• Generate and archive test reports
• Send notifications on test failures
• Use parallel execution to reduce time
• Maintain test environment consistency

Benefits:

• Early bug detection
• Faster feedback to developers
• Automated quality gates
• Reduced manual testing effort
• Consistent test execution

Answer:

Flaky tests are automated tests that produce inconsistent results - sometimes passing and sometimes failing without any code changes.

Common Causes of Flaky Tests:

1. Timing Issues:
   • Insufficient waits for elements to load
   • Race conditions
   • Network latency
2. Test Dependencies:
   • Tests depending on execution order
   • Shared state between tests
   • Database state not cleaned up
3. External Dependencies:
   • Third-party API failures
   • Test environment instability
   • Resource contention
4. Concurrency Issues:
   • Parallel test execution conflicts
   • Shared resources

How to Fix Flaky Tests:

1. Fix Timing Issues:

# Bad: Hard wait
time.sleep(5)

# Good: Explicit wait
wait = WebDriverWait(driver, 10)
element = wait.until(EC.element_to_be_clickable((By.ID, "button")))

2. Ensure Test Independence:

# Use setup and teardown
def setup_method(self):
    self.driver = webdriver.Chrome()
    # Clean state for each test

def teardown_method(self):
    self.driver.quit()
    # Clean up resources

3. Mock External Dependencies:

# Mock API responses instead of calling real APIs
@mock.patch('requests.get')
def test_api_call(mock_get):
    mock_get.return_value.json.return_value = {'status': 'success'}
    # Test with mocked response

4. Use Unique Test Data:

# Generate unique data for each test run
import uuid
test_email = f"test_{uuid.uuid4()}@example.com"

Best Practices:

• Identify and fix flaky tests immediately
• Track flaky test metrics
• Isolate tests from each other
• Use proper waits (explicit over implicit)
• Avoid hard-coded waits (Thread.sleep)
• Clean up test data after each test
• Run tests multiple times to identify flakiness
• Quarantine consistently flaky tests

Answer:

Severity: Impact of the bug on the application's functionality

Priority: Urgency of fixing the bug from business perspective

Severity Levels:

• Critical: Application crash, data loss, security breach
• Major: Major functionality broken
• Minor: Minor functionality issue
• Trivial: UI/cosmetic issues

Priority Levels:

• P1 (High): Must fix immediately
• P2 (Medium): Fix in next release
• P3 (Low): Fix when time permits

Examples:

1. High Severity, High Priority:

• Example: Payment gateway not working on e-commerce site
• Impact: Critical business loss
• Action: Fix immediately

2. High Severity, Low Priority:

• Example: Crash in rarely used admin feature
• Impact: Severe but affects few users
• Action: Can be scheduled for next release

3. Low Severity, High Priority:

• Example: Company logo misspelled on homepage
• Impact: Minor technical issue but major brand impact
• Action: Fix immediately for business reasons

4. Low Severity, Low Priority:

• Example: Minor UI alignment issue in footer
• Impact: Minimal impact on users and business
• Action: Fix when convenient

Who Decides:

• Severity: Determined by QA/Testers based on technical impact
• Priority: Determined by Product Owner/Business based on business needs

Answer:

Functional Test Scenarios:

1. Valid Credentials: Login with correct username and password
2. Invalid Username: Login with wrong username
3. Invalid Password: Login with wrong password
4. Empty Fields: Submit with empty username/password
5. Case Sensitivity: Test if username/password are case-sensitive
6. Special Characters: Test with special characters in credentials
7. SQL Injection: Test with SQL injection strings
8. Remember Me: Verify "Remember Me" functionality
9. Forgot Password: Test password reset flow
10. Account Lockout: Test after multiple failed attempts
11. Session Timeout: Verify session expires after inactivity
12. Logout: Verify logout clears session

UI/UX Test Scenarios:

• Verify password is masked
• Check "Show Password" toggle works
• Verify error messages are clear and helpful
• Test tab navigation between fields
• Verify Enter key submits form
• Check responsive design on mobile

Security Test Scenarios:

• Verify HTTPS is used
• Check password is not visible in network requests
• Test CAPTCHA after failed attempts
• Verify session token is secure
• Test against brute force attacks
• Check for XSS vulnerabilities

Performance Test Scenarios:

• Test login response time
• Test with concurrent users
• Verify behavior under load

Compatibility Test Scenarios:

• Test on different browsers (Chrome, Firefox, Safari, Edge)
• Test on different devices (Desktop, Mobile, Tablet)
• Test on different OS (Windows, Mac, Linux, iOS, Android)

Edge Cases:

• Very long username/password
• Leading/trailing spaces in credentials
• Copy-paste credentials
• Browser back button after login
• Direct URL access to protected pages

Answer:

Immediate Actions:

1. Assess Impact:
   • How many users are affected?
   • What functionality is broken?
   • Is there data loss or security risk?
   • What is the business impact?
2. Notify Stakeholders:
   • Alert product owner/manager
   • Inform development team
   • Notify customer support team
   • Update status page if applicable
3. Document the Bug:
   • Create detailed bug report
   • Include steps to reproduce
   • Attach screenshots/logs
   • Note affected environment/version
4. Reproduce the Issue:
   • Verify in production (if safe)
   • Reproduce in staging/test environment
   • Identify root cause
5. Determine Fix Strategy:
   • Hotfix deployment
   • Rollback to previous version
   • Feature flag to disable broken feature
   • Temporary workaround
6. Test the Fix:
   • Verify fix in test environment
   • Run regression tests
   • Perform smoke testing
   • Get approval for deployment
7. Deploy and Monitor:
   • Deploy fix to production
   • Monitor application logs
   • Verify fix is working
   • Monitor user reports
8. Post-Mortem:
   • Conduct root cause analysis
   • Document lessons learned
   • Update test cases to prevent recurrence
   • Improve testing process if needed

Communication Template:

Subject: CRITICAL: Production Issue - [Feature Name]

Impact: [High/Medium/Low]
Affected Users: [Number/Percentage]
Status: [Investigating/Fix in Progress/Resolved]

Description:
[Brief description of the issue]

Steps Being Taken:
1. [Action 1]
2. [Action 2]

ETA for Fix: [Time estimate]

Updates will be provided every [X] hours.

Key Principles:

• Stay calm and focused
• Communicate clearly and frequently
• Prioritize user impact
• Document everything
• Learn from the incident

Answer:

Functional Test Cases:

TC01: Search with Valid Product Name

• Precondition: User is on homepage
• Steps: Enter "iPhone 15" in search box, Click search
• Expected: Display relevant iPhone 15 products

TC02: Search with Partial Product Name

• Steps: Enter "iPho" in search box
• Expected: Display auto-suggestions with iPhone products

TC03: Search with Non-Existent Product

• Steps: Enter "xyz123abc" in search box
• Expected: Display "No results found" message with suggestions

TC04: Search with Empty Input

• Steps: Click search without entering text
• Expected: Display validation message or show popular products

TC05: Search with Special Characters

• Steps: Enter "@#$%" in search box
• Expected: Handle gracefully, show no results or error message

TC06: Search with Category Filter

• Steps: Search "shoes", apply "Men's" category filter
• Expected: Display only men's shoes

TC07: Search with Price Range Filter

• Steps: Search "laptop", set price range $500-$1000
• Expected: Display laptops within price range

TC08: Search Result Sorting

• Steps: Search "headphones", sort by "Price: Low to High"
• Expected: Results sorted by ascending price

TC09: Search with Misspelled Word

• Steps: Enter "ipone" instead of "iphone"
• Expected: Show "Did you mean: iPhone?" suggestion

TC10: Search History

• Steps: Perform multiple searches, click search box again
• Expected: Display recent search history

Performance Test Cases:

• TC11: Search response time should be < 2 seconds
• TC12: Auto-suggestions should appear within 500ms
• TC13: Search should handle 1000 concurrent users

UI/UX Test Cases:

• TC14: Search box is visible on all pages
• TC15: Search icon is clickable
• TC16: Enter key triggers search
• TC17: Search results display product image, name, price
• TC18: Pagination works correctly for large result sets

Security Test Cases:

• TC19: Test SQL injection in search input
• TC20: Test XSS attacks in search query

Answer:

Key Principles of Agile Testing:

• Testing is continuous throughout the sprint
• Testers are part of the development team
• Early and frequent feedback
• Collaboration between developers and testers
• Test automation is emphasized
• Focus on preventing defects, not just finding them

Testing Activities in Scrum:

Sprint Planning:

• Review user stories and acceptance criteria
• Identify testable scenarios
• Estimate testing effort
• Plan test automation tasks

During Sprint:

• Write test cases based on user stories
• Perform continuous testing as features are developed
• Collaborate with developers on test scenarios
• Automate regression tests
• Participate in daily standups
• Update test documentation

Sprint Review/Demo:

• Demonstrate tested features to stakeholders
• Validate acceptance criteria are met
• Gather feedback

Sprint Retrospective:

• Discuss what went well in testing
• Identify testing improvements
• Plan process enhancements

Agile Testing Quadrants:

Q1: Technology-Facing, Supporting Development

• Unit tests
• Component tests

Q2: Business-Facing, Supporting Development

• Functional tests
• Story tests
• Prototypes

Q3: Business-Facing, Critiquing Product

• Exploratory testing
• Usability testing
• UAT

Q4: Technology-Facing, Critiquing Product

• Performance testing
• Security testing
• Load testing

Definition of Done (DoD):

• Code is written and reviewed
• Unit tests are written and passing
• Integration tests are passing
• Acceptance criteria are met
• No critical/major bugs
• Documentation is updated
• Feature is deployed to test environment

Benefits of Agile Testing:

• Early defect detection
• Faster feedback cycles
• Better collaboration
• Continuous improvement
• Higher quality deliverables

Answer:

Mobile-Specific Testing Areas:

1. Device Fragmentation:

• Multiple screen sizes and resolutions
• Different OS versions (iOS, Android)
• Various device manufacturers
• Different hardware capabilities

2. Network Conditions:

• Test on WiFi, 4G, 5G, 3G, 2G
• Test offline functionality
• Test network switching
• Test poor network conditions

3. Battery Consumption:

• Monitor battery drain
• Test app behavior on low battery
• Verify background processes

4. Interruptions:

• Incoming calls during app use
• SMS/notifications
• Alarm triggers
• Low battery warnings
• App switching

5. Touch Gestures:

• Tap, double-tap
• Swipe (left, right, up, down)
• Pinch to zoom
• Long press
• Multi-touch gestures

6. Device Features:

• Camera functionality
• GPS/Location services
• Accelerometer/Gyroscope
• Bluetooth
• Biometric authentication (fingerprint, face ID)

7. App Installation & Updates:

• Fresh installation
• App updates
• Uninstallation
• Reinstallation
• Data persistence after update

8. Permissions:

• Camera permission
• Location permission
• Storage permission
• Contacts permission
• Notification permission

Mobile Testing Tools:

• Appium: Cross-platform mobile automation
• XCUITest: iOS native automation
• Espresso: Android native automation
• BrowserStack/Sauce Labs: Cloud device testing
• Firebase Test Lab: Google's testing infrastructure

Web vs Mobile Comparison:

Answer:

Essential Components of a Bug Report:

1. Bug ID/Title:

• Unique identifier
• Clear, concise title describing the issue
• Example: "Login button not responding on mobile Safari"

2. Summary/Description:

• Brief overview of the bug
• What is broken and where

3. Steps to Reproduce:

• Detailed step-by-step instructions
• Should be clear enough for anyone to reproduce

4. Expected Result:

• What should happen (correct behavior)

5. Actual Result:

• What actually happens (incorrect behavior)

6. Environment Details:

• Operating System (Windows 11, macOS 14, etc.)
• Browser/App version
• Device (if mobile)
• Screen resolution
• Test environment (Dev, QA, Staging, Production)

7. Severity & Priority:

• Severity: Critical, Major, Minor, Trivial
• Priority: High, Medium, Low

8. Attachments:

• Screenshots showing the issue
• Screen recordings/videos
• Log files
• Network traces

9. Additional Information:

• Frequency: Always, Sometimes, Rarely
• Workaround (if any)
• Related bugs
• User impact

Example Bug Report:

Bug ID: BUG-1234
Title: Login button unresponsive on iPhone Safari

Summary:
The login button does not respond to tap on iPhone Safari browser.

Steps to Reproduce:
1. Open Safari on iPhone 13
2. Navigate to https://example.com/login
3. Enter valid username: testuser@example.com
4. Enter valid password: Test@123
5. Tap the "Login" button

Expected Result:
User should be logged in and redirected to dashboard

Actual Result:
Nothing happens when tapping the login button. No error message displayed.

Environment:
- Device: iPhone 13
- OS: iOS 17.2
- Browser: Safari 17.2
- Environment: Production
- Screen Resolution: 390x844

Severity: Major
Priority: High

Attachments:
- screenshot_login_issue.png
- video_recording.mp4

Additional Info:
- Frequency: Always reproducible
- Works fine on Chrome iOS and desktop browsers
- Affects all iPhone users on Safari
- Workaround: Use Chrome browser on iPhone

Best Practices:

• Be specific and objective
• Use clear, professional language
• Include all relevant details
• Verify bug is reproducible before reporting
• Check for duplicates before creating new bug
• Update bug status as needed

Answer:

Database testing involves verifying data integrity, data validity, and database performance to ensure the application's data layer functions correctly.

Key Areas to Test:

1. Data Integrity:

• Verify data is correctly inserted, updated, and deleted
• Check foreign key relationships
• Validate constraints (NOT NULL, UNIQUE, CHECK)
• Verify triggers execute correctly

2. Data Validity:

• Verify correct data types
• Check data format (dates, emails, phone numbers)
• Validate data ranges
• Ensure no orphan records

3. Schema Validation:

• Verify table structures
• Check column names and data types
• Validate indexes
• Verify stored procedures and functions

4. CRUD Operations:

• Create: Verify INSERT operations
• Read: Verify SELECT queries return correct data
• Update: Verify UPDATE operations modify correct records
• Delete: Verify DELETE operations remove correct records

Common SQL Queries for Testing:

1. Verify Record Count:

SELECT COUNT(*) FROM users WHERE status = 'active';

2. Check for Duplicates:

SELECT email, COUNT(*)
FROM users
GROUP BY email
HAVING COUNT(*) > 1;

3. Verify Data Integrity:

-- Check for orphan records
SELECT * FROM orders
WHERE user_id NOT IN (SELECT id FROM users);

4. Validate Date Ranges:

SELECT * FROM orders
WHERE order_date > delivery_date;

5. Check NULL Values:

SELECT * FROM users
WHERE email IS NULL OR email = '';

Performance Testing:

• Query execution time
• Index effectiveness
• Database response under load
• Connection pooling

Tools for Database Testing:

• SQL queries (manual testing)
• Database management tools (MySQL Workbench, pgAdmin)
• Automated testing frameworks (DBUnit, SQLUnit)
• Performance tools (JMeter for DB load testing)

Answer:

Key Performance Metrics:

1. Response Time:

• Time taken to receive response after sending request
• Measured in milliseconds or seconds
• Target: < 2 seconds for web pages, < 500ms for APIs

2. Throughput:

• Number of requests processed per unit time
• Measured in requests/second or transactions/second
• Higher throughput = better performance

3. Concurrent Users:

• Number of users accessing system simultaneously
• Tests system capacity
• Example: 1000 concurrent users

4. Error Rate:

• Percentage of failed requests
• Target: < 1% error rate
• Includes HTTP errors (500, 503, etc.)

5. CPU Utilization:

• Percentage of CPU being used
• Target: < 70-80% under normal load
• High CPU may indicate performance bottleneck

6. Memory Usage:

• Amount of RAM consumed
• Monitor for memory leaks
• Should remain stable over time

7. Network Bandwidth:

• Data transfer rate
• Measured in Mbps or Gbps
• Important for data-heavy applications

8. Database Performance:

• Query execution time
• Connection pool usage
• Database locks and deadlocks

Performance Testing Types:

Load Testing:

• Test system under expected load
• Example: 500 concurrent users

Stress Testing:

• Test system beyond normal capacity
• Find breaking point

Spike Testing:

• Sudden increase in load
• Example: Black Friday traffic

Endurance Testing:

• Test system over extended period
• Detect memory leaks

Performance Testing Tools:

• JMeter: Open-source load testing tool
• LoadRunner: Enterprise performance testing
• Gatling: Modern load testing framework
• K6: Developer-centric load testing
• Locust: Python-based load testing

Acceptable Performance Benchmarks:

• Page load time: < 3 seconds
• API response time: < 500ms
• Database query: < 100ms
• Error rate: < 1%
• CPU usage: < 80%

Answer:

Key Components of Test Automation Framework:

1. Test Scripts:

• Automated test cases written in programming language
• Reusable and maintainable code
• Follow coding standards and best practices

2. Test Data:

• Input data for test execution
• Stored in external files (CSV, Excel, JSON, XML)
• Separates test logic from test data
• Enables data-driven testing

3. Object Repository:

• Centralized location for UI elements/locators
• Stores element identifiers (ID, XPath, CSS selectors)
• Easy maintenance when UI changes
• Reduces code duplication

4. Utility/Helper Functions:

• Reusable common functions
• Examples: date formatting, file operations, database connections
• Reduces code redundancy

5. Configuration Files:

• Store environment settings
• URLs, credentials, browser settings
• Easy to switch between environments (Dev, QA, Prod)

6. Test Execution Engine:

• Runs test scripts
• Manages test execution flow
• Examples: TestNG, JUnit, pytest

7. Reporting Mechanism:

• Generates test execution reports
• Shows pass/fail status
• Includes screenshots, logs, execution time
• Examples: Extent Reports, Allure Reports

8. Logging:

• Records test execution details
• Helps in debugging failures
• Different log levels (INFO, DEBUG, ERROR)

9. CI/CD Integration:

• Integration with Jenkins, GitHub Actions, etc.
• Automated test execution on code changes
• Continuous feedback

Framework Types:

1. Data-Driven Framework:

• Test data separated from test scripts
• Same test runs with different data sets

2. Keyword-Driven Framework:

• Keywords represent actions
• Non-technical users can create tests

3. Hybrid Framework:

• Combination of data-driven and keyword-driven
• Most flexible approach

4. BDD Framework:

• Behavior-Driven Development
• Uses Gherkin language (Given-When-Then)
• Tools: Cucumber, SpecFlow

Framework Structure Example:

test-automation-framework/
├── src/
│   ├── test/
│   │   ├── java/
│   │   │   ├── tests/          # Test scripts
│   │   │   ├── pages/          # Page Object Model
│   │   │   └── utils/          # Helper functions
│   ├── main/
│   │   └── resources/
│   │       ├── config/         # Configuration files
│   │       ├── testdata/       # Test data files
│   │       └── locators/       # Object repository
├── reports/                    # Test reports
├── logs/                       # Execution logs
├── screenshots/                # Failure screenshots
└── pom.xml                     # Dependencies

Benefits of Framework:

• Reusability of code
• Easy maintenance
• Scalability
• Consistent test execution
• Better collaboration

Answer:

This is a behavioral question that assesses your learning ability and adaptability. Here's a structured approach to answer:

My Learning Approach:

1. Understand the Fundamentals:

• Read official documentation
• Understand the tool's purpose and use cases
• Learn core concepts before diving into advanced features

2. Hands-On Practice:

• Set up the tool in local environment
• Follow tutorials and examples
• Create small practice projects
• Learn by doing, not just reading

3. Online Resources:

• Video tutorials (YouTube, Udemy, Pluralsight)
• Online courses and certifications
• Technical blogs and articles
• Community forums (Stack Overflow, Reddit)

4. Real-World Application:

• Apply learning to current projects
• Start with small, low-risk tasks
• Gradually increase complexity
• Get feedback from experienced team members

5. Community Engagement:

• Join testing communities and forums
• Attend webinars and conferences
• Participate in discussions
• Share knowledge with others

6. Continuous Practice:

• Regular practice to retain knowledge
• Build personal projects
• Contribute to open-source projects
• Stay updated with latest features

Example Answer:

"When learning a new testing tool, I start by understanding its core purpose and reading the official documentation. For example, when I learned Selenium, I first understood the WebDriver architecture, then set up a simple project to automate a login page. I supplemented this with online tutorials and practiced daily for 2 weeks. I also joined Selenium community forums to learn from others' experiences. Once comfortable with basics, I applied it to a real project at work, starting with simple test cases and gradually automating more complex scenarios. I believe in learning by doing and continuously improving through practice and feedback."

Key Points to Emphasize:

• Proactive learning attitude
• Structured approach to learning
• Practical application of knowledge
• Continuous improvement mindset
• Willingness to share knowledge

Resources I Use:

• Documentation: Official tool documentation
• Courses: Udemy, Coursera, Test Automation University
• Communities: Ministry of Testing, Test Automation Slack groups
• Blogs: Martin Fowler, James Bach, Angie Jones
• Practice: GitHub projects, personal portfolio