Brainscape's Knowledge GenomeTM

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


See full index

ISTQB 2018 > flashcards > Flashcards

flashcards

1
Q

verify T basis early in the SDLC will …

A

prevent defects

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

T control in fundament.T process - when?

A

always

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

design and prioritize of high level TC - when?

A

T analysis and design

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

developer makes a __ which causes a __ when code is dynamically tested

A

mistake, failure

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

exhaustive T is __

A

impossible

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

Func T can be conducted at ___ levels

A

all

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

Non-func T can be conducted at ___ levels

A

all

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

triggers for Maintenance T

A

a component in production is modifies, migrated or retired

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

V-model. Design docs (DD) available. What Testers do?

A

create func/non-func TCs + review DD

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

Formal review. Role which documents issues

A

scribe

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

static analysis best finds

A

dead code

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

best T tech for: determine/improve code maintainability

A

static

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

document specifies input/output for test

A

TC specs

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

what is a test condition?

A

is what a TC targets for testing. = TC tests a test condition

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

reason for use experience-based tech?

A

can found defects which missed by more formal tech

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

error guessing is used in …

A

experience T

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

how calc decision (D) coverage?

A

num of D outcomes executed / total num of D outcomes in module

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

how calc statement (S) coverage?

A

num of S executed / total num of S in module

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

equivalence partitioning requires

A

one TC for each partition, one for too low and one for too high

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

boundary value analysys (BVA) requires

A

for each partition: prev+first - 0;1 + 49;50 + 59;60 + 69;70 + 79;80

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

T design specs contains …

A

T conditions (what to test) + T approach

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

TC specs contains …

A

test cases

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

T procedures contain …

A

test steps

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

full statement coverage

A

each S (=operator. usually ‘if’) executed once

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

what T leader does ..

A

writes a T strategy

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

T planning should be … (when?)

A

not when. It’s a continuous activity

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

Risk-based T is an … approach

A

analytical (risk analysis)

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

T summary report contains ‘variances’ section which descibes …

A

diff btw what was planned for T and what was ACTUALLY tested

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

system always become more reliable after debugging: T/F?

A

F

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

what fund. T principle helps to find as many bugs as possible?

A

defect clustering

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

3 activities of T implem and execution:

A
  1. TC dev and prioritize, create T data, write T proc; 2. group TC into TS; 3. verif T env
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

V-model includes the verif of …

A

design

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

acceptance T is required for …

A

confidence

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

M Testing requires …

A

both re-test and R test

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

M Testing is difficult to scope =>

A

req careful risk and impact analysis

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

S. and D. Testing are complementary because …

A

share the aim of ident defects but differ in the defect types found

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

reviews are a cost-effective …

A

early static test

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

use case testing is good for …

A

acceptance, cover main business processes, find defects in components integration

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

which fundamental T activity do the test data prep tools support?

A

T analysis and design

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

if disagreement w dev …

A

remind about common goal create quality systems

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

inside SDLC, testing role is …

A

provide decision-making info

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

sometimes T is required for legal reasons because …

A

contracts may specify T reqs

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

root cause analysis helps …

A

to better identify and correct the defects root cause

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

pesticide paradox is …

A

running the same T over and over -> reduce the chance of finding new defects

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

well-managed test level should have …

A

a T objective

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

black-box T us based on …

A

req. docs

47
Q

experience-based T is used …

A

in conj w more formal tech

48
Q

TC tests T cond by …

A

following T procedures

49
Q

bva =

A

2 per valid range + 1 for negative + 1 for exceeding

50
Q

risk level is determined by …

A

likelyhood and impact

51
Q

defect density is used for …

A

determine which areas of sw have the highest number of defects -> re-evaluate risk/priority

52
Q

T exec tool purpose is …

A

execute T objects using automated T scripts

53
Q

pilot project objectives are …

A

learn, evaluate the fit in the organization, decide standard usage, assess benefits

54
Q

T contributes to the quality of delivered software by …

A

identif root causes of defects from past projects and use lessons -> improve processes -> help to reduce defect count

55
Q

T planning assigns resources and …

A

sets the level of T procedures

56
Q

acceptance T test basis is …

A

risk analysis report, system reqs, business use cases

57
Q

objective for T is …

A

finding defects

58
Q

objectives for acceptance T are …

A

confidence + assess readiness for deployment and use

59
Q

debugging process:

A

T ident defect, Dev locate and fix, T confirm

60
Q

verify the T env is ready - done during this fundamental T process:

A

Planning and Control

61
Q

choice of SDLC model depends on …

A

product and project characteristics

62
Q

what T metrics provides the best indication of T progress?

A

Test failure rate of tests executed

63
Q

Integration T test level. Test basis:

A

software and system design

64
Q

Integration T test level. Test objects:

A

interfaces

65
Q

independent T is important because …

A

independent T can verify assumptions made during specification and implementation of the system

66
Q

functional and structural T can be used together at __ T levels

A

ALL

67
Q

M Testing is triggered by …

A

changes to delivered sw and uses impact analysis to min regression T

68
Q

Formal review. One of roles -

A

moderator

69
Q

review process success factors are …

A
  1. predefined objectives; 2. right people involved; 3.emphasis on learning and process improvement
70
Q

experience-based T: TC are derived from …

A

knowledge of the testers

71
Q

most effect the testing efforts -

A

product reqs for reliability and security

72
Q

T planning - when

A

continuously in all life cycle processes and activities

73
Q

execution tools examples:

A

test harness, test comparators

74
Q

pilot project main reason:

A

assess cost-effectiveness

75
Q

T planning - major tasks:

A

find: scope, risks, objectives

76
Q

evaluate reqs testability is a part of T. phase

A

T analysis/design

77
Q

acceptance TC are based on …

A

output of requirement analysis/req.specs

78
Q

validation =

A

helps to check that we have built the right product

79
Q

impact analysis helps to decide …

A

how much testing should be done

80
Q

functional system testing is …

A

end-to-end func of the system as a whole

81
Q

technical review AKA

A

peer review

82
Q

formal review kick-off =

A

explain objectives

83
Q

low level design -> what level of T?

A

integration

84
Q

business reqs -> what level of T?

A

acceptance

85
Q

high level design -> what level of T?

A

system

86
Q

review success factors:

A
  1. defects found are welcomed and expressed objectively; 2. mgmt support; 3. emphasis on learn and proc improv
87
Q

static analysis tools can find defects:

A

vars never used, security vuln, prog.std violations, uncalled func

88
Q

T cond derive from …

A

specs

89
Q

regression T - when:

A

after sw changed, environment changed

90
Q

T leader tasks:

A
  1. interact w T tool vendor; 2. write T sum report; 3. decide what should be automated and how
91
Q

typical exit criteria …

A

Thoroughness measures, reliability measures, cost, schedule, tester availability and residual risks.

92
Q

when to stop T ?

A

when T completion crit have been met

93
Q

formal review phases:

A

plan, kick-off, prep, review meeting, rework, follow-up

94
Q

T objectives during dev

A

provoke as many failures as possible

95
Q

T objectives during delivery

A

confirm that system works as expected and assess the quality for stakeholders

96
Q

QA?

A

prevents defects

97
Q

static T is …

A

remove ambiguites and errors

98
Q

dynamic T is …

A

execute program with some test data

99
Q

7 T principles

A
  • T shows the presence of bugs
  • exhaustive T is impossible
  • early T
  • defect clust
  • pesticide paradox
  • T is context-dependent
  • absence-of-errors fallacy - no errors doesn’t mean good product
100
Q

if risk is low and acceptable ->

A

stop T and ship

101
Q

T should provide enough info for whom?

A

stakeholders

102
Q

risk analysis answers:

A
  • what to test 1st
  • what to test most
  • how thoroughly to test
  • what not to test
  • how much time to allocate for T
103
Q

fundamental T process steps:

A

1a. Plan = def T obj and T activities
1b. Control = compare actual progress against the plan and report status
2. Analysis/Design = tangible T cond and T cases, test-bed
3. Implem/Execute = write T proc, TC->TS, priority, check test-env, run, log, bugrep
4. Evaluate exit crit and summary report to stakehold (what planned/achieved)
5. T closure

104
Q

T design tech list

A

bb, wb, exp-based

105
Q

bb types

A

decision-table, state_transition, use_case(actors/activities/system), bva, equiv_part

106
Q

T design process parts:

A

identify T cond / T cases / T data

107
Q

typical test design strategy

A
  1. func (bb)
  2. non-func
  3. wb - check statement/decision cov and create new TCs if necessary
  4. exp-based T
108
Q

test types

A 
func
non-func
struct = wb
related to changes (regression, re-test, maintenance)
109
Q

validation =

A

doing the right thing (sw created by specs but code not maintainable)

110
Q

verif =

A

doing the things in the right way (good code but not match specs)

111
Q

V&V for Testers

A

verif=detect_faults, valid=comply

112
Q

V&V for Analysts

A 
verif = reqs not ambigious and complete
valid = valid w customer what he asks make sure
113
Q

signs of good T for any model

A

each T level has clear T obj
for every dev act -> T act
review drafts as soon as they’re ready

114
Q

T exec tools types:

A

T comparators
coverage measure
security T
test harness / unit test framework

ISTQB 2018 (1 decks)

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