Robot FrameworkProcess automation is becoming increasingly important when developing new software and hardware, as a means to detect implementation failures, carry out behavioral tests involving resources and scenarios, etc. On top of saving employees a great amount of time, it is a quick and easy method that is highly reliable when compared to the alternative: specific tests that have to be run manually. As a result, well-known and highly effective infrastructures (like Robot Framework) have been created.

 

What is Robot Framework?

It is an open source test automation framework designed for acceptance testing and acceptance test-driven development. It is based on Python and allows us to test a wide range of distributed applications.

The environment that has been created is made up of multiple libraries and tools that were previously developed.

Why use Robot Framework to test applications?

  • As previously mentioned, the framework is open source (meaning it brings all the advantages associated with that type of code).
  • It is very easy to install: you can do it using Python’s standard package manager (Pip). You can install it from the source, using a JAR distribution, and even manually.
  • Robot Framework is also greatly valued because it is independent from the platform and application to be tested.
  • Users do not need to use any sort of programming language to implement and run tests.
  • The Robot Framework tool itself provides a wide range of libraries (Android, database, etc.) to test all kinds of applications.
  • An API library will also be provided in order to create proprietary test libraries that can be run in both Java and Python.
  • A command line and output files that are readable in XML format are also provided. These can be used later on to build log and report files (in HTML format) containing a great deal of accurate information presented in a pretty simple and intuitive manner.

Robot Framework structure:

The structure of the Robot Framework’s infrastructure is made up of four well-differentiated modules or layers.

Following a bottom-up approach, we shall now briefly describe each of them:

  • System being tested: It’s the architecture’s most physical layer. Here, we shall find each and every physical system, application, environment, etc. to be tested, automated…
  • We later find the Tests layer, with its own tests and libraries. This layer is connected to the previous one by means of system interfaces and to the next one through an API test library.
  • The Robot Framework infrastructure can be found right at the next level. It parses test data and interacts with the lower layer.
  • Lastly, we find test data.

Companies that use this infrastructure:

Leading companies in a wide range of sectors and industries make use of Robot Framework.
Robot Framework was developed thanks to the efforts of one of the biggest European manufacturers of communication systems and devices. The company uses this tool to test devices, software systems and protocols using graphical interfaces and APIs.
One of the main technology providers in the digital sector is using the system to test configuration tools, web interfaces and embedded devices.

A European consultancy firm that specializes in IT solutions uses Robot Framework to test automated end-to-end business processes by means of a complex network of desktop and web applications.

Other major companies use it to test software and hardware developments in broadcast equipment… And the list goes on.

Where to use Robot Framework:

The characteristics of this technology make it a very suitable tool for process automation and the testing of hardware and software systems under development.

Robot Framework is particularly useful when it comes to automation resources where programming languages cannot be easily used. It saves companies time, since they do not have to develop another testing framework, is readily available and reliable.

Teldat uses several automated test platforms to guarantee the quality of its products. Robot Framework is particularly useful when it comes to the continuous integration of a new generation of SD-WAN Edge Devices, since it runs automated tests every time the source code is modified.


About the author

Alvaro MolineroAlvaro Molinero
Telematics Engineeer in the Teldat R&D Department. Within this department he is responsible for the development of tests for the Automatic Error Detection in OSDx.

Share this post


Our Relevant Solutions