Brainscape's Knowledge GenomeTM


Top Flashcards (Certified)
All Flashcards

Testing > Test Automation Engineering > Flashcards

Test Automation Engineering Flashcards

Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0

1
Q

Test Case

A

A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions.

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

Test Step

A

A single interaction between an actor and a test object consisting of an input, an action, and an expected result.

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

Test Condition

A

A testable aspect of a component or system identified as a basis for testing.

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

Functional Testing

A

Testing performed to evaluate if a component or system satisfies functional requirements.

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

Non-Functional Testing

A

Testing performed to evaluate that a component or system complies with non-functional requirements.

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

System Under Test (SUT)

A

A type of test object that is a system.

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

Test Object

A

The work product to be tested.

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

Defect Report

A

Documentation of the occurrence, nature, and status of a defect.

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

Software Development Lifecycle (SDLC)

A

The activities performed at each stage in software development, and how they relate to one another logically and chronologically.

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

Waterfall Model

A

SDLC model that is both linear and sequential

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

V-Model

A

SDLC model where a process is executed in a sequential manner. Test levels: Component, Component Integration, System, System Integration & Acceptance

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

Component Testing

A

A test level that focuses on individual hardware or software components.

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

System Testing

A

A test level that focuses on verifying that a system as a whole meets specified requirements.

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

Integration Testing

A

A test level that focuses on interactions between components or systems.

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

Test Automation Framework (TAF)

A

A set of test harnesses and test libraries for test automation.

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

Test Harnesses

A

A collection of drivers and test doubles needed to execute a test suite.

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

Driver

A

A component or tool that temporarily replaces another component and controls or calls a test item in isolation.

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

Test Plan

A

Documentation describing the test objectives to be achieved and the means and the schedule for achieving them, organized to coordinate testing activities.

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

Test Suite

A

A set of test scripts or test procedures to be executed in a specific test run.

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

Test Run

A

The execution of a test suite on a specific version of the test object.

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

Test Log

A

A chronological record of relevant details about the execution of tests.

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

Test Automation

A

The conversion of test activities to automatic operation.

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

Test Automation Engineer

A

A person who is responsible for the design, implementation and maintenance of a test automation architecture as well as the technical evolution of the resulting test automation solution.

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

API Testing

A

A test approach performed by submitting requests to a test object using its application programming interface.

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

GUI Testing

A

A test approach performed by interacting with a test object using a graphical user interface.

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

Testability

A

The degree to which test conditions can be established for a component or system, and tests can be performed to determine whether those test conditions have been met.

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

Configuration need for a better testability of the SUT that can be generated atm by different development FWs or developers can set them manually…

A

Accessibility Identifiers

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

Configuration need for a better testability of the SUT related with application parameters…

A

System Environment Variables

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

Configuration need for a better testability of the SUT that is similar to system variables but can be set before starting deployment…

A

Deployment Variables

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

Designing for testability of a SUT consists of which aspects?

A
  1. Observability
  2. Controllability
  3. Architecture Transparency
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Observability aspect consists on…

A

The SUT needs to provide interfaces that give insight into the SUT.

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

Controllability aspect consists on…

A

The SUT needs to provide interfaces that can be used to perform actions on the SUT (i.e. UI elements, function calls, TCP/IP, and others)

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

Architecture Transparency

A

The documentation of an architecture needs to provide clear, understandable components and interfaces that give observabillity and controllability at all test levels and foster quality.

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

Test Automation Solution (TAS)

A

The implementation of a test automation architecture for a test automation assignment by understanding of functional, non-functional, and technical requirements of the SUT.

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

Test Process

A

The set of interrelated activities comprising of test planning, test monitoring, test control, test analysis, test design, test implementation, test execution, and test completion.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
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
36
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
37
Q

Test Data

A

Data needed for test execution.

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

Behavior-Driven Development (BDD)

A

A collaborative approach to development in which the team is focusing on delivering expected behavior of a component or system for the customer, which forms the basis for testing.

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

Capture/Playback

A

A test automation approach in which inputs to a test object are recorded during manual testing to generate automated test scripts that can be executed later.

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

Data-Driven Testing (DDT)

A

A scripting technique that uses data files to contain the test data and expected results needed to execute the test scripts.

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

Generic Test Automation Architecture (gTAA)

A

A representation of the layers, components, and interfaces that allows for a structured and modular approach to implement test automation.

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

Keyword-Driven Testing

A

A scripting technique in which test scripts contain high-level keywords and supporting files that contain low-level scripts that implement those keywords.

43
Q

Linear Scripting

A

A simple scripting technique without any control structure in the test scripts.

44
Q

Model-Based Testing

A

Testing based on or involving models.

45
Q

Structured Scripting

A

A scripting technique that builds and utilizes a library of reusable (parts of) scripts.

46
Q

Test Adaptation Layer

A

The layer in a test automation architecture which provides the necessary code to adapt test scripts on an abstract level to the various components, configuration or interfaces of the SUT.

47
Q

Test Script

A

A sequence of instructions for the execution of a test.

48
Q

Testware

A

Work products produced during the test process for use in planning, designing, executing, evaluating and reporting on testing.

49
Q

Test Step

A

A single interaction between an actor and a test object consisting of an input, an action, and an expected result.

50
Q

Test-Driven Development

A

A software development technique in which the test cases are developed, automated and then the software is developed incrementally to pass those test cases.

51
Q

Generic Test Automation Architecture (gTAA) Interfaces…

A
  • SUT
  • Project Management
  • Configuration Management
  • Test Management
52
Q

SUT Interface

A

Describes the connection between the SUT and the TAF

53
Q

Project Management Interface

A

Describes the test automation development progress

54
Q

Test Management Interface

A

Describes the mapping of test case definitions and automated test cases

55
Q

Configuration Management Interface

A

Describes the CI/CD pipelines, environments and testware

56
Q

Core Test Automation Capabilities

A
  • Test Generation
  • Test Definition
  • Test Execution
  • Test Adaptation
57
Q

Test Generation

A

Supports the automated design of test cases based on a test model. Is an optional capability.

58
Q

Test Definition

A

Supports the definition and implementation of test cases and/or test suites, which optionally can be derived from a test model.

59
Q

Test Execution

A

Test execution and test logging.

60
Q

Test Adaptation

A

Provides the necessary functionality to adapt the automated tests for the various components or interfaces of the SUT. It provides different adaptors for connnecting to the SUT via APIs, protocols, and services.

61
Q

Define a distinct border of classes that have similar purposes such as TCs, test reporting, test logging, encryption, and test harnesses…

A

TAF Layers

62
Q

Test Scripts - TAF Layer

A

Purpose: Provide a TC repository of the SUT and test suite annotations. No direct calls should be made to the core libraries from test scripts.

63
Q

Business Logic - TAF Layer

A

All the SUT -dependent- libraries are stored in this layer. Is used to set up the TAF to run against the SUT and the additional configurations.

64
Q

Core Libraries

A

All the libraries that are -independent- of any SUT. This core libraries can be re-used.

65
Q

Encapsulation

A

Hiding the internal details of an object and only exposing necessary parts.

66
Q

Abstraction

A

Hiding complex implementation details and showing only essential features.

67
Q

Inheritance

A

One class can inherit properties and behavior from another class.

68
Q

Polymorphism

A

The ability to use the same method name with different implementations.

69
Q

Single Responsibility Principle (SRP)

A

A class should have only one reason to change (one responsibility).

70
Q

Open/Closed Principle (OCP)

A

A class should be open for extension but closed for modification.

71
Q

Liskov Substitution Principle (LSP)

A

Subclasses should be replaceable with their base classes without breaking functionality.

72
Q

Interface Segregation Principle (ISP)

A

A class should not be forced to implement methods it does not use.

73
Q

Dependency Inversion Principle (DIP)

A

High-level modules should not depend on low-level modules. Both should depend on abstractions.

74
Q

Risk

A

A factor that could result in future negative consequences.

75
Q

Test Fixture

A

The predefined data and test environment to test software in a repeatable manner.

76
Q

Deployment Risks

A
  • Firewall issues
  • Resource utilization
  • Network connection
  • Reliability
77
Q

Technical Deployment Risks

A
  • Packaging
  • Logging
  • Test structuring
  • Updating
78
Q

Packaging

A

Needs to be considered as version control of test automation is just as important as for the SUT.

79
Q

Test Logging Levels

A
  • Fatal
  • Error
  • Warn
  • Info
  • Debug
  • Trace
80
Q

Test Logging: FATAL

A

Is used to log events that may lead to abort the test execution

81
Q

Test Logging: ERROR

A

Is used when a condition or interaction fails and therefore fails the test case as well

82
Q

Test Logging: WARN

A

Is used when an unexpected condition/action occurs but does not break the flow of the TC

83
Q

Test Logging: INFO

A

Is used to show basic info about a TC and what happens during test execution

84
Q

Test Logging: DEBUG

A

Is used to store execution specific details that generally are not required for basic logs, but useful during investigation of a test failure

85
Q

Test Logging: TRACE

A

Similar to debug, but has even more information

86
Q

Test Structuring

A

Involves the most important part of the TAS is the test harnesses and the test fixtures included in it.

87
Q

Updating

A

The technical risk of the automatic updates on the test harnesses (e.g. agents) and version changes on devices.

88
Q

Hardcoding

A

Is the process of embedding values in the software without the ability to change them directly.

89
Q

Pipeline (CI/CD Pipeline)

A

A pipeline is an automated sequence of steps used in software development to build, test, and deploy applications efficiently.

90
Q

Application Programming Interface (API)

A

A type of interface in which the components or systems involved exchange information in a defined formal structure.

91
Q

API Connections

A

Understand the business logic that can be tested automatically and the relationship between APIs

92
Q

API Documentation

A

Serves as a baseline for test automation with all relevant information (e.g. parameters, headers, and distinct types of request-response of objects)

93
Q

Contract Testing

A

Is a type of integration testing verifying that services can communicate with each other, and that the data shared between the services is consistent with a specified set of rules.

94
Q

Measurement

A

The process of assigning a number or category to an entity to describe an attribute of that entity.

95
Q

Metric

A

A measurement scale and the method used for measurement.

96
Q

Test Progress Report

A

A type of periodic test report that includes the progress of test activities against a baseline, risks, and alternatives requiring a decision.
Must contain the test results, SUT info and documentation of the test environment.

97
Q

There is usually a unique ID added to the interaction with the same ID for each subsequent call and integration in the system

A

Trace ID / Correlation ID

98
Q

Static Analysis

A

The process of evaluating a component or system without executing it, based on its form, structure, content, or documentation.

99
Q

Verification

A

The process of confirming that a work product fulfills its specification.

100
Q

Validation

A

Confirmation by examination that a work product matches a stakeholder’s needs.

101
Q

Debuggng

A

The process of finding, analyzing and removing the causes of failures in a component or system.

102
Q

Root Cause

A

A source of a defect such that if it is removed, the occurrence of the defect type is decreased or removed.

103
Q

Root Cause Analysis

A

An analysis technique aimed at identifying the root causes of defects.

104
Q

Schema Validation

A

A type of static analysis based on a database schema.

105
Q

Test Histogram

A

A visual representation that shows the distribution of test results.

Testing (3 decks)

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