There are no auto testers in the team - what to do?
Some of you may have heard that in the first week of December an educational campaign “ Code Hour ” took place: for schoolchildren in grades 5-11, there were open lessons that showed that programming is simple and fun and everyone can learn it.
At Acronis, we decided to share our own experiences: how we try to teach our employees how to program without taking them away from work.
Task
')
As is known, acceptance testing of a product, by and large, comes down to repeating the same work from build to build. Testers chase standard scripts on every build - sometimes everything, sometimes selectively. Anyway, there is a list of actions that need to be performed periodically. Naturally, there is a desire to automate this process.
It would seem that it is not difficult at all: concrete steps and results are given that should eventually turn out - however, there is one big “BUT”. Most testers do not speak programming languages. When we faced this problem in Acronis, we had an idea to find a tool that could run test scripts written by people without developer qualifications. Testers will write scripts, as before (maybe a bit more formalized), but the machine will not be the person to execute these scripts.
Tool
Several common truths have long been formed in automation: for example, keyword-driven or data-driven approaches, BDD (Behavior Driven Development) and ATTD (Acceptance Test Driven Development), writing test libraries for your application, generating reports, etc. As a tool for our task, we chose the Robot Framework , which unites all these things together. This is an open-source framework that is primarily intended for automating acceptance testing and ATTD. At the same time, its capabilities go far beyond these limits and allow you to create a powerful framework for automating software testing with a focus on various needs.
We stopped on this framework for several reasons. First, because it has tools for testing web pages and web applications. Secondly, there is a large set of packages and extensions: for example, we use the machine management add-on via SSH. Finally, Robot Framework is based on the principle of keyword-driven testing, that is, the development of keywords that even people who are not well versed in programming can then use.
This approach is very convenient to use for the construction of automatic tests. Tests are written in a high-level language and can in theory be written by anyone who knows how to test a product.
For example :
Based on keywords, you can easily build tests with various input data, or you can turn tests into readable and executable text. The Robot Framework has built-in libraries for automating web applications, databases, file system operations, SSH, Swing, SWT, Windows GUIs, etc. Also, this framework has a test editor and many additional plug-ins for integration into any projects. In general, the architecture of the framework is built in such a way that you can easily extend the original functionality and write your own libraries in Python or Java.
Implementation
By the beginning of the experiment, most of our services were already covered by functional tests, which the developers themselves wrote on the “python”. However, the tests did not cover the web console and the integration points between it and the server. We decided, so to speak, to “kill two birds with one stone”: to teach testers to write automatic tests and to involve front-end developers to write basic functionality and keywords at the lower level. For example, the code for the phrase “open browser” in the Robot Framework is as follows:
In general, the framework is very easy to use, so our front-end developers quickly mastered it and began to cover the most painful parts of the code with tests. In our opinion, it is worth mentioning a good reporting system, which is provided by the robot out of the box. Although we did not have to use it too much, since we already had our own reporting system for testing.
Integration of the Robot Framework with our reporting system did not cause any special problems. The robot supports any kind of add-ons for reports: you just need to write a Python class with a couple of methods:
Another feature that we evaluated in this case is the ability to group tests using tags. Each test can be assigned one attribute or another, and after that only those that have it can be selected to run. For example, mark tests that run for a long time, and do not run them with each run. We use this opportunity mainly to monitor our combat servers. We select some of the tests that check the accessibility of the main entry points to the system, write the appropriate plug-in (so that the result is in a format that is understandable for zabbix-agent) and as a result we have a permanent monitoring system of the availability of our site.
At this link you can see the demo version of the robot framework: click
As for bringing our testers to automation, we are moving in the right direction. Now developers write scripts “how to check” to each bug or task in the bug tracker: moreover, they write so that they can be easily used in their work. So, step by step, we convince our testers that programming and testing are easy :)
At Acronis, we decided to share our own experiences: how we try to teach our employees how to program without taking them away from work.
Task
')
As is known, acceptance testing of a product, by and large, comes down to repeating the same work from build to build. Testers chase standard scripts on every build - sometimes everything, sometimes selectively. Anyway, there is a list of actions that need to be performed periodically. Naturally, there is a desire to automate this process.
It would seem that it is not difficult at all: concrete steps and results are given that should eventually turn out - however, there is one big “BUT”. Most testers do not speak programming languages. When we faced this problem in Acronis, we had an idea to find a tool that could run test scripts written by people without developer qualifications. Testers will write scripts, as before (maybe a bit more formalized), but the machine will not be the person to execute these scripts.
Tool
Several common truths have long been formed in automation: for example, keyword-driven or data-driven approaches, BDD (Behavior Driven Development) and ATTD (Acceptance Test Driven Development), writing test libraries for your application, generating reports, etc. As a tool for our task, we chose the Robot Framework , which unites all these things together. This is an open-source framework that is primarily intended for automating acceptance testing and ATTD. At the same time, its capabilities go far beyond these limits and allow you to create a powerful framework for automating software testing with a focus on various needs.
We stopped on this framework for several reasons. First, because it has tools for testing web pages and web applications. Secondly, there is a large set of packages and extensions: for example, we use the machine management add-on via SSH. Finally, Robot Framework is based on the principle of keyword-driven testing, that is, the development of keywords that even people who are not well versed in programming can then use.
This approach is very convenient to use for the construction of automatic tests. Tests are written in a high-level language and can in theory be written by anyone who knows how to test a product.
For example :
open browser welcome page should be opened username field should be visible password field should be visible login button should be visible input username $username input password $password press login button Based on keywords, you can easily build tests with various input data, or you can turn tests into readable and executable text. The Robot Framework has built-in libraries for automating web applications, databases, file system operations, SSH, Swing, SWT, Windows GUIs, etc. Also, this framework has a test editor and many additional plug-ins for integration into any projects. In general, the architecture of the framework is built in such a way that you can easily extend the original functionality and write your own libraries in Python or Java.
Implementation
By the beginning of the experiment, most of our services were already covered by functional tests, which the developers themselves wrote on the “python”. However, the tests did not cover the web console and the integration points between it and the server. We decided, so to speak, to “kill two birds with one stone”: to teach testers to write automatic tests and to involve front-end developers to write basic functionality and keywords at the lower level. For example, the code for the phrase “open browser” in the Robot Framework is as follows:
*** Keywords *** open browser [Arguments] ${url} run keyword if '${DEBUG}' == 'false' set log level debugging Browser.open browser ${url} ${BROWSER} desired_capabilities=service_args:--ignore-ssl-errors=true;--ssl-protocol=tlsv1;--debug=${DEBUG};--disk-cache=true;--max-disk-cache-size=204800 set browser implicit wait ${IMPLICIT WAIT} set selenium speed 0.2s delete all cookies set window size 1400 1280 # for PhantomJS maximize browser window In general, the framework is very easy to use, so our front-end developers quickly mastered it and began to cover the most painful parts of the code with tests. In our opinion, it is worth mentioning a good reporting system, which is provided by the robot out of the box. Although we did not have to use it too much, since we already had our own reporting system for testing.
Integration of the Robot Framework with our reporting system did not cause any special problems. The robot supports any kind of add-ons for reports: you just need to write a Python class with a couple of methods:
class CustomReporter: def start_suite(self, name, attributes): # put your code here def end_suite(self, name, attributes): # put your code here def start_test(self, name, attributes): # put your code here def end_test(self, name, attributes): # put your code here Another feature that we evaluated in this case is the ability to group tests using tags. Each test can be assigned one attribute or another, and after that only those that have it can be selected to run. For example, mark tests that run for a long time, and do not run them with each run. We use this opportunity mainly to monitor our combat servers. We select some of the tests that check the accessibility of the main entry points to the system, write the appropriate plug-in (so that the result is in a format that is understandable for zabbix-agent) and as a result we have a permanent monitoring system of the availability of our site.
At this link you can see the demo version of the robot framework: click
As for bringing our testers to automation, we are moving in the right direction. Now developers write scripts “how to check” to each bug or task in the bug tracker: moreover, they write so that they can be easily used in their work. So, step by step, we convince our testers that programming and testing are easy :)
Source: https://habr.com/ru/post/247109/
All Articles