12. Software Testing Flashcards

1
Q

Reasons for testing

A
  1. detect defects
  2. support design and implementation
  3. prevent introduction of defects
  4. document behaviour of system
  5. demonstrate system meets specification
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

testing concepts

A

interface
- expected service of a system

failures
- deviation from expected system behaviour

defects
- causes failure of system

slips
- actions by programmers that introduces defects

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

scales of test

A
  1. unit test
  2. integration test
  3. acceptance test
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

test terminologies

A

test case
- set of actions to be performed on software with an expected outcome

test
- execution of a test case

testing
- practice of creating, maintaining, evaluating test cases

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

defects testing

A

goal
- discover defects to be rectified

derived from
- architecture and design documents

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

acceptance testing

A

goals
- demonstrate system meets requirements

derived from
- requirement specification

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

behavioural driven development

A

derive test cases from a collection of user stories and scenarios

user story
scenario
steps
step functions
API
implementation
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

mapping steps in test case

A

scenario
GIVEN –> how to setup test

WHEN –> actions to take during test

THEN –> assertions to be made and output at the end of the test

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

Good practices for BDD

A
  1. keep scenarios short
  2. have individual step short
  3. comply with GWT pattern
  4. write features in user domain language
  5. use frameworks sot reduce redundancy
  6. develop feature and implementation gradually
  7. work with customers to validate features
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

limitation of BDD

A
  1. specification by example which needs many examples
  2. philosophy makes abstraction difficult
  3. need to maintain steps definitions as features changes
  4. hard coding of dependencies
  5. only one level of abstraction possible with gherkin
  6. gherkin steps sequential so all combinations have to be expressed
How well did you know this?
1
Not at all
2
3
4
5
Perfectly