Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull Request for Comments to the Syllabus #45

Open
wants to merge 3 commits into
base: Review-Branch
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions LOs.csv
Original file line number Diff line number Diff line change
@@ -1,12 +1,12 @@
LO ID,K Level,Content,Slide Number,Done,Notes
LO-1.1,(K1),Recall the two main use cases of Robot Framework,,,
LO-1.1.1,(K1),recall the test levels Robot Framework is mostly used for,,,
LO-1.1.1,(K1),Recall the test levels Robot Framework is mostly used for,,,
LO-1.2.1,(K1),Recall the layers of the Generic Test Automation Architecture (gTAA) and their corresponding components in Robot Framework,,,
LO-1.2.2,(K1),Recall what is part of Robot Framework and what is not,,,
LO-1.2.3,(K1),Recall the technology Robot Framework is built on and the prerequisites for running it,,,
LO-1.3,(K1),Recall the key attributes of the syntax that makes Robot Framework simple and human-readable,,,
LO-1.3.3,(K2),Explain the difference between User Keywords and Library Keywords,,,
LO-1.3.4,(K1),Recall the difference between Resource Files and Libraries and their artefacts,,,
LO-1.3.4,(K1),Recall the difference between Resource Files and Libraries and their artifacts,,,
LO-1.4,(K1),Recall the three specification styles of Robot Framework,,,
LO-1.4.1,(K2),Understand the basic concepts of Keyword-Driven Specification,,,
LO-1.4.2,(K2),Understand the basic concepts of Behavior-Driven Specification,,,
Expand Down
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@
- [`1.1 Purpose / Use Cases`](chapter-01/01_purpose.md)
- LO-1.1 (K1) Recall the two main use cases of Robot Framework
- [`1.1.1 Test Automation`](chapter-01/01_purpose.md#111-test-automation)
- LO-1.1.1 (K1) recall the test levels Robot Framework is mostly used for
- LO-1.1.1 (K1) Recall the test levels Robot Framework is mostly used for
- [`1.1.1.1 Synthetic Monitoring`](chapter-01/01_purpose.md#1111-synthetic-monitoring)
- [`1.1.2 Robotic Process Automation (RPA)`](chapter-01/01_purpose.md#112-robotic-process-automation-rpa)
- [`1.2 Architecture of Robot Framework`](chapter-01/02_architecture.md)
Expand All @@ -21,7 +21,7 @@
- [`1.3.3 What are Keywords?`](chapter-01/03_syntax.md#133-what-are-keywords)
- LO-1.3.3 (K2) Explain the difference between User Keywords and Library Keywords
- [`1.3.4 Resource Files & Libraries`](chapter-01/03_syntax.md#134-resource-files--libraries)
- LO-1.3.4 (K1) Recall the difference between Resource Files and Libraries and their artefacts
- LO-1.3.4 (K1) Recall the difference between Resource Files and Libraries and their artifacts
- [`1.4 Specification Styles`](chapter-01/04_styles.md)
- LO-1.4 (K1) Recall the three specification styles of Robot Framework
- [`1.4.1 Keyword-Driven Specification`](chapter-01/04_styles.md#141-keyword-driven-specification)
Expand Down
3 changes: 3 additions & 0 deletions website/docs/chapter-01/00_overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
# 1 Introduction to Robot Framework

The upcoming chapters provide a concise overview of Robot Framework, including its core structure, use cases in test automation and Robotic Process Automation (RPA), and key specification styles like keyword-driven and behavior-driven testing. You'll learn about its architecture, syntax, and how test cases and tasks are organized. Additionally, the chapters explain the open-source licensing under Apache 2.0, the role of the Robot Framework Foundation in maintaining the ecosystem, and the foundational web resources available for further exploration and contributions.
65 changes: 65 additions & 0 deletions website/docs/chapter-01/01_purpose.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,65 @@
# 1.1 Purpose / Use Cases

::::lo[Learning Objectives]

:::K1[LO-1.1]

Recall the two main use cases of Robot Framework

:::

::::

Robot Framework is a versatile, open-source automation framework that supports both **test automation** and **robotic process automation (RPA)**.
Initially designed for acceptance testing, it has since evolved to cover other types of testing and various automation tasks in both IT and business environments.
Its keyword-driven approach allows users to create reusable components, making it accessible even to those with minimal programming skills.
Robot Framework can be extended through a vast array of third-party or custom made keyword libraries, allowing it to automate interactions with APIs, user interfaces, databases, and many more technologies.



## 1.1.1 Test Automation

::::lo[Learning Objectives]

:::K1[LO-1.1.1]

Recall the test levels Robot Framework is mostly used for

:::

::::

Robot Framework is widely used at various levels of testing, primarily focusing on:

- **System Testing**: Involves verifying the complete system’s behavior and capabilities. It often includes both functional and non-functional aspects (e.g., accessibility, security) and may use simulated components.

- **System Integration Testing**: Focuses on the interaction between the system under test and external services, as well as on the integration of multiple systems into a larger system, ensuring that all integrated components communicate and function together as expected.

- **Acceptance Testing**: Aims to validate that the system meets business requirements and is ready for deployment or release. This often includes different forms of acceptance testing (e.g., user acceptance, operational acceptance, regulatory acceptance) and is frequently written or conducted by end-users or stakeholders to confirm the system’s readiness for use. Acceptance tests, often defined by business stakeholders in approaches like Acceptance Test-Driven Development (ATDD), can be automated and executed earlier in the development process. This ensures that the solution aligns with business requirements from the start and provides immediate feedback, reducing costly changes later.

- **End-to-End Testing**: Verifies that a complete workflow or process within the system operates as intended, covering all interconnected subsystems, interfaces, and external components. End-to-end tests ensure the correct functioning of the application in real-world scenarios by simulating user interactions from start to finish.

Robot Framework's flexibility and support for external libraries make it an excellent tool for automating these comprehensive test cases, ensuring seamless interaction between components and validating the system's behavior also in production or production-like conditions.

Robot Framework is typically not used for **component testing** nor **integration testing** because its primary strength lies in higher-level testing, such as system, acceptance, and end-to-end testing, where behavior-driven and keyword-based approaches excel. Component testing requires low-level, granular tests focusing on individual units of code, often necessitating direct interaction with the codebase, mocking, or stubbing, which are better handled by unit testing frameworks like JUnit, pytest, or NUnit. Similarly, integration testing at a low level often requires precise control over service interactions, such as API stubs or protocol-level testing, which may not align with Robot Framework's abstraction-oriented design. While Robot Framework can technically handle these cases through custom libraries, its overhead and design philosophy make it less efficient compared to tools specifically tailored for low-level and tightly scoped testing tasks.


### 1.1.1.1 Synthetic Monitoring

Beyond traditional test levels, **Synthetic Monitoring**, also referred to as **Active Monitoring** or **Proactive Monitoring**, is a proactive approach that simulates user interactions with live systems at regular intervals. It detects performance issues or downtime early with the goal of to detect such failure before they affect actual users.



## 1.1.2 Robotic Process Automation (RPA)

Robotic Process Automation (RPA) uses software bots to perform tasks and interactions normally performed by humans, without requiring changes to the underlying applications.

Robot Framework, with its keyword-driven approach, vast ecosystem of libraries, simplicity, and scalability, is widely adopted for RPA tasks.
Robot Framework allows users to automate most workflows using ready-made keyword libraries that provide a wide range of functionalities. These libraries can be combined and reused in user-defined keywords, making automation simple and efficient. For custom functionalities or more complex tasks, Robot Framework also offers the flexibility to create custom keyword libraries using Python, enabling advanced use cases and seamless integration with unique systems.

Common use cases of RPA with Robot Framework include:

- **Data extraction and manipulation**: Automating data transfers and processing between systems.
- **Task/proces automation**: Automating tasks such as form submissions, clicks, and file operations across web or desktop applications.


104 changes: 104 additions & 0 deletions website/docs/chapter-01/02_architecture.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,104 @@
# 1.2 Architecture of Robot Framework

Robot Framework is an open-source automation framework that allows you to build automation scripts for testing and RPA (Robotic Process Automation).
It focuses on providing a keyword-driven or behavior-driven approach, making the automation easy to understand and maintain.
However, it is not a full-stack solution that encompasses all layers of automation.
Instead, it provides a flexible platform where different tools, libraries, and integrations handle specific tasks to implement a flexible automation solution.



## 1.2.1 Robot Framework and the gTAA (Generic Test Automation Architecture)

::::lo[Learning Objectives]

:::K1[LO-1.2.1]

Recall the layers of the Generic Test Automation Architecture (gTAA) and their corresponding components in Robot Framework

:::

::::

The **Generic Test Automation Architecture (gTAA)** described in the ISTQB "Certified Tester Advanced Level Test Automation Engineering" offers a structured approach to test automation, dividing it into different layers for a clear separation of concerns:

- **Definition Layer**: This layer contains the "Test Data" (test cases, tasks, resource files which include user keywords and variables).
In Robot Framework, the test data is written using the defined syntax and contains keyword calls and argument values that make the test case or task definitions structured in suites.

- **Execution Layer**: In Robot Framework, the execution layer consists of the framework itself, including its core components and APIs.
It parses and interprets the test data syntax to build an execution model.
The execution layer is responsible for processing this execution model to execute the library keywords with their argument values, logging results, and generating reports.

- **Adaptation Layer**: This layer provides the connection between Robot Framework and the system under test (SUT).
In Robot Framework, this is where the keyword libraries, which contain code responsible for interacting with different technologies and interfaces,
such as those for UI, API, database interactions, or others, are located.
These keyword libraries enable interaction with different technologies and interfaces, ensuring the automation is flexible and adaptable to various environments.

Editors/IDEs that offer support for Robot Framework's syntax are tools that support or integrate in these layers.
When writing tests|tasks or keywords, the editor supports the definition layer.
When executing or debugging tests|tasks, the editor supports the execution layer.
When writing keywords in i.e. Python for keyword libraries, the editor supports the adaptation layer.
Therefore also other additional extensions of Robot Framework can be categorized into these layers.

<!-- TODO: add a graphic here -->

## 1.2.2 What is Robot Framework & What It Is Not

::::lo[Learning Objectives]

:::K1[LO-1.2.2]

Recall what is part of Robot Framework and what is not

:::

::::


Robot Framework itself focuses primarily on **test|task execution**.
It includes:

- A parser to read test|task data and build an execution model.
- An execution engine to process model and execute the keywords.
- A result generation mechanism to provide logs and reports.
- A collection of generic standard libraries to process and handle data or interact with files and processes.
- Defined APIs for extensions and customizations.

However, Robot Framework **does not** include:

- Keyword libraries to control systems under test/RPA.

Such as:
- Web front-end automation libraries.
- API interaction libraries.
- Mobile automation libraries.
- Database interaction libraries.
- RPA libraries.
- etc.

- Code editors or IDEs.
- CI/CD Integration.

Robot Framework defines the syntax for test|task data, but it is the role of external libraries and tools to extend its functionality for specific automation needs.



## 1.2.3 Technology & Prerequisites

::::lo[Learning Objectives]

:::K1[LO-1.2.3]

Recall the technology Robot Framework is built on and the prerequisites for running it

:::

::::


Robot Framework is built on **Python** but is adaptable to other languages and technologies through external libraries.
To run Robot Framework, an [officially supported version](https://devguide.python.org/versions/) of the **Python interpreter** is required on the machine executing the tests|tasks.
Typically, Robot Framework and its libraries are installed via the "package installer for Python" (`pip`) from [PyPi.org](https://pypi.org/project/robotframework/), allowing for straightforward installation and setup.
Robot Framework itself does not have any external dependencies, but additional third party tools or keyword libraries may require additional installations.



Loading