Testing & QA の面接質問

A test case represents a single lookup procedure for issues and errors.

Each test case should encompass specific attributes to ensure its efficacy as a validation tool in the software testing process:

• ID: Unique identifier, possibly generated by an automated system.
• Title: Descriptive summary of the test case.
• Description: Detailed account of the test case purpose, prerequisite steps, and expected outcomes.
• Steps to Reproduce: Procedural guide to replicate the test environment and provoke the expected result.
• Expected Outcome: Clearly defined desired or optimal test result or post-test state.
• Actual Outcome: Recorded results from test execution for comparison with the expected outcome.
• Comments: Space for the addition of ancillary information relating to the test case or its particular actions.
• Assigned To: Identification of the tester or group responsible for executing the test case.
• Last Updated: Timestamp noting the most recent alteration to the test case, including modifications to any of its elements.

Code Example: Test Case Attributes

Here is the Java code:

import java.util.List;
import java.time.LocalDateTime;

public class TestCase {
    private int id;
    private String title;
    private String description;
    private List<String> stepsToReproduce;
    private String expectedOutcome;
    private String actualOutcome;
    private String comments;
    private String assignedTo;
    private LocalDateTime lastUpdated;

    // Constructor, getters and setters
}

Automated testing provides numerous advantages, accelerating and enhancing the software development process across key areas.

Key Benefits

Reliability and Consistency

• Regular Execution: Automated tests are swiftly run after code changes, ensuring ongoing functionality and reducing the likelihood of regressions.

• Consistency: The absence of human error in test execution leads to more reliable and consistent results.

• Risk Mitigation: Early detection of issues reduces the chances of critical bugs, security vulnerabilities, and downtimes.

Time and Cost Efficiency

• Time Saving: Automated tests substantially reduce the time needed for testing, especially in repetitive tasks.

• Cost Effectiveness: The upfront investment in setting up automation is outweighed by long-term savings in manual testing efforts.

Insights and Reporting

• Detailed Reports: Automated tests generate comprehensive reports, pinpointing failures and exceptions for accelerated debugging.

• Code Coverage: Automation tools can track the percentage of codebase covered by tests, ensuring thorough testing.

• Actionable Insights: Data from automated tests informs decision-making on code readiness.

Team Productivity and Collaboration

• Rapid Feedback: Immediate test results enable developers to promptly address issues, fostering a more agile and iterative development process.

• Streamlined Communication: Known issues are tracked centrally with tools like JIRA, promoting better team coordination.

Codebase Integrity

• Continuous Integration and Deployment (CI/CD): Automated tests are intrinsic to CI/CD pipelines, validating code for rapid, reliable releases.

• Version Control Integration: Tools like Git integrate seamlessly with automated tests, ensuring code quality with each commit.

• Improved Code Quality: Early error detection and the ability to enforce coding standards lead to cleaner, more maintainable code.

User Satisfaction

• Enhanced UX: By pinpointing issues before deployment, automated tests help deliver a smoother, more reliable user experience.

Process Standardization

• Adherence to Standards: Automation leaves little room for deviation, ensuring teams comply with testing procedures and industry best practices.

White-box, black-box, and grey-box testing serve different purposes and are often used in tandem.

Black-Box Testing

In Black-Box testing, the tester is unfamiliar with the internal workings of the system. Tests are designed based on the system's specifications or requirements, ensuring that both the functional and non-functional requirements are met.

This type of testing is commonly performed during early development stages.

White-Box Testing

White-Box testing requires in-depth understanding of the internal structures of the system or software under test.

It is a structural testing method that ensures all or most paths and operations within the software are tested.

This testing method is also known as clear box testing, and glass box testing, and is more appropriate for later stages in the software development lifecycle.

Grey-Box Testing

In Grey-Box testing, the tester has access to some internal structures or algorithms of the software under test.

This kind of testing strives to achieve a balance between test coverage and system functionality. It combines the benefits of both white-box and black-box approaches.

Grey-Box testing is considered the most practical for real-world scenarios, especially when testing web applications, APIs, or distributed systems.

Software testing refers to all procedures driving, guiding, and evaluating system and application development. It ensures the quality of both the software being developed and the processes involved.

Importance of Software Testing

• Error Detection: Identifies bugs, discrepancies, or deviations from expected behavior.
• Risk Mitigation: Reduces the probability or impact of a software failure.
• Quality Assurance: Ensures the product aligns with users' expectations and business requirements.
• Customer Satisfaction: Allows for a reliable, user-friendly experience.
• Cost-Efficiency: Early defect detection is essential, as fixing errors becomes more costly over time.
• Process Improvement: Testing provides invaluable data for refining software development processes.

Positive Feedback Loops

• Prompting Fixing of Defects
• Building Confidence
• Learning from Mistakes
• Continuous Improvement

Areas of Testing

1. Unit Testing: Involves testing individual components or modules in isolation.
2. Integration Testing: Ensures that different parts of the system work together smoothly.
3. System Testing: Validates the product as a whole, usually in an environment closely resembling the production setting.
4. Acceptance Testing: Confirms that the system meets specific business requirements, making this the final validation phase before release.
5. Performance Testing: Assesses how the system performs under various load conditions.
6. Security Testing: Checks for vulnerabilities that could lead to breaches or data compromises.
7. Usability Testing: Focuses on how user-friendly the system is.

Common Misconceptions about Testing

1. Role Misinterpretation: Often seen as the epithet for Bug Tracking, Testing digs deeper into Risk Management, Requirement Analysis and Customer Feedback Handling.

1. Test Setup Cost: Initial test setup may appear costly. It is worth investing to avoid higher costs due to system crash or customer retention issues.

1. Defect Discovery Fallacy: Zero Defect assertion after testing is unrealistic. A critical awareness is: "We can't ensure the absence of all defects, but we work tirelessly to minimize these occurrences."

1. Static Analysis Pitfall: Automated scans and code reviews offer a wealth of data but doesn't replace dynamic testing that mimics and inspects live executions.

1. Elimination of Manual Testing: While Automated Testing is robust, the human intellect from exploratory tests gives an edge in uncovering unexpected anomalies.

1. Sprint or Time-Based Delimitation: Testing is viewed as an ongoing process, steadily integrated with Development, investing in every unit engineered.

Skillset Proficiency

1. Test-Driven Development (TDD): Composing tests even before building the code can steer a clear development path, magnifying code quality and reduction of bugs.

1. Agile and DevOps Synthesis: Seamless interaction among Development, Testing and Deployment is possible through such cohesive environments.

1. Domain Knowledge Fundamentals: Such expertise aids in meticulous scenario outlining and certification of systems.

Coverage testing involves evaluating the extent to which pieces of code are executed. This assessment helps in identifying areas of code that are not tested.

Key metrics for coverage include:

• Line coverage: The percentage of executable lines of code that are exercised by a test suite.

• Branch coverage: The percentage of decision points in the code where both possible outcomes have been tested at least once.

• Path coverage: This is the ideal scenario where every possible path through a program has been executed at least once. Achieving comprehensive path coverage can be impractical for larger programs.

• Statement coverage: The simplest type of coverage, evaluating if each statement in the program has been executed at least once during testing.

Unit Testing

• What is it? Focuses on testing separate functions and methods.
• When is it Done? At the time of coding.
• Level of Testing: Isolated.
• Role in Testing Pyramid: Forms Base.
• Tools: JUnit, NUnit, PyTest.
• Key Benefits: Early Error Detection.

Component Testing

• What is it? Tests software components, often defined at a high level.
• When is it Done? After unit testing and before integration testing.
• Level of Testing: Limited Context.
• Role in Testing Pyramid: Foundational.
• Key Benefits: Verifies that units of code work together as expected in defined scenarios.

Integration Testing

• What is it? Focuses on the combined units of the application.
• When is it Done? After component testing and before system testing.
• Level of Testing: Moderate Context.
• Role in Testing Pyramid: Focal.
• Tools: Apache JMeter, LoadRunner.
• Key Benefits: Identifies issues in interfaces between software modules.

System Testing

• What is it? Evaluates the complete and integrated system.
• When is it Done? After integration testing.
• Level of Testing: Comprehensive.
• Role in Testing Pyramid: Primary.
• Key Benefits: Validates system requirements against its delivered functionalities.

Acceptance Testing

• What is it? Validates if the system meets specified customer requirements.
• When is it Done? After system testing.
• Level of Testing: External.
• Role in Testing Pyramid: Apex.
• Key Benefits: Ensures the system is acceptable to end-users.

Alpha & Beta Testing

• When is it Done? After acceptance testing; often includes phases after the product launch.

Alpha Testing

• For What: Validates the system in a controlled, in-house environment.
• Role in Testing Pyramid: Initial User Feedback Provider.

Beta Testing

• For What: Verifies the system in a live, real-time environment, often receiving feedback from a select group of external users.
• Role in Testing Pyramid: Early User Feedback Provider.

Acceptance Testing (AT) examines whether a system meets its business-related objectives. This serves as the final validation step before the product is released to its end-users or customers.

Types of Acceptance Testing

1. Alpha Testing:
2. Scope: Performed by the in-house team before the product is made available to a few external customers.
3. Goal: Identifies any critical issues and refines features based on direct user feedback.
4. Common in: Software, gaming consoles, and application deployment in private organizations.

1. Beta Testing:
2. Scope: Executed by a select group of external users or customers.
3. Goal: Aims to uncover any final issues or glitches and understand user experience and acceptance.
4. Common in: Software, web applications, and broader consumer-targeted products.

1. Contract Acceptance Testing:
2. Scope: Typically occurs at the point of contractual agreement between two or more entities.
3. Goal: Guarantees the developed product, or service adheres to specified contract requirements.
4. Common in: Government projects, major client engagements, and legal agreements.

1. Regulation Acceptance Testing:
2. Scope: Required to ensure the product complies with specific industry or regional regulations.
3. Goal: Confirms the product satisfies set regulatory conditions or safety standards.
4. Common in: Industries like healthcare, finance, aviation, and pharmaceuticals.

1. User Acceptance Testing (UAT):
2. Scope: Carried out by stakeholders, often end-users or customer representatives.
3. Goal: Validates whether the system performs as per their given requirements and needs.
4. Common in: All industries, especially those with a strong focus on user needs and input.

1. Operational Testing:
2. Scope: Focuses on the operational aspects and the system's ability to perform tasks.
3. Goal: Validates the operational readiness of the system, often under real-world conditions.
4. Common in: Mission-critical systems, defense, emergency response, and large-scale industrial systems.

1. Regulation Acceptance Testing:
2. Scope: Ensures the product complies with industry or regional regulations.
3. Goal: Validates adherence to specific regulations or safety standards.
4. Common in: Sectors such as healthcare, finance, aviation, and pharmaceuticals.

Integration testing evaluates the combined functionality of software components to identify any interfacial issues and ensure that they work seamlessly together.

By testing groups of components as a unit, integration testing aims to:

• Identify defects in component interactions.
• Verify that messages/requests are passed correctly.
• Assess systems for correct resource allocation and management.

Types of Integration Testing

Top-Down Strategies

Advantages:

• Easier to identify and rectify architectural issues early on.
• Useful for monitoring the overall progress of the project.

Disadvantages:

• It may be complex to manage, especially in larger systems.

Top-Down Testing

Also known as "Big Bang Integration Testing," this strategy focuses on testing upper layers of the application first.

It involves:

1. Relying on stubs to simulate lower-level modules (these are temporary stand-ins for actual lower modules).
2. Successive integration of lower-level modules, systematically reducing the number of stubs.

Bottom-Up Testing

This strategy, known as "Incremental Integration Testing," follows the opposite approach, testing lower layers first:

1. Form initial test bases using modules from the bottom.
2. Use drivers as temporary surrogates for higher-level components.
3. Gradually integrate modules upwards.

Middle-Out Testing

The "Sandwich" or "Middleware" strategy integrates modules layer-by-layer, starting with the core and expanding outwards.

• Offers a balanced perspective.
• Ensures the core is robust first.

Hybrid Approaches

In reality, integration testing often employs several methodologies to achieve the most comprehensive coverage:

• Federated: Begins with vertical slices of the application, followed by vertical and horizontal integrations.
• Concentric: Works from the inside out or outside in, focusing on specific zones or areas of the application.

Code Example: Top-Down and Bottom-Up Testing

Here is the Java code:

// Top-Down Testing
public class SalesReportServiceTest {
    // Test dependency to CashierService
}

// Bottom-Up Testing
public class CashierServiceTest {
    // Test core functionality
}

System Testing ensures that an integrated system meets its design requirements.

It differs from other testing techniques such as unit testing, integration testing, and acceptance testing in focus, testing scope, and test environment.

System Testing vs. Unit Testing

Focus

• Unit Testing: Tests individual "units" or components in isolation.

• System Testing: Evaluates the entire system as a whole, the way it will be used in its actual environment.

Testing Scope

• Unit Testing: Narrow-scope test mode.
• Mock objects and stubs may be employed to isolate functionality for testing.
• Such testing is usually automated and performed by developers.

• System Testing: Broad-scope test mode.
• No components are isolated during testing.
• Typically, these tests are end-to-end, manual, and customer-oriented.

Test Environment

• Unit Testing: Relies on a controlled and simulated environment.
• System Testing: Uses a real-world environment.

System Testing vs. Integration Testing

Focus

• Integration Testing: Evaluates if the interaction and combined functionalities of system components are as expected.

• System Testing: Ensures the entire system behaves per the given requirements.

Testing Scope

• Integration Testing: Medium-scope test mode.
• Focuses on component interactions within the system more than broader system functions.

• System Testing: Broad-scope test mode.

Test Environment

• Integration Testing: Uses a partially controlled environment where components are integrated.

• System Testing: Conducted in an environment mirrorring real-world application use.

System Testing vs. Acceptance Testing

Focus

• Acceptance Testing: Usually refers to testing performed by stakeholders for system approval.

• System Testing: Primarily focuses on product quality assurance and compliance with specific requirements.

Testing Scope

• Acceptance Testing: Medium-scope test mode, often involving test cases created by business users.

• System Testing: Broad-scope test mode, ensuring comprehensive system behavior.

Regression testing is a specialized testing mechanism designed to ensure that recent code changes do not adversely impact the existing functionality of a system.

Core Goals

1. Stability Assurance: Verifying that modifications don't introduce new defects and issues.
2. Consistency Check: Ensuring unchanged features maintain their intended behavior.
3. Prevention of Software Degradation: Identifying areas where changes break established features.

Common Triggers for Regression Testing

• Defect Resolution: Upon fixing a bug, testing other areas to confirm no new faults emerged.
• Feature Enhancements: Implementing new functionality while certifying existing features continue to work unaltered.
• Code Refactoring: Maintaining previous functionality after making structural or architectural modifications.

Methods of Regression Testing

Complete

The exhaustive testing of all functionalities within an application. Although thorough, this method is time-consuming and often impractical for larger systems.

Selective

Targeting specific features or components known to interact with the newly modified code segments. This approach is more efficient but requires careful identification of relevant test scenarios.

Unit-Test-Driven Regression

Relies on the continuous and automated execution of unit tests. This ensures prompt detection of regressions during development, enabling quick rectification.

The selective approach is common in industry as complete testing is often infeasible or unnecessarily time-consuming.

Tools for Automation

Various tools are available for automating regression testing, including:

• Jenkins: A continuous integration server that can schedule and execute test jobs at specified time intervals.
• JUnit: A popular unit testing framework for Java, often used in conjunction with build tools like Maven.
• Selenium: A web application testing framework that can automate interactions with web browsers.
• GitLab CI/CD: GitLab's integrated continuous integration/continuous deployment system that allows for the automated execution of tests.

Let's define verification and validation in the context of software testing and distinguish between the two.

Core Distinctions

• Verification: Confirms that the software adheres to its specifications and requirements.
• It answers "Are we building the product right?"
• Examples: Code reviews, inspections, and walkthroughs.

• Validation: Ensures that the software meets the user's actual needs.
• It answers "Are we building the right product?"
• Examples: User acceptance testing, alpha and beta testing.

Static testing and dynamic testing complement each other to deliver comprehensive code verification. Whereas static testing focuses on examining software without executing it, dynamic testing verifies software in an operational environment. ### Core Focus

• Static Testing: Analyzes code or documentation to identify issues without executing the program.
• Dynamic Testing: Involves code execution to identify and evaluate program behavior.

Timing

• Static Testing: Typically conducted earlier in the development cycle, aiding in identifying issues at their root.
• Dynamic Testing: Typically performed later in the development cycle, after code integration, to assess system functionality and user interaction.

Tools and Techniques

Static Testing

• Manual Reviews: Human experts manually inspect code and documentation.
• Automated Tools: Software applications are used to analyze code or documentation for possible issues. Examples include code linters, IDE integrations, and spell-checkers for documentation.

Dynamic Testing

• Unit Testing: Evaluates the smallest units of code, such as individual functions or methods, in isolation.
• Integration Testing: Validates that modules or components work together as expected.
• System Testing: Assesses the complete, integrated software product to ensure it meets predefined requirements.
• Acceptance Testing: Determines if a system meets a set of business requirements and/or user expectations. It often involves end-users executing the system.

Code Coverage

• Static Testing: Offers some line coverage to ensure that all code is correct and complete, but does not guarantee execution.
• Dynamic Testing: Provides comprehensive execution, ensuring that code is run as intended under different scenarios.

Test Objectives

• Static Testing: Primarily aims to identify issues such as code violations, design errors, and documentation problems.
• Dynamic Testing: Seeks to validate system functionality and user interaction in a real or simulated environment.

Unit testing involves testing individual components or modules of a system to ensure they perform as expected. It's commonly done in the software development process, helping to identify and fix bugs early.

Core Principles

• Isolation: Each unit should be independent of the system, allowing verification in isolation.
• Repeatability: Tests must be consistent over multiple test runs.
• Speed: Running one test should be quick, enabling frequent runs.
• Consistency across Platforms: Tests should produce consistent results, irrespective of the platform.

Tools and Frameworks

• JUnit: For Java-based testing.
• NUnit: For .NET and C# developers.
• JUnit Jupiter API: The latest version of JUnit, designed using Java 8 features.
• TestNG: Java framework supporting multiple test levels.
• RSpec: A BDD-style testing tool for Ruby.
• Google Test: A test framework suitable for C++ projects.
• Mocha and Jasmine: For JavaScript developers.
• PyTest and Unittest: For Python testing.

Code Example: JUnit 5 for Java

Here is the Java code:

import static org.junit.jupiter.api.Assertions.assertEquals;
import static org.junit.jupiter.api.Assertions.assertTrue;
import org.junit.jupiter.api.Test;

class MathFunctionsTest {
    MathFunctions mathFunctions = new MathFunctions();

    @Test
    void testAdd() {
        assertEquals(4, mathFunctions.add(2, 2));
    }

    @Test
    void testIsPrime() {
        assertTrue(mathFunctions.isPrime(7));
    }
}

Tools for Automation

• Maven for Java: It's a build automation tool. Along with managing dependencies and building packages, it can run tests.
• Gradle for Java, Groovy, and Kotlin: It's a build tool providing a domain-specific language to configure project automation.
• JUnit Platform Launcher: A test execution engine used with build systems to run JUnit 5-based tests.
• Jenkins: Often used for Continous Integration/Continous Deployment (CI/CD), it can automate test executions.
• GitHub Actions: A CI/CD tool from GitHub focused on automating workflows, such as testing.

Assertions and Test Cases

• Assert: Provides methods to validate different conditions. For instance, assertEquals(expected, actual) checks if two values are equal.
• Test Cases: Methods beginning with @Test mark the testing methods.

Use of Annotations

• @BeforeAll and @AfterAll: Methods annotated with these are executed once, before and after all test methods, respectively.
• @BeforeEach and @AfterEach: Methods annotated with these run before and after each test method, ensuring a clean test environment.

Integration with Development Tools

• IDE Tools: Many modern integrated development environments, such as IntelliJ IDEA or Eclipse, support unit testing directly in the UI.
• Version Control Systems: Tools like Git can be integrated with unit testing for pre-commit and post-commit testing.
• Automated Build Systems: Build systems such as Jenkins and TeamCity can be configured to trigger automated testing.

Pitfalls to Avoid

• Inadequate Coverage: The tests might not fulfill all requirements, leading to undetected bugs.
• Over-Reliance on External Systems: External dependencies can fail, resulting in false positives.
• Tightly Coupled Tests: This may complicate code refactorings, as even unrelated changes can break tests.
• Testing Redundancies: Repeating test scenarios is inefficient and may lead to inconsistency.

Benefits of Unit Testing

• Early Bug Detection: Issues are identified early in development, reducing remediation costs.
• Improved Code Quality: Dividing code into small testable units promotes cleaner and more maintainable code.
• Refactoring Confidence: Allows for peace of mind when modifying existing code.
• Better Documentation: The test suite can serve as living documentation, outlining the behavior of units.

Although automated testing is generally advantageous, there are specific scenarios where manual testing is more appropriate. Such instances are typically characterized by high initial setup costs, limited test repetition needs, or the benefit of human intuition and adaptability.

When to Opt for Manual Testing

• Repetitive One-Time Scenarios: If a test case is complex and unlikely to be repeated, manual testing might be more efficient.

• Data Sensitivity: Cases involving sensitive data, especially in regulated industries, are often better suited for manual testing.

• Exploratory Testing: This method is more about discovering software behaviors organically rather than confirming predetermined ones. It's hard to automate by definition and often benefits from human insight.

• Localized Testing: Some scenarios, like minor changes or specific error resolution, can be more effectively checked through manual testing.

• Initial Test Automation Costs: For projects with small scopes or where setup costs for automated testing are relatively high, manual testing can offer a streamlined alternative.

Combined Approach: The Best of Both Worlds

Blended testing approaches are becoming increasingly popular in the industry. By combining the strengths of both manual and automated testing, teams can achieve comprehensive test coverage and rapid feedback.

• Ground-Up Automation Post-Manual Testing: This method lets testers understand the system, its domain, and the test needs before automating select areas.

• Automation-Assisted Exploratory: Using automated testing tools to guide and streamline exploratory testing can yield more comprehensive coverage.

• Risk-Based Testing with Tools: Prioritizing test cases based on risk and automating high-risk scenarios helps ensure critical functionalities are constantly tested.

Explore all 100 answers here 👉 Devinterview.io - Testing

The Software Development Life Cycle (SDLC) is comprised of several distinct phases that lay the foundation for a successful software project.

Key Phases

1. Requirement Analysis & Planning:
2. Stakeholder Consultation: Engaging with stakeholders to fully understand their needs and expectations, and to establish clear project objectives.
3. Testing Role: Requirement validation via techniques like Prototype Evaluation and Use Case Analysis.

1. Design & Architectural Planning:
2. Document Creation: This involves creating the Software Requirement Specification (SRS) and the High-Level Design document.
3. Testing Role: Design Reviews and Structural Testing ensure the project's design aligns with the defined requirements.

1. Implementation & Coding:
2. Core Functionality: The focus here is on writing code to cater to validated and approved requirements.
3. Unit Testing: Small, independent units of code are tested to confirm they meet their expected behaviors, ensuring reliable building blocks for the larger system.

1. System Testing: The integrated system is tested as a whole, to ensure all features work together cohesively.
2. Phase Segmentation: This is often divided into Alpha & Beta Testing before release.
3. Stress Testing: Conducting experiments in extreme conditions helps assess the system's limits.

1. Deployment & Maintenance:
2. Deployment Verification: Post-deployment tests are conducted to ensure that the system functions correctly in its live environment.
3. Regular Checks: Ongoing maintenance includes periodic checks and updates to keep the software optimized and secure.

Code Example: Unit Testing

Here is the Python code:

def add(a, b):
    return a + b

def subtract(a, b):
    return a - b

# Unit Tests
assert add(1, 2) == 3
assert subtract(5, 2) == 3

Code Example: Integration Testing

Here is the Python code:

def add_and_subtract(a, b):
    return add(a, b), subtract(a, b)

# Integration Test
result = add_and_subtract(5, 3)
assert result == (8, 2)