Brainscape's Knowledge GenomeTM

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


See full index

ASY ISTQB > Foundation Level 2 > Flashcards

Foundation Level 2 Flashcards

1
Q

A software development lifecycle (SDLC)

A
  1. an abstract, high-level representation of the software development process
  2. defines how different development phases and types of activities performed within this process relate to each other, both logically and chronologically
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

Examples of SDLC models

A
  1. sequential development models (e.g., waterfall model, V-model),
  2. iterative development models (e.g., spiral model, prototyping)
  3. incremental development models (e.g., Unified Process)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

Impact of the Software Development Lifecycle on Testing

A
  1. Scope and timing of test activities (e.g., test levels and test types)
  2. Level of detail of test documentation
  3. Choice of test techniques and test approach
  4. Extent of test automation
  5. Role and responsibilities of a tester
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

Good testing practices, independent of SDLC model

A
  1. For every software development activity, there is a corresponding test activity => quality control
  2. Different test levels have specific and different test objectives => comprehensive, no redundancy
  3. Test analysis and design for a given test level begins during the corresponding development phase of the SDLC => principle of early testing
  4. Testers are involved in reviewing work products as soon as drafts of this documentation are available => supports shift left
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

Testing as a Driver for Software Development (Approaches)

A
  1. Test-Driven Development (TDD)
  2. Acceptance Test-Driven Development (ATDD)
  3. Behavior-Driven Development (BDD)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

Test-Driven Development (TDD)

A
  1. Directs the coding through test cases
  2. Tests are written first, then the code is written to satisfy the tests
  3. The tests and code are refactored
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Acceptance Test-Driven Development (ATDD)

A
  1. Derives tests from acceptance criteria as part of the system design process
  2. Tests are written before the part of the application is developed to satisfy the tests
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Behavior-Driven Development (BDD)

A
  1. Expresses the desired behavior of an application with test cases written in a simple form of natural language, which is easy to understand by stakeholders – usually using the Given/When/Then format.
  2. Test cases are then automatically translated into executable tests
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Challenges & Risks of DevOps (test design perspective)

A
  1. The DevOps delivery pipeline must be defined and established
  2. CI / CD tools must be introduced and maintained
  3. Test automation requires additional resources and may be difficult to establish and maintain
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Benefits of DevOps for testing

A
  1. Fast feedback on the code quality, and whether changes adversely affect existing code
  2. CI promotes a shift-left approach in testing by encouraging developers to submit high quality code accompanied by component tests and static analysis
  3. Promotes automated processes like CI/CD that facilitate establishing stable test environments
  4. Increases the view on non-functional quality characteristics
  5. Automation through a delivery pipeline reduces the need for repetitive manual testing
  6. The risk in regression is minimized due to the scale and range of automated regression tests
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

Shift-Left Approach

A
  1. an approach where testing is performed earlier in the SDLC
  2. it does not mean that testing later in the SDLC should be neglected.
  3. the process but is expected to save efforts and/or costs later in the process.
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

Good practices that illustrate how to achieve a “shift-left” in testing,

A
  1. Reviewing the specification from the perspective of testing. These review activities on specifications often find potential defects, such as ambiguities, incompleteness, and inconsistencies
  2. Writing test cases before the code is written and have the code run in a test harness during code implementation
  3. Using CI and even better CD as it comes with fast feedback and automated component tests to accompany source code when it is submitted to the code repository
  4. Completing static analysis of source code prior to dynamic testing, or as part of an automated process
  5. Performing non-functional testing starting at the component test level, where possible. This is a form of shift-left as these non-functional test types tend to be performed later in the SDLC when a complete system and a representative test environment are available
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

Benefits of retrospectives for testing include

A
  1. Increased test effectiveness / efficiency
  2. Increased quality of testware
  3. Team bonding and learning
  4. Improved quality of the test basis
  5. Better cooperation between development and testing
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Hot fix

A

unplanned releases/deployments

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

Categories of maintenance

A
  1. Corrective
  2. Adaptive to changes
  3. Improve performance or maintainability
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

Testing the changes to a system in production includes:

A
  1. evaluating the success of the implementation of the change
  2. the checking for possible regressions in parts of the system that remain unchanged
17
Q

The scope of maintenance testing depends on

A
  1. The degree of risk of the change
  2. The size of the existing system
  3. The size of the change
18
Q

The triggers for maintenance and maintenance testing can be classified as

A
  1. Modifications, such as planned enhancements (i.e., release-based), corrective changes or hot fixes.
  2. Upgrades or migrations of the operational environment, such as from one platform to another, which can require tests associated with the new environment as well as of the changed software, or tests of data conversion when data from another application is migrated into the system being maintained.
  3. Retirement, such as when an application reaches the end of its life. When a system is retired, this can require testing of data archiving if long data-retention periods are required.
19
Q

Confirmation testing

A

confirms that an original defect has been successfully fixed.

20
Q

Regression testing

A
  1. confirms that no adverse consequences have been caused by a change, including a fix that has already been confirmation tested.
  2. Regression testing may not be restricted to the test object itself but can also be related to the environment
  3. It is advisable first to perform an impact analysis to optimize the extent of the regression testing. Impact analysis shows which parts of the software could be affected.
21
Q

Test levels: definition

A
  1. groups of test activities that are organized and managed together
  2. an instance of the test process, performed in relation to software at a given stage of development,
22
Q

Test types

A
  1. groups of test activities related to specific quality characteristics
  2. most of those test activities can be performed at every test level.
23
Q

Test levels example

A
  1. Component testing
  2. Component integration testing
  3. System testing
  4. System integration testing
  5. Acceptance testing
24
Q

Component testing

A
  1. components in isolation
  2. normally performed by developers in their development environments
25
Q

Component integration testing

A
  1. testing the interfaces and interactions between components
  2. heavily dependent on the integration strategy approaches like bottom-up, top-down or big-bang
26
Q

System testing

A

overall behavior and capabilities of an entire system or product, often including functional testing of end-to-end tasks and the non-functional testing of quality characteristics

NB using simulation of sub-systems is possible

27
Q

System integration testing

A

focuses on testing the interfaces of the system under test and other systems and external services . System integration testing requires suitable test environments preferably similar to the operational environment

28
Q

Acceptance testing

A

validation and on demonstrating readiness for deployment, which means that the system fulfills the user’s business needs.

NB ideally be intended users

29
Q

The main forms of acceptance testing

A
  1. user acceptance testing (UAT)
  2. operational acceptance testing
  3. contractual and regulatory acceptance testing
  4. alpha testing and beta testing.
30
Q

Test levels are distinguished by the following non-exhaustive list of attributes

A
  1. Test object
  2. Test objectives
  3. Test basis
  4. Defects and failures
  5. Approach and responsibilities
31
Q

Test Types

A
  1. functional testing
  2. non-funcional testing
  3. black box testing
  4. white box testing
32
Q

Functional testing

A

evaluates the functions that a component or system should perform.

The main objective - checking the functional completeness, functional correctness and functional appropriateness.

33
Q

Non-functional software quality characteristics

A
  1. Performance efficiency
  2. Compatibility
  3. Usability
  4. Reliability
  5. Security
  6. Maintainability
  7. Portability

ASY ISTQB (8 decks)

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