CH 2 Software testing

Software Development Life Cycle (SDLC)

A series of defined stages used to develop software from requirements through delivery.

Work Product

An intermediate deliverable required to create the final product, such as documentation or code.

Product

The final software system and associated documentation ready for release.

Waterfall Model

A linear/sequential SDLC where each phase is completed before the next begins.

Major drawback of Waterfall Model

Defects may not be discovered until late in development, making them expensive to fix.

Verification

Checking that a work product meets its specified requirements; building the product correctly.

Validation

Checking that the product meets user needs; building the right product.

V Model

A sequential SDLC that links each development phase with a corresponding testing phase.

Benefit of the V Model

Test planning begins early and every work product has a corresponding testing activity.

Requirement Specification

Captures user needs and requirements.

Functional Specification

Defines functions required to meet user needs.

Technical Specification

Provides technical design details for required functions.

Program Specification

Detailed design of modules or units to be coded.

Unit Testing in the V Model

Testing against the program specification.

Integration Testing in the V Model

Testing against the technical specification.

System Testing in the V Model

Testing against the functional specification.

System Integration Testing in the V Model

Testing against business processes.

Acceptance Testing in the V Model

Testing against the requirement specification.

Impact of V Model on Testing

Encourages early static testing but delays dynamic testing until later stages.

Iterative Development

Development where requirements evolve and software is built in repeated cycles.

Incremental Development

Development where functionality is delivered in small pieces over time.

Time-box

A fixed period during which work for an iteration is completed.

Key Advantage of Iterative Development

Users provide feedback throughout development, reducing risk of building the wrong product.

Test-Driven Development (TDD)

Writing functional tests before writing code.

Shift-Left Testing

Moving testing activities earlier in the development life cycle.

Traceability

The ability to link requirements, code, and tests throughout development.

Regression Testing Challenge in Iterative Development

Frequent changes require extensive retesting to ensure nothing breaks.

Agile

An umbrella term for iterative development methods emphasizing collaboration and adaptability.

Scrum

Agile framework using short iterations called sprints.

Sprint

A fixed-length iteration in Scrum.

Kanban

A visual workflow management approach using task boards.

Spiral Model

An iterative model driven by risk assessment.

Acceptance Test-Driven Development (ATDD)

Development driven by acceptance criteria defined by stakeholders.

Behavior-Driven Development (BDD)

Development based on expected behavior using Given-When-Then statements.

Domain-Driven Development (DDD)

Development using a common language shared by all stakeholders.

Feature-Driven Development (FDD)

Development focused on designing and building specific features.

Extreme Programming (XP)

Agile methodology emphasizing communication, feedback, and continuous integration.

Lean IT

Development approach focused on maximizing value and eliminating waste.

DevOps

Collaboration among development, operations, and testing with emphasis on automation and continuous delivery.

Benefits of DevOps for Testing

Faster feedback, continuous integration, stable environments, automation, and reduced regression risk.

Continuous Integration (CI)

Frequent merging and testing of code changes.

Benefits of Shift-Left Testing

Earlier defect detection, reduced costs, and faster feedback.

Retrospective

A meeting used to identify lessons learned and improve future processes.

Purpose of Retrospectives

Retain successful practices and improve weak areas.

Good Testing Practice

Test design should begin early in the SDLC.

Good Testing Practice

Every work product should be tested.

Good Testing Practice

Each test level should have specific objectives.

Good Testing Practice

Testers should review requirements early.

Test Level

A stage of testing with a specific focus and objectives.

Five Common Test Levels

Component, Integration, System, System Integration, Acceptance.

Test Basis

Information used to derive test cases.

Test Object

The item being tested.

Component Testing

Testing individual units or components in isolation.

Who Usually Performs Component Testing?

Developers.

Purpose of Component Testing

Verify functionality and structure of individual units.

Mock Objects

Simulated objects used during testing when actual components are unavailable.

Stub

A passive replacement for a lower-level component during testing.

Driver

An active replacement for a higher-level component during testing.

Integration Testing

Testing interactions and interfaces between integrated components or systems.

Purpose of Integration Testing

Detect interface and interaction defects.

Component Integration Testing

Testing interactions between integrated components.

System Integration Testing

Testing interactions between systems and external interfaces.

Big-Bang Integration

Integrating all components at once before testing.

Disadvantage of Big-Bang Integration

Defects are difficult to isolate and often discovered late.

Top-Down Integration

Testing starts with higher-level components and moves downward.

Top-Down Integration Uses

Stubs.

Bottom-Up Integration

Testing starts with lower-level components and moves upward.

Bottom-Up Integration Uses

Drivers.

System Testing

End-to-end testing of the complete system in a representative environment.

Who Typically Performs System Testing?

An independent testing team.

Functional Requirement

A requirement describing what the system must do.

Non-Functional Requirement

A requirement describing how the system performs.

Examples of Non-Functional Requirements

Performance, usability, reliability, security, portability, maintainability.

Acceptance Testing

Testing performed to determine whether the system satisfies user and business needs.

Purpose of Acceptance Testing

Provide confidence that the system meets expectations.

User Acceptance Testing (UAT)

Testing performed by user representatives to verify business needs are met.

Operational Acceptance Testing

Testing operational readiness including backups, maintenance, and recovery procedures.

Contractual Acceptance Testing

Testing against acceptance criteria defined in a contract.

Regulatory Acceptance Testing

Testing to ensure compliance with legal or industry standards.

Alpha Testing

Testing by external users at the developer's site before release.

Beta Testing

Testing by customers at their own sites before release.

Functional Testing

Testing specific functions and features of a system.

Other Names for Functional Testing

Black-box testing or specification-based testing.

Functional Testing Measurement

Percentage of requirements covered by tests.

Non-Functional Testing

Testing system characteristics such as performance, usability, and security.

ISO/IEC 25010

Standard that defines software quality characteristics for non-functional testing.

White Box Testing

Testing based on the internal structure of the system.

Common White Box Measures

Code coverage and interface coverage.

Confirmation Testing

Retesting to verify a defect has been fixed.

Retesting

Another name for confirmation testing.

Regression Testing

Testing unchanged areas to ensure changes have not introduced new defects.

Difference Between Confirmation and Regression Testing

Confirmation verifies a fix works; regression checks nothing else broke.

Debugging

The process of identifying and fixing defects.

Testing vs Debugging

Testing finds defects; debugging fixes them.

Maintenance Testing

Testing performed after a system has been released and modified.

Triggers for Maintenance Testing

Modifications, upgrades, migrations, retirement, and bug fixes.

Impact Analysis

Determining which parts of a system may be affected by a change.

Purpose of Impact Analysis

Reduce unnecessary regression testing and understand risks of changes.

Conversion Testing

Testing data transfer during system migration.

Importance of Traceability in Maintenance

Helps determine the impact of changes and required testing.