Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

ISTQB Study Cards > Chapter 2 SDLC Testing > Flashcards

Chapter 2 SDLC Testing Flashcards

1
Q

Acceptance Testing

A

Formal testing with respect to user needs, requirements, and business processes conducted to determine whether or not a system satisfies the criteria and to enable the user, customers, or other authorized entity to determine whether to approve the system

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

Alpha Testing

A

Simulated or actual operational testing conducted in the developer’s test environment, by roles outside the development organization

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

Beta Testing

A

Simulated or actual operational testing conducted at an external site, by roles outside the development organization.

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

Commercial off-the-shelf (COTS)

A

A software product that is developed for the general market, i.e. for a large number of customers, ad that is delivered to many customers in identical format.

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

Component Integration Testing

A

Testing performed to expose defects in the interfaces and interactions between integrated components.
Focus - component interfaces
Generally automated
Performed after component testing

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

Component testing

A

The testing of individual hardware or software components.
Often done in isolation for the rest of the system, may require mock objects, service virtualization, harnesses, stubs, and drivers.
May cover functional, non functional, structural testing.

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

Confirmation Testing

A

Dynamic testing conducted after fixing defects with the objective to confirm that failures caused by those defects do not occur anymore

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

Contractual acceptance testing

A

Acceptance testing conducted to verify whether a system satisfies its contractual requirements

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

Functional testing

A

Testing conducted to evaluate the compliance of a component or system with functional requirements

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

Impact analysis

A

The identification of all work products affected by a change, including an estimate of the resources needed to accomplish the change

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

Integration testing

A

Testing performed to expose defects in the interfaces and in the interactions between integrated components or systems

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

Maintenance testing

A

Testing the changes to an operational system or the impact of a changed environment to an operational system

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

Non-functional testing

A

Testing conducted to evaluate the compliance of a component or system with non-functional requirements

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

Operational acceptance testing

A

Operational testing in the acceptance test phase, typically performed in a (simulated) operational environment by operations and/or systems administration staff focusing on operational aspects, e.g., recoverability, resource-behavior, installability, and technical compliance

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

Regression testing

A

Testing of a previously tested component or system following modification to ensure that defects have not been introduced or have been uncovered in unchanged areas of the software, as a result of the changes made.

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

Regulatory acceptance testing

A

Acceptance testing conducted to verify whether a system conforms to relevant laws, policies, and regulations.

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

Sequential development model

A

A type of development lifecycle model in which a complete system is developed in a linear way of several discrete and successive phases with no overlap between them

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

System integration testing

A

Testing the combination and interaction of systems
Focuses on the interactions and interfaces between systems, packages and microservices.
Cover external organizations (web services)

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

System testing

A

Testing an integrated system to verify it meets the specified requirements

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

Test basis

A

The body of knowledge used as the basis for test analysis and design

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

Test case

A

A set of preconditions, inputs, actions, expected results, and postconditions, developed based on test conditions.

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

Test environment

A

An environment containing hardware, instrumentation, simulators, software tools, and other support elements needed to conduct a test

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

Test level

A

A specific instantiation of a test process

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

Test object

A

The component or system to be tested

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Test objective
A reason or purpose for designing and executing a test
26
Test type
A group of test activities based on specific test objectives aimed at specific characteristics of a component or system
27
User acceptance testing
Acceptance testing conducted in a real or simulated operational environment by intended users focusing their needs, requirements and business processes.
28
Usability testing
Testing to evaluate the degree to which the system can be used by specified users with effectiveness, efficiency and satisfaction in a specified context of use.
29
V-model
A sequential development lifecycle model describing a one for one relationship between major phases of software development from business requirements specification to delivery, and corresponding test levels from acceptance testing to component testing
30
Validation
Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.
31
Verification
Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.
32
White Box Testing
Testing based on an analysis of the internal structure of the component or system.
33
Development Lifecycles
Sequential (Waterfall) Incremental Iterative
34
Test Levels
``` Component Integration - Component / System System Acceptance UAT Operational Contractual Regulatory Alpha Beta ```
35
Test Types
``` Functional Non Functional Performance, Usability, Security Structural (whitebox) Effects of Changes Confirmation Regression Maintenance (Mods, Migration, Retirement) ```
36
Good Testing Characteristics
For every development Activity there is a testing Activity For each test level test objectives are defined Test design and analysis should begin during corresponding development activity at all test levels Testers should review work products as soon as drafts are available
37
Sequential Development Types
Waterfall | V Model
38
Incremental Development
Requirements, designing, building and testing a system in pieces. Software feature set grows incrementally.
39
Iterative Development
``` Feature groups specified, designed, built, tested in a series of cycles of fixed duration. RUP sCRUM/aGILE Kanban Spiral ```
40
Sequential Development Model
A type of development life cycle model in which a complete system is developed in a linear way of several discrete and successive phases with no overlap between them
41
V-model levels
Development - Testing 1. User Requirements - Acceptance Testing 2. System / Software Requirements - System Testing 3. Architecture/Design - Integration Testing 4. Detailed Design - Component Testing
42
Key Elements of a Testing Level
``` Specific objectives Test Basis Test Object Typical Defects / Failures Specific approaches and responsibilities Suitable Test Environment ```
43
Test Environment
``` A collection of Hardware System Software Application software Documentation People Interfaces Data ```
44
Driver
A software component or test tool that replaces a component that takes care of the control and/or the calling of a component or system
45
Stub
A skeletal or special-purpose implementation of a software component, used to develop or test a component that calls or is otherwise dependent on it. It replaces a called component.
46
Test objectives
Reduce Risk Verify Functional, non Functional behaviors Build confidence in quality Find Defects Prevent defect escapes to higher levels of tests
47
Component Test Basis
Detailed Design Code Data Model Component specifications (api, inputs, outputs)
48
Component Test Objects
Components, units, or modules Code and Data Structures Classes Database modules
49
Component Defects and Failures
Incorrect functionality Data flow problems Incorrect logic and code
50
Component Testing Approach
Done by Developer | Can be Test Driven
51
Integration Test Basis
Software and System Design Sequence Diagrams Interface and communication protocol specifications Use Cases Architecture at component or system level Workflows External interface definitions
52
Integration Test Objects
``` Subsystems Databases Infrastructure Interfaces Api's Microservices ```
53
Integration Defects and Failures
``` Incorrect/missing data or encoding Incorrect sequencing/timing of calls Interface mismatch Communication failres Unhandled communication failures Incorrect assumptions/disagreement of the meaning, units or boundaries of the data being passed Inconsistent message structures ```
54
Integration Testing Approaches
Concentrate on testing the integration in functional, non functional, structural capabilites Component Integration - Developers System Integration - Testers Plan Integration Tests before development
55
System Testing Objectives
``` Focus on whole system End to end tasks Non Functional Behaviros Validate system is complete Data complete/meet regulations ```
56
System Test Basis
``` System and Software requirements Risk analysis reports Use cases Epics / Features /User Stories Models State diagrams Manuals ```
57
System Test Objects
``` Applications Hardware Software systems Operating systems System under test System configuration ```
58
System Test Defects and Failures
``` Incorrect calculations Functional / Non Functional behavior Flow Control Data Flows End to End functionality Production failures ```
59
System Testing Approaches
End to End Functional and Non Functional Independent Testers Early involvement
60
Acceptance Testing Objectives
Establish confidence in Quality Validate System is Complete and Will Work Verify Functional and Non Functional Behaviors
61
Acceptance Testing Forms
``` User Acceptance Testing Operational Acceptance Testing Contractual Acceptance Testing Regulatory Acceptance Testing Alpha and Beta Testing ```
62
User Acceptance Testing
Validate Fitness For Use by Intended Users Real or simulated operational environment System meets user needs and fulfills requirements Perform business functionality with minimum difficulty, cost, risk
63
Operational Acceptance Testing
``` Test backup / Restore Test installation, uninstall, upgrade Disaster recovery User management Maintenance tasks Data load and migration Security Performance ```
64
Contractual Acceptance Testing
For custom developed software against contractual agreement criteria
65
Regulatory Acceptance Testing
For Gov't, Legal, or Safety regulations
66
Acceptance Testing Objectives
Establish confidence Validate System Verify Functionality
67
Acceptance Test Basis
``` Business Process User or Business Requirements Regulations, legal contracts, standards Use Cases System Requirements System or User Documentation Installation procedures Risk analysis reports ```
68
Acceptance Test Basis Operational
``` Backup and restore procedures Disaster recovery procedures Non functional requirements Operations documentation Deployment and installation instructions Performance targets Database packages Security standards or regs ```
69
Acceptance Test Objects
``` System under test System configuration and configuration data Business processes Recovery systems and hot sites Operational and maintenance processes Forms Reports Data ```
70
Acceptance Tests Defects and Failures
``` Not meet Business / User needs Business rules Contractual/Regulatory requirements not met Security Performance Operational ```
71
Acceptance Test Approaches
Customers, Business Users, Operators, Product Owner responsibility May be at the end of each iteration or a searies

ISTQB Study Cards (5 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2025 Bold Learning Solutions. Terms and Conditions