Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

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
Q

Test objective

A

A reason or purpose for designing and executing a test

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

Test type

A

A group of test activities based on specific test objectives aimed at specific characteristics of a component or system

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

User acceptance testing

A

Acceptance testing conducted in a real or simulated operational environment by intended users focusing their needs, requirements and business processes.

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

Usability testing

A

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.

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

V-model

A

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
Q

Validation

A

Confirmation by examination and through provision of objective evidence that the requirements for a specific intended use or application have been fulfilled.

31
Q

Verification

A

Confirmation by examination and through provision of objective evidence that specified requirements have been fulfilled.

32
Q

White Box Testing

A

Testing based on an analysis of the internal structure of the component or system.

33
Q

Development Lifecycles

A

Sequential (Waterfall)
Incremental
Iterative

34
Q

Test Levels

A 
Component
Integration - Component / System
System
Acceptance
  UAT
  Operational
  Contractual
  Regulatory
  Alpha
  Beta
35
Q

Test Types

A 
Functional
Non Functional
  Performance, Usability, Security
Structural (whitebox)
Effects of Changes
  Confirmation
  Regression
  Maintenance (Mods, Migration, Retirement)
36
Q

Good Testing Characteristics

A

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
Q

Sequential Development Types

A

Waterfall

V Model

38
Q

Incremental Development

A

Requirements, designing, building and testing a system in pieces.
Software feature set grows incrementally.

39
Q

Iterative Development

A 
Feature groups specified, designed, built, tested in a series of cycles of fixed duration.
RUP
sCRUM/aGILE
Kanban
Spiral
40
Q

Sequential Development Model

A

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
Q

V-model levels

A

Development - Testing

  1. User Requirements - Acceptance Testing
  2. System / Software Requirements - System Testing
  3. Architecture/Design - Integration Testing
  4. Detailed Design - Component Testing
42
Q

Key Elements of a Testing Level

A 
Specific objectives
Test Basis
Test Object
Typical Defects / Failures
Specific approaches and responsibilities
Suitable Test Environment
43
Q

Test Environment

A 
A collection of 
Hardware
System Software
Application software
Documentation
People
Interfaces
Data
44
Q

Driver

A

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
Q

Stub

A

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
Q

Test objectives

A

Reduce Risk
Verify Functional, non Functional behaviors
Build confidence in quality
Find Defects
Prevent defect escapes to higher levels of tests

47
Q

Component Test Basis

A

Detailed Design
Code
Data Model
Component specifications (api, inputs, outputs)

48
Q

Component Test Objects

A

Components, units, or modules
Code and Data Structures
Classes
Database modules

49
Q

Component Defects and Failures

A

Incorrect functionality
Data flow problems
Incorrect logic and code

50
Q

Component Testing Approach

A

Done by Developer

Can be Test Driven

51
Q

Integration Test Basis

A

Software and System Design
Sequence Diagrams
Interface and communication protocol specifications
Use Cases
Architecture at component or system level
Workflows
External interface definitions

52
Q

Integration Test Objects

A 
Subsystems
Databases
Infrastructure
Interfaces
Api's
Microservices
53
Q

Integration Defects and Failures

A 
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
Q

Integration Testing Approaches

A

Concentrate on testing the integration in functional, non functional, structural capabilites
Component Integration - Developers
System Integration - Testers
Plan Integration Tests before development

55
Q

System Testing Objectives

A 
Focus on whole system 
End to end tasks
Non Functional Behaviros
Validate system is complete
Data complete/meet regulations
56
Q

System Test Basis

A 
System and Software requirements
Risk analysis reports
Use cases
Epics / Features /User Stories
Models
State diagrams
Manuals
57
Q

System Test Objects

A 
Applications
Hardware Software systems
Operating systems
System under test
System configuration
58
Q

System Test Defects and Failures

A 
Incorrect calculations
Functional / Non Functional behavior
Flow Control Data Flows
End to End functionality
Production failures
59
Q

System Testing Approaches

A

End to End
Functional and Non Functional
Independent Testers
Early involvement

60
Q

Acceptance Testing Objectives

A

Establish confidence in Quality
Validate System is Complete and Will Work
Verify Functional and Non Functional Behaviors

61
Q

Acceptance Testing Forms

A 
User Acceptance Testing
Operational Acceptance Testing
Contractual Acceptance Testing
Regulatory Acceptance Testing
Alpha and Beta Testing
62
Q

User Acceptance Testing

A

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
Q

Operational Acceptance Testing

A 
Test backup / Restore
Test installation, uninstall, upgrade
Disaster recovery
User management
Maintenance tasks
Data load and migration
Security
Performance
64
Q

Contractual Acceptance Testing

A

For custom developed software against contractual agreement criteria

65
Q

Regulatory Acceptance Testing

A

For Gov’t, Legal, or Safety regulations

66
Q

Acceptance Testing Objectives

A

Establish confidence
Validate System
Verify Functionality

67
Q

Acceptance Test Basis

A 
Business Process
User or Business Requirements
Regulations, legal contracts, standards
Use Cases
System Requirements
System or User Documentation
Installation procedures
Risk analysis reports
68
Q

Acceptance Test Basis Operational

A 
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
Q

Acceptance Test Objects

A 
System under test
System configuration and configuration data
Business processes
Recovery systems and hot sites
Operational and maintenance processes
Forms
Reports
Data
70
Q

Acceptance Tests Defects and Failures

A 
Not meet Business / User needs
Business rules
Contractual/Regulatory requirements not met
Security
Performance
Operational
71
Q

Acceptance Test Approaches

A

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.
© 2024 Bold Learning Solutions. Terms and Conditions