Testing Throughout the Software Development Lifecycle Flashcards

1
Q

What are the most used and popular software development life cycle models?

A
  • Sequential
    • Waterfall
    • V-model
    • W-model
  • Iterative
    • Spiral
    • Prototyping
  • Incremental
    • Unified Process
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What are some methods and agile practices?

A
  • Acceptance-test drive Development (ATDD)
  • Behavior-driven Development
  • Domain-driven Design
  • Extreme programming
  • Feature-driven Development (FDD)
  • Kanban
  • Lean IT
  • SCRUM
  • Test-driven Development (TDD)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Where SDLC impact on testing?

A
  • Scope and timing of Test Activities
  • Level of Detail of Test Documentation
  • Choice of Techniques and Test Approach
  • Extent of Test Automation
  • Role and responsabilities of a tester
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What is the difference between verification and validation?

A

Verification builds the product right. Validation builds the right product.

Software verification is about evaluating a work product, component or system to determine whether it meets the requirements set.
Is the product built according to the specification?

Software validation is about evaluating a work product, component or system to determine whether it meets the user needs and requirements.
Is the product fit for the purpose? Does it solve the problem?

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What are common tasks for Verification and Validation? There are tasks that belongs to both?

A

Verification:
- Unit Test
- Integration Test
Automated Testing

Validation
- Customer Acceptance Test
- Usability Test

Both:
- Regression testing
- System Test
- System Integration Test
- Beta Test

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is a key characteristic of the Waterfall model?

A

Each phase must be completed and signed off before the next phase begins.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Why is testing considered “late” in Waterfall?

A

Because dynamic testing typically starts after most or all coding is finished.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Name one advantage of the Waterfall model.

A

It’s easy to follow with clear documentation and defined milestones.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Why is Waterfall not ideal when frequent changes are expected?

A

Because changes require going back to earlier phases, which is costly and time-consuming.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

What does “V” stand for in V-Model?

A

It represents the Verification phases on the left, Coding at the bottom, and Validation phases on the right.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Why is the V-Model considered an improvement over Waterfall for testing?

A

Because testing activities (test design) start in parallel with each development phase, enabling early detection of defects.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Give one example of a corresponding test phase for System Requirements in the V-Model.

A

System Testing is planned and designed parallel to System Requirements gathering.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What is a drawback of the V-Model?

A

It can still be rigid—major changes late in development can be expensive to manage.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

How does the W-Model differ from the V-Model?

A

It emphasizes parallel test activities at each development step, creating two “tracks” that form a W shape rather than a single “V.”

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Name one advantage of the W-Model.

A

Very early, continuous test involvement, leading to faster feedback and defect detection.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is a common challenge when using the W-Model?

A

It can be complex to manage and requires significant testing resources.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Does the W-Model allow for incremental releases like Agile?

A

Not inherently. It’s still a sequential model, delivering the entire product at once.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

In sequential models, how is the system typically delivered?

A

All at once in a single release (not incrementally).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

Which model is known for having testing start parallel with development phases?

A

V-Model (Verification & Validation model).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

Name one reason the W-Model might be more effective than the V-Model.

A

It supports continuous parallel test activities at each development step, potentially finding issues even earlier.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

Why can changes be expensive in sequential models?

A

Because each phase is finalized before the next starts, so revisiting a phase (e.g., design) after coding has begun involves major rework.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

Which sequential model typically fits a small project with fixed requirements?

A

Waterfall—it’s straightforward if you don’t anticipate many changes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

In the V-Model, what test level corresponds to “Detailed Design”?

A

Unit/Component Test Design.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

How is “User Acceptance Testing” positioned in the V-Model?

A

It corresponds to the “User Requirements” definition phase on the opposite side of the V.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

If your team is short on testers, why might the W-Model be challenging?

A

Because it requires test activities at every step, demanding more test resources in parallel.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

How does the Incremental Model deliver software?

A

It delivers the software in small, functional increments, each providing part of the system’s functionality.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

Name one advantage of the Incremental Model over a purely sequential model.

A

It provides working software earlier, allowing for faster feedback.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

What is a key challenge in testing each increment?

A

Ensuring that new functionality integrates well with existing increments (regression testing).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

Is each increment fully tested before the next increment starts?

A

Ideally, yes. Each increment goes through requirements, design, coding, and testing cycles before integrating.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

How does the Iterative Model build software?

A

By revisiting and refining the software in multiple iterations, each iteration improving previous versions.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Give one benefit of the Iterative Model.

A

It allows progressive refinement, making it easier to accommodate changes.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

What’s a common risk with iterative development?

A

Potential for scope creep if the team continually adds features without a clear endpoint.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

How are testing activities handled in each iteration?

A

Each iteration includes designing tests for new or updated functionality and regression testing of previously built features.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

In what key way do incremental and iterative models differ from Waterfall?

A

They deliver or refine software in parts or in repeated cycles, rather than waiting for a single final release at the end.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

How does the Incremental Model handle changes mid-project?

A

Changes can be added in future increments without overhauling the entire codebase.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Why does the Iterative Model often produce an early “baseline” system?

A

So stakeholders can experience a working solution early, provide feedback, and allow the team to refine it in subsequent iterations.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Which model is best if you have stable architecture but can deliver features in stages?

A

Incremental Model—it’s ideal for adding well-defined slices of functionality.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

What is the primary risk of iterative development?

A

Scope creep—the project might keep evolving without a clear end if not carefully managed.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

In both models, why is testing generally easier to start earlier compared to Waterfall?

A

Because smaller chunks of functionality (increments or iterations) can be tested as they’re delivered/refined, rather than testing everything at the end.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

What is the primary measure of progress in Agile development?

A

Working software that meets user needs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Name one key Agile principle related to requirements.

A

“Welcome changing requirements,” even late in development.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Why is customer collaboration crucial in Agile?

A

Frequent feedback ensures the product aligns with real user needs.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Why is regression testing so important in Agile?

A

Because frequent changes are introduced each sprint, so previously working features could break.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

How do testers get involved early in Agile?

A

They review user stories, refine acceptance criteria, and plan tests before coding starts.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Which type of testing aligns well with Agile’s fast pace and frequent changes?

A

Exploratory Testing, supported by Automated Regression.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

How is delivery different in Agile vs. Waterfall?

A

Agile delivers in frequent increments/sprints, while Waterfall delivers a single final product at project end.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

In Waterfall, when does dynamic testing primarily occur?

A

After the coding phase, often late in the project.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Why is Agile often better for projects with uncertain or changing requirements?

A

Because Agile welcomes change and adapts the backlog iteratively.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

In V-Model, what is each activity and the corresponding test?

A

User Requirements -> Acceptance Tests
Sysm Requirements -> System Tests
Global Design -> Integration Tests
Detailed design -> Component Tests
Implementation

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

List 4 testing best practices.

A
  • For each developmet activity there is a correspoding testing activity
  • Each test level has test objectives specific to that level
  • Test analysis and design of tests for a given test level should begin during the correspoding development activity
  • Testers should be involved in reviewing documents as soon as drafts are available in the development cycle
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

In TDD, why do we write the test before the code?

A

It helps clarify the desired functionality, ensuring requirements are understood and preventing defects.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

Name the three TDD steps.

A

Red, Green, and Refactor.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Which level of testing does TDD focus on most?

A

Primarily unit testing, although it can also influence integration tests.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

How does ATDD differ from TDD?

A

ATDD focuses on acceptance criteria at higher test levels, bringing business stakeholders into the process.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

What is a common benefit of ATDD?

A

It ensures everyone (business, dev, test) shares the same understanding of “done” for each feature.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Can ATDD tests be used after development?

A

Yes, acceptance tests become part of regression testing suites.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

How does BDD differ from TDD?

A

BDD uses behavior-focused, natural language scenarios (Given-When-Then), while TDD focuses on unit-level tests in code syntax.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

Why do we say BDD fosters collaboration?

A

Because business, dev, and test jointly create human-readable scenarios, aligning everyone on the desired behavior.

59
Q

Which format is commonly used in BDD for scenarios?

A

Given-When-Then.

Scenario: A learning platform that checks course completion.

Requirement (Given/When/Then):
Given a student is enrolled in the Basic Testing course
When the student completes all lessons and quizzes
Then the student should have at least 65% correct answers overall

BDD Tools can convert this scenario into automated tests, ensuring the functionality is coded to produce the correct outcome.

60
Q

What is a primary goal of DevOps?

A

To deliver high-quality software more rapidly by bridging development, testing, and operations.

61
Q

What does “team autonomy” mean in DevOps?

A

The cross-functional DevOps team owns decisions on application development, testing, and environment setup, without separate siloed agendas.

62
Q

Which concept ensures that newly integrated code is tested immediately?

A

Continuous Integration (CI)—it merges code frequently and runs automated tests on every commit.

63
Q

Why is test automation crucial in DevOps?

A

Because frequent releases require fast, repetitive testing. Automation ensures quick feedback and reduces manual workload.

64
Q

Name one key benefit of adopting DevOps for testing.

A

Fast feedback loops on code quality (unit tests, coverage checks), reducing regression and late defect discovery.

65
Q

Mention a risk or challenge in DevOps testing.

A

Maintaining CI/CD pipelines and large test suites can be resource-heavy, requiring skilled personnel and budget.

66
Q

In a DevOps pipeline, which tests are typically the slowest to run?

A

UI (end-to-end) tests. They often require careful scheduling to avoid pipeline bottlenecks.

67
Q

How does “shift-left” help in a DevOps environment?

A

It prevents defects by writing tests and performing static analysis early in the coding process, catching errors sooner.

68
Q

What does “Shift Left” fundamentally mean in software testing?

A

Starting testing activities earlier in the SDLC rather than only at the end.

69
Q

Does Shift Left replace final-stage testing?

A

No. It adds early testing but does not eliminate or reduce later testing stages.

70
Q

Why should test cases be written before coding starts according to Left Approach?

A

It clarifies expected behavior for developers, prevents misunderstandings, and ensures tests are ready once code is committed.

71
Q

What is a “test harness”?

A

A collection of stubs, drivers, and scripts enabling partial test execution and automated reporting during development.

72
Q

How does Shift Left reduce costs in a project?

A

Early detection of defects is cheaper to fix and prevents costly rework later.

73
Q

Why do we say shift left also applies to non-functional testing?

A

Because usability, performance, etc., can be reviewed and tested as soon as relevant system parts (like wireframes or partial builds) are ready.

74
Q

What is one potential challenge of implementing Shift Left?

A

Upfront investment in testing, tooling, and stakeholder training, which may feel higher initially.

75
Q

What is the main purpose of Continuous Integration?

A

To frequently merge code changes, automate build and tests, and provide fast feedback on integration issues.

76
Q

How often should developers commit code to the main branch in a CI environment?

A

Typically at least once a day, but more frequent smaller commits are encouraged.

77
Q

Name three key steps in a typical CI pipeline.

A

(1) Static code analysis, (2) Build/Compile, (3) Automated tests (unit/integration), plus result reporting.

78
Q

Does CI remove the need for manual testing?

A

No. Manual testing (exploratory, usability, acceptance) remains crucial, especially at system-level checks.

79
Q

Why does CI help reduce “big bang” integration issues?

A

Because code is integrated and tested in small increments rather than waiting until the end of a sprint or project.

80
Q

What is a common challenge when implementing CI?

A

Maintenance of the pipeline and tests, which requires time, tools, and skilled resources.

81
Q

How do we handle slow or lengthy tests in CI?

A

Run critical/fast tests on each commit and schedule long-running tests (like full UI or performance tests) nightly or on a separate pipeline.

82
Q

What is the main purpose of having multiple test levels?

A

To address different scopes (component, integration, system, etc.) and uncover defects early and thoroughly at each stage.

83
Q

In which test level do we typically validate if the software meets actual user or business needs?

A

Acceptance Testing.

84
Q

How does component testing differ from component integration testing?

A

Component testing checks individual modules in isolation, whereas component integration ensures multiple modules communicate correctly.

85
Q

Why are component tests usually cheaper to execute than system tests?

A

Smaller scope, faster feedback, and easier automation at the code level.

86
Q

What is the focus of system integration testing?

A

Ensuring interactions between different systems or subsystems (e.g., external APIs, microservices) work correctly.

87
Q

Who typically performs system testing in many organizations?

A

A dedicated QA or independent test team, though in Agile it may be a cross-functional team effort.

88
Q

Who are the primary stakeholders in acceptance testing?

A

Often end users, customer representatives, or product owners—they validate the system against business or user requirements.

89
Q

Does acceptance testing focus only on functionality?

A

No. It may also address non-functional aspects like usability, performance, or compliance.

90
Q

What is another term for component testing?

A

Unit testing or module testing.

91
Q

Why are stubs and drivers used in component testing?

A

To simulate missing interfaces so the component can be tested in isolation.

92
Q

What is the main purpose of component integration testing?

A

To validate that integrated components communicate correctly, catching interface-level defects early.

93
Q

Which stage typically precedes component integration testing?

A

Component (unit) testing, ensuring each module works in isolation before checking their interactions.

94
Q

Which test objects are covered in component integration testing?

A

Pairs or small groups of modules that directly exchange data.

95
Q

How do testers handle missing modules or services during integration testing?

A

They use stubs or mocks to simulate those unavailable parts.

96
Q

Give one example of a typical defect found at component integration level.

A

Parameter mismatch (e.g., the caller sends (float, string), but the callee expects (int, string)).

97
Q

If a module indicates an error status but the caller doesn’t handle it, which type of defect is that?

A

Incorrect handling of return values—a common interface mismatch defect.

98
Q

Who usually performs component integration testing?

A

Developers or integration-focused testers (sometimes SDETs) who understand the technical interfaces between components.

99
Q

Do we use a separate test environment for component integration testing?

A

Often yes—an environment or harness that allows partial integration, stubs for missing parts, and easy debugging.

100
Q

What does system testing validate?

A

The entire integrated system, checking both functional and non-functional requirements.

101
Q

When does system testing typically occur?

A

After component and component integration tests are done, ensuring individual parts already work.

102
Q

Which testing technique is common in system testing?

A

Black-box methods (e.g., equivalence partitioning, boundary value analysis), focusing on requirements rather than internal code structure.

103
Q

Who usually conducts system testing?

A

A QA/test team (could be independent or part of the dev team in Agile), aiming for an unbiased approach.

104
Q

Name one common system-level defect.

A

Missing functionality that was specified but never implemented, or incomplete implementations leading to unexpected behavior.

105
Q

Why is performance testing often included in system testing?

A

Because you need the entire system running to accurately measure performance under real-world load conditions.

106
Q

How does system testing reduce project risk?

A

It identifies critical end-to-end failures before deployment, preventing severe production issues.

107
Q

Does system testing replace integration or acceptance testing?

A

No. Each level has its own scope and objectives. System testing ensures the software works as a whole, but acceptance focuses on business/user needs.

108
Q

What is the focus of system integration testing?

A

Ensuring multiple complete systems (or subsystems) function together correctly, focusing on interfaces and data exchange.

109
Q

Which test level typically precedes system integration testing?

A

System testing on each individual system, ensuring each system is stable before integration testing.

110
Q

What are common “test basis” sources for system integration testing?

A

Interface specs, architecture diagrams, SLAs, security or network requirements.

111
Q

If a real external system is unavailable, how can you still proceed with integration testing?

A

Use mocks or stubs to simulate that external system’s API or behavior.

112
Q

Name a typical interface mismatch issue in system integration testing.

A

One system sends data as XML, while the receiver expects JSON—leading to parsing errors.

113
Q

How do timing/sequence issues manifest in system integration testing?

A

Asynchronous calls might not align with a system expecting synchronous responses, causing timeouts or missed events.

114
Q

Who usually manages system integration testing?

A

A cross-team or integration test team, often collaborating with multiple dev teams.

115
Q

Does system integration testing replace end-to-end business process testing?

A

No. SIT focuses on technical interactions between systems. End-to-end tests might be part of a broader acceptance or operational readiness test.

116
Q

What is the primary goal of acceptance testing?

A

To confirm the product meets business/user needs and is ready for deployment.

117
Q

Who typically performs user acceptance testing?

A

End-users, customer reps, or product owners with domain knowledge.

118
Q

What is alpha testing vs. beta testing?

A

Alpha is typically in-house or closed-group testing, while beta is a wider release to a larger user group for real-world feedback.

119
Q

When does operational acceptance testing occur?

A

Usually right before go-live, checking operational aspects like backups, deployment scripts, and environment readiness.

120
Q

Name a typical acceptance-level defect.

A

Missing or misunderstood business requirements discovered by real users.

121
Q

Why might performance be tested again at acceptance testing?

A

Because realistic usage or final environment constraints can highlight performance issues not fully seen in earlier tests.

122
Q

Does acceptance testing replace earlier test levels (like system testing)?

A

No. Acceptance testing focuses on user/business validation, whereas system testing ensures technical correctness.

123
Q

What is the final result if acceptance testing passes?

A

The product is declared ready for deployment or go-live.

124
Q

What differentiates test levels from test types?

A

Levels (component, system, etc.) focus on where or scope of testing, while types (functional, non-functional, etc.) focus on what aspects or objectives are being tested.

125
Q

Why separate functional from non-functional tests?

A

They measure different attributes. Functional verifies features; non-functional verifies quality attributes (performance, security, etc.).

126
Q

Give an example of a non-functional test.

A

Load testing to measure response times under heavy user load.

127
Q

What is the main goal of structural (white-box) testing?

A

To assess internal code or architectural structures, ensuring enough coverage of code paths or branches.

128
Q

What is regression testing?

A

Re-running tests to confirm existing functionality still works after changes.

129
Q

Why do we do re-testing (confirmation testing)?

A

To verify that a specific defect is truly fixed using the same scenario that initially revealed it.

130
Q

Is it enough to rely solely on functional tests?

A

No. Non-functional, structural, and change-related types are also needed to ensure complete quality coverage.

130
Q

What are the four types o tests?

A
  1. Functional Testing
    Checks features and behaviors against functional requirements.
    Example: Validating login, cart checkout, or data processing steps.
    Techniques: Black-box methods (equivalence partitioning, boundary value analysis).
  2. Non-Functional Testing
    Evaluates quality attributes such as performance, security, usability, reliability, and so on.
    Example: A performance test to measure response times under load, or usability testing for user-friendliness.
    Often requires specialized tools or environments (e.g., load testing frameworks, security scanning software).
  3. Structural (White-Box) Testing
    Focuses on internal code or architecture (e.g., coverage of branches, statements, or paths).
    Example: Checking code coverage to ensure each line or branch is executed at least once.
    Typically done by developers, SDETs, or specialized testers comfortable with the code.
  4. Change-Related Testing
    Regression Testing: Ensures existing functionality still works after changes.
    Re-Testing (Confirmation Testing): Verifies that specific defects are fixed by retesting the same scenario.
    Example: After a bug fix, testers re-run the test that previously failed (re-testing), plus additional regression tests to confirm no side effects.
131
Q

What is the main purpose of confirmation (re-)testing?

A

To ensure a specific defect has indeed been fixed, by re-running the same scenario that revealed the bug.

132
Q

Why do we do regression testing after bug fixes?

A

To ensure unchanged functionality isn’t broken by the fix or changes in the code.

133
Q

Do we always run the entire regression suite for every fix?

A

Not necessarily. Teams often run a partial or targeted regression if the scope of change is small—but some environments demand a full suite for major changes.

134
Q

Should confirmation tests be automated?

A

If possible, yes—especially if the original test was automated. But some bug scenarios require manual steps or specialized checks.

135
Q

What if the confirmation test passes, but regression tests fail?

A

It means the bug is fixed, but the fix introduced a new bug or side effect. The fix might need rework.

136
Q

Is re-testing the same as regression testing?

A

No. Re-testing is for the specific defect scenario; regression covers broader areas of functionality.

137
Q

What is the main purpose of maintenance testing?

A

To ensure stability and quality of a live system after changes, fixes, or upgrades are introduced.

138
Q

Name two main maintenance testing activities after a defect fix.

A

Confirmation (re-testing) for the defect scenario and regression testing to check other areas for side effects.

139
Q

What are some triggers for maintenance testing besides bug fixes?

A

Enhancements, environment upgrades, migrations, security patches, or retirement of modules.

140
Q

In which environment is maintenance testing typically done?

A

A staging or pre-production environment that closely mirrors live production settings.

141
Q

What if the system is large and changes are frequent?

A

Automated regression testing is crucial, plus well-planned impact analysis to avoid testing everything unnecessarily each time.

142
Q

How do we handle a module’s decommission in maintenance testing?

A

Test flows that previously depended on that module, ensuring no broken references, data integrity issues, or other side effects.