Testing Throughout the Software Development Lifecycle Flashcards
(144 cards)
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
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)
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
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?
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
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.
7
Q
Why is testing considered “late” in Waterfall?
A
Because dynamic testing typically starts after most or all coding is finished.
8
Q
Name one advantage of the Waterfall model.
A
It’s easy to follow with clear documentation and defined milestones.
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.
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.
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.
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.
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.
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.”
15
Q
Name one advantage of the W-Model.
A
Very early, continuous test involvement, leading to faster feedback and defect detection.
16
Q
What is a common challenge when using the W-Model?
A
It can be complex to manage and requires significant testing resources.
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.
18
Q
In sequential models, how is the system typically delivered?
A
All at once in a single release (not incrementally).
19
Q
Which model is known for having testing start parallel with development phases?
A
V-Model (Verification & Validation model).
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.
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.
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.
23
Q
In the V-Model, what test level corresponds to “Detailed Design”?
A
Unit/Component Test Design.
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.
25
If your team is short on testers, why might the W-Model be challenging?
Because it requires test activities at every step, demanding more test resources in parallel.
26
How does the Incremental Model deliver software?
It delivers the software in small, functional increments, each providing part of the system’s functionality.
27
Name one advantage of the Incremental Model over a purely sequential model.
It provides working software earlier, allowing for faster feedback.
28
What is a key challenge in testing each increment?
Ensuring that new functionality integrates well with existing increments (regression testing).
29
Is each increment fully tested before the next increment starts?
Ideally, yes. Each increment goes through requirements, design, coding, and testing cycles before integrating.
30
How does the Iterative Model build software?
By revisiting and refining the software in multiple iterations, each iteration improving previous versions.
31
Give one benefit of the Iterative Model.
It allows progressive refinement, making it easier to accommodate changes.
32
What’s a common risk with iterative development?
Potential for scope creep if the team continually adds features without a clear endpoint.
33
How are testing activities handled in each iteration?
Each iteration includes designing tests for new or updated functionality and regression testing of previously built features.
34
In what key way do incremental and iterative models differ from Waterfall?
They deliver or refine software in parts or in repeated cycles, rather than waiting for a single final release at the end.
35
How does the Incremental Model handle changes mid-project?
Changes can be added in future increments without overhauling the entire codebase.
36
Why does the Iterative Model often produce an early “baseline” system?
So stakeholders can experience a working solution early, provide feedback, and allow the team to refine it in subsequent iterations.
37
Which model is best if you have stable architecture but can deliver features in stages?
Incremental Model—it’s ideal for adding well-defined slices of functionality.
38
What is the primary risk of iterative development?
Scope creep—the project might keep evolving without a clear end if not carefully managed.
39
In both models, why is testing generally easier to start earlier compared to Waterfall?
Because smaller chunks of functionality (increments or iterations) can be tested as they’re delivered/refined, rather than testing everything at the end.
40
What is the primary measure of progress in Agile development?
Working software that meets user needs.
41
Name one key Agile principle related to requirements.
“Welcome changing requirements,” even late in development.
42
Why is customer collaboration crucial in Agile?
Frequent feedback ensures the product aligns with real user needs.
43
Why is regression testing so important in Agile?
Because frequent changes are introduced each sprint, so previously working features could break.
44
How do testers get involved early in Agile?
They review user stories, refine acceptance criteria, and plan tests before coding starts.
45
Which type of testing aligns well with Agile’s fast pace and frequent changes?
Exploratory Testing, supported by Automated Regression.
46
How is delivery different in Agile vs. Waterfall?
Agile delivers in frequent increments/sprints, while Waterfall delivers a single final product at project end.
47
In Waterfall, when does dynamic testing primarily occur?
After the coding phase, often late in the project.
48
Why is Agile often better for projects with uncertain or changing requirements?
Because Agile welcomes change and adapts the backlog iteratively.
49
In V-Model, what is each activity and the corresponding test?
User Requirements -> Acceptance Tests
Sysm Requirements -> System Tests
Global Design -> Integration Tests
Detailed design -> Component Tests
Implementation
50
List 4 testing best practices.
- 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
51
In TDD, why do we write the test before the code?
It helps clarify the desired functionality, ensuring requirements are understood and preventing defects.
52
Name the three TDD steps.
Red, Green, and Refactor.
53
Which level of testing does TDD focus on most?
Primarily unit testing, although it can also influence integration tests.
54
How does ATDD differ from TDD?
ATDD focuses on acceptance criteria at higher test levels, bringing business stakeholders into the process.
55
What is a common benefit of ATDD?
It ensures everyone (business, dev, test) shares the same understanding of “done” for each feature.
56
Can ATDD tests be used after development?
Yes, acceptance tests become part of regression testing suites.
57
How does BDD differ from TDD?
BDD uses behavior-focused, natural language scenarios (Given-When-Then), while TDD focuses on unit-level tests in code syntax.
58
Why do we say BDD fosters collaboration?
Because business, dev, and test jointly create human-readable scenarios, aligning everyone on the desired behavior.
59
Which format is commonly used in BDD for scenarios?
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
What is a primary goal of DevOps?
To deliver high-quality software more rapidly by bridging development, testing, and operations.
61
What does “team autonomy” mean in DevOps?
The cross-functional DevOps team owns decisions on application development, testing, and environment setup, without separate siloed agendas.
62
Which concept ensures that newly integrated code is tested immediately?
Continuous Integration (CI)—it merges code frequently and runs automated tests on every commit.
63
Why is test automation crucial in DevOps?
Because frequent releases require fast, repetitive testing. Automation ensures quick feedback and reduces manual workload.
64
Name one key benefit of adopting DevOps for testing.
Fast feedback loops on code quality (unit tests, coverage checks), reducing regression and late defect discovery.
65
Mention a risk or challenge in DevOps testing.
Maintaining CI/CD pipelines and large test suites can be resource-heavy, requiring skilled personnel and budget.
66
In a DevOps pipeline, which tests are typically the slowest to run?
UI (end-to-end) tests. They often require careful scheduling to avoid pipeline bottlenecks.
67
How does “shift-left” help in a DevOps environment?
It prevents defects by writing tests and performing static analysis early in the coding process, catching errors sooner.
68
What does “Shift Left” fundamentally mean in software testing?
Starting testing activities earlier in the SDLC rather than only at the end.
69
Does Shift Left replace final-stage testing?
No. It adds early testing but does not eliminate or reduce later testing stages.
70
Why should test cases be written before coding starts according to Left Approach?
It clarifies expected behavior for developers, prevents misunderstandings, and ensures tests are ready once code is committed.
71
What is a “test harness”?
A collection of stubs, drivers, and scripts enabling partial test execution and automated reporting during development.
72
How does Shift Left reduce costs in a project?
Early detection of defects is cheaper to fix and prevents costly rework later.
73
Why do we say shift left also applies to non-functional testing?
Because usability, performance, etc., can be reviewed and tested as soon as relevant system parts (like wireframes or partial builds) are ready.
74
What is one potential challenge of implementing Shift Left?
Upfront investment in testing, tooling, and stakeholder training, which may feel higher initially.
75
What is the main purpose of Continuous Integration?
To frequently merge code changes, automate build and tests, and provide fast feedback on integration issues.
76
How often should developers commit code to the main branch in a CI environment?
Typically at least once a day, but more frequent smaller commits are encouraged.
77
Name three key steps in a typical CI pipeline.
(1) Static code analysis, (2) Build/Compile, (3) Automated tests (unit/integration), plus result reporting.
78
Does CI remove the need for manual testing?
No. Manual testing (exploratory, usability, acceptance) remains crucial, especially at system-level checks.
79
Why does CI help reduce “big bang” integration issues?
Because code is integrated and tested in small increments rather than waiting until the end of a sprint or project.
80
What is a common challenge when implementing CI?
Maintenance of the pipeline and tests, which requires time, tools, and skilled resources.
81
How do we handle slow or lengthy tests in CI?
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
What is the main purpose of having multiple test levels?
To address different scopes (component, integration, system, etc.) and uncover defects early and thoroughly at each stage.
83
In which test level do we typically validate if the software meets actual user or business needs?
Acceptance Testing.
84
How does component testing differ from component integration testing?
Component testing checks individual modules in isolation, whereas component integration ensures multiple modules communicate correctly.
85
Why are component tests usually cheaper to execute than system tests?
Smaller scope, faster feedback, and easier automation at the code level.
86
What is the focus of system integration testing?
Ensuring interactions between different systems or subsystems (e.g., external APIs, microservices) work correctly.
87
Who typically performs system testing in many organizations?
A dedicated QA or independent test team, though in Agile it may be a cross-functional team effort.
88
Who are the primary stakeholders in acceptance testing?
Often end users, customer representatives, or product owners—they validate the system against business or user requirements.
89
Does acceptance testing focus only on functionality?
No. It may also address non-functional aspects like usability, performance, or compliance.
90
What is another term for component testing?
Unit testing or module testing.
91
Why are stubs and drivers used in component testing?
To simulate missing interfaces so the component can be tested in isolation.
92
What is the main purpose of component integration testing?
To validate that integrated components communicate correctly, catching interface-level defects early.
93
Which stage typically precedes component integration testing?
Component (unit) testing, ensuring each module works in isolation before checking their interactions.
94
Which test objects are covered in component integration testing?
Pairs or small groups of modules that directly exchange data.
95
How do testers handle missing modules or services during integration testing?
They use stubs or mocks to simulate those unavailable parts.
96
Give one example of a typical defect found at component integration level.
Parameter mismatch (e.g., the caller sends (float, string), but the callee expects (int, string)).
97
If a module indicates an error status but the caller doesn’t handle it, which type of defect is that?
Incorrect handling of return values—a common interface mismatch defect.
98
Who usually performs component integration testing?
Developers or integration-focused testers (sometimes SDETs) who understand the technical interfaces between components.
99
Do we use a separate test environment for component integration testing?
Often yes—an environment or harness that allows partial integration, stubs for missing parts, and easy debugging.
100
What does system testing validate?
The entire integrated system, checking both functional and non-functional requirements.
101
When does system testing typically occur?
After component and component integration tests are done, ensuring individual parts already work.
102
Which testing technique is common in system testing?
Black-box methods (e.g., equivalence partitioning, boundary value analysis), focusing on requirements rather than internal code structure.
103
Who usually conducts system testing?
A QA/test team (could be independent or part of the dev team in Agile), aiming for an unbiased approach.
104
Name one common system-level defect.
Missing functionality that was specified but never implemented, or incomplete implementations leading to unexpected behavior.
105
Why is performance testing often included in system testing?
Because you need the entire system running to accurately measure performance under real-world load conditions.
106
How does system testing reduce project risk?
It identifies critical end-to-end failures before deployment, preventing severe production issues.
107
Does system testing replace integration or acceptance testing?
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
What is the focus of system integration testing?
Ensuring multiple complete systems (or subsystems) function together correctly, focusing on interfaces and data exchange.
109
Which test level typically precedes system integration testing?
System testing on each individual system, ensuring each system is stable before integration testing.
110
What are common “test basis” sources for system integration testing?
Interface specs, architecture diagrams, SLAs, security or network requirements.
111
If a real external system is unavailable, how can you still proceed with integration testing?
Use mocks or stubs to simulate that external system’s API or behavior.
112
Name a typical interface mismatch issue in system integration testing.
One system sends data as XML, while the receiver expects JSON—leading to parsing errors.
113
How do timing/sequence issues manifest in system integration testing?
Asynchronous calls might not align with a system expecting synchronous responses, causing timeouts or missed events.
114
Who usually manages system integration testing?
A cross-team or integration test team, often collaborating with multiple dev teams.
115
Does system integration testing replace end-to-end business process testing?
No. SIT focuses on technical interactions between systems. End-to-end tests might be part of a broader acceptance or operational readiness test.
116
What is the primary goal of acceptance testing?
To confirm the product meets business/user needs and is ready for deployment.
117
Who typically performs user acceptance testing?
End-users, customer reps, or product owners with domain knowledge.
118
What is alpha testing vs. beta testing?
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
When does operational acceptance testing occur?
Usually right before go-live, checking operational aspects like backups, deployment scripts, and environment readiness.
120
Name a typical acceptance-level defect.
Missing or misunderstood business requirements discovered by real users.
121
Why might performance be tested again at acceptance testing?
Because realistic usage or final environment constraints can highlight performance issues not fully seen in earlier tests.
122
Does acceptance testing replace earlier test levels (like system testing)?
No. Acceptance testing focuses on user/business validation, whereas system testing ensures technical correctness.
123
What is the final result if acceptance testing passes?
The product is declared ready for deployment or go-live.
124
What differentiates test levels from test types?
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
Why separate functional from non-functional tests?
They measure different attributes. Functional verifies features; non-functional verifies quality attributes (performance, security, etc.).
126
Give an example of a non-functional test.
Load testing to measure response times under heavy user load.
127
What is the main goal of structural (white-box) testing?
To assess internal code or architectural structures, ensuring enough coverage of code paths or branches.
128
What is regression testing?
Re-running tests to confirm existing functionality still works after changes.
129
Why do we do re-testing (confirmation testing)?
To verify that a specific defect is truly fixed using the same scenario that initially revealed it.
130
Is it enough to rely solely on functional tests?
No. Non-functional, structural, and change-related types are also needed to ensure complete quality coverage.
130
What are the four types o tests?
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
What is the main purpose of confirmation (re-)testing?
To ensure a specific defect has indeed been fixed, by re-running the same scenario that revealed the bug.
132
Why do we do regression testing after bug fixes?
To ensure unchanged functionality isn’t broken by the fix or changes in the code.
133
Do we always run the entire regression suite for every fix?
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
Should confirmation tests be automated?
If possible, yes—especially if the original test was automated. But some bug scenarios require manual steps or specialized checks.
135
What if the confirmation test passes, but regression tests fail?
It means the bug is fixed, but the fix introduced a new bug or side effect. The fix might need rework.
136
Is re-testing the same as regression testing?
No. Re-testing is for the specific defect scenario; regression covers broader areas of functionality.
137
What is the main purpose of maintenance testing?
To ensure stability and quality of a live system after changes, fixes, or upgrades are introduced.
138
Name two main maintenance testing activities after a defect fix.
Confirmation (re-testing) for the defect scenario and regression testing to check other areas for side effects.
139
What are some triggers for maintenance testing besides bug fixes?
Enhancements, environment upgrades, migrations, security patches, or retirement of modules.
140
In which environment is maintenance testing typically done?
A staging or pre-production environment that closely mirrors live production settings.
141
What if the system is large and changes are frequent?
Automated regression testing is crucial, plus well-planned impact analysis to avoid testing everything unnecessarily each time.
142
How do we handle a module’s decommission in maintenance testing?
Test flows that previously depended on that module, ensuring no broken references, data integrity issues, or other side effects.
143
