12. Software Testing Flashcards
Reasons for testing
- detect defects
- support design and implementation
- prevent introduction of defects
- document behaviour of system
- demonstrate system meets specification
testing concepts
interface
- expected service of a system
failures
- deviation from expected system behaviour
defects
- causes failure of system
slips
- actions by programmers that introduces defects
scales of test
- unit test
- integration test
- acceptance test
test terminologies
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
defects testing
goal
- discover defects to be rectified
derived from
- architecture and design documents
acceptance testing
goals
- demonstrate system meets requirements
derived from
- requirement specification
behavioural driven development
derive test cases from a collection of user stories and scenarios
user story scenario steps step functions API implementation
mapping steps in test case
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
Good practices for BDD
- keep scenarios short
- have individual step short
- comply with GWT pattern
- write features in user domain language
- use frameworks sot reduce redundancy
- develop feature and implementation gradually
- work with customers to validate features
limitation of BDD
- specification by example which needs many examples
- philosophy makes abstraction difficult
- need to maintain steps definitions as features changes
- hard coding of dependencies
- only one level of abstraction possible with gherkin
- gherkin steps sequential so all combinations have to be expressed