Obľúbený nástroj test automatizérov – Cypress

The automation engineers' favourite tool - Cypress

You've probably experienced many situations, in which you've cursed the work tools, which are an inevitable part of your everyday work. Just like a butcher needs a sharp knife, a courier needs a mobile van and a bricklayer needs a good-quality mortar, the developer of automated tests also needs to have the right tool for his job – a tool which is a good fit for the tested object and everyday work..

Not that our “automation engineers'” previous tool wasn't doing its job, on the contrary, a few years ago it was an ideal solution. As it sometimes happens, the years have passed and the tool has lost its effectiveness. In the following article we would like to describe our beginnings, as well as the migration process of our previous “backend” test automation based on the Micro Focus UFT to very popular and by the community well-liked tool – to Cypress.

THE INNOVATIVE FRIDAYS GAVE A GO TO THE NEW TOOL

The format of the so-called innovative Fridays has become the Cypress' starting line. The first test concept designed in this tool was created on this workshop, which is organized on our project regularly once in a quarter of a year. The topics are collected in advance, while everybody can join either with their own idea or just join the already existing idea and a group, which then develops this idea and works on the first solution.

Some people involved in the project considered the Cypress an appropriate alternative already for a long time. The developers from one of the “scrum” teams had even begun to use it in isolation, but most of the test automation engineers were using the previous tool. Gradually, four more teams joined the first team, so the new tool was gaining even more space.

THE PROCESS AND THE REASONS OF CHOICE

The migration was specific and unique in that only teams working with the system application layer were involved. Our project is quite huge and most people within the project work with the functional and integrational testing of one or more microservices (Spring Boot). That's why it was necessary to choose a universal tool designed for the test automation. Even though the Cypress is presented mostly as a UI tool, it doesn't miss out on elements, which enable to cover the whole process from the database through the REST service, “messaging”, SOAP communication to the already mentioned web presentation layer.

Moreover, the Node JS, in which the Cypress operates, provides the modularity by NPM, which is a public package manager for JavaScript providing a wide palette of plugins. As application layer testers, we were offered an opportunity to “misuse” one of our developers' unit test tools, but we decided to keep the decentralized set-up of the project. In practice, it means that as developers of automated tests we were partly separated, despite our close contact with our teams (mostly the developers).

PREPARATION OF BASIC FUNCTIONALITIES

In the preparation of Cypress for its atypical role for web services testing, some questions have emerged, to which we needed to find the suitable answers.

HOW MANY SEPARATE PROJECTS DO WE USE?

In case it's a small and easy application, the solution is very easy, thus one Cypress project for everything. But our situation was different. Since each of the microservices represents a separate application with a bunch of functionalities, there could be a problem with the code sharing, if we created a separate Cypress project for every microservice. Moreover, the work would be slowed down, because every team manages multiple microservices, and the tester would have to switch projects constantly.

We thought about a different approach, and thus to create one big global repository with all the tests for 20+ microservices. However, the final solution was the middle path. We divided the applications to clusters, which got the dedicated Cypress project. In practice, it means that every team has one repository, because it handles a group of “backend” applications, which have the common technical denominator.

HOW TO SOLVE REPORTS, WHICH WE WANT TO SAVE AND ARCHIVE?

As the test management tool we were using ALM, which is compatible with UFT, but difficult to integrate with Cypress. We temporarily chose the path for the reports' creation with the help of the Mochawesome library, which generates an HTML report after the test execution. We save the HTML reports to Gite together with the tests in a separate folder, and we add the report to the particular user story by link.

IMPLEMENTING CI/CD IMMEDIATELY OR LATER?

Nowadays is the integration of automated tests to “the CI/ID pipeline” very popular, however we decided not to use it in our project. The main reason is the way of code testing by our developers. Besides the unit tests, they also create the so-called system tests, which are integrated in the “build pipeline”. These are very similar to our function tests, but in comparison with our test, they use less testing scenarios. That's why we decided not to apply another testing layer.

HOW TO APPROACH THE MYSQL DATABASES?

For an easy access, we used the NPM package “mysql”.

HOW TO MUTUALLY SHARE THE URLS, LOGIN AND ACCESS DATA?

We used the existing configuration server, which serves for the Spring Boot applications. We access it with the help of other NCM package ("cloud-config-server"), by which we always have all the required access data, which are in case of change updated by our developers.  

EDUCATION PROCESS AND MIGRATION

After solving the technical matters, we started to share the knowledge and to plan the migration. The process of education and sharing of the know-how went very well, even though we have been using the low code environment 90% of the time before. The developers of automated tests got accustomed to Cypress quite fast. The migration plan was a bit more difficult. Already from the beginning, we anticipated that such number of tests won't be that easy to migrate, as the Cypress is a completely different tool. And so the only thing left for us, was to start planning gradual manual migration of one test after the other. The numbers were surprising for everyone. There were lots of tests, that's why every team got the space to optimize its projects and to estimate the migration time. Based on all the teams' estimates, we decided to migrate gradually quarter of year by quarter of year and develop new tests in the meantime.

The migration itself went smoothly, and in the moment we use the UFT only to gain the required information from the previous test to create a new one in Cypress.

A GLIMPSE INTO THE FUTURE

After some time, we found out that not every decision of ours was correct. For example, by separating the repositories we caused that every developer of automatized tests is doing their own solution implementation in Cypress. However, the most important is, that the whole situation is significantly better than it was when we were using the previous tool for test automation. Cypress is much more effective and its biggest advantage is the time saving.

Autor: Jozef Kováč

Interview with an RPA Developer

Interview with an RPA Developer

Robotic Process Automation (RPA) is a technological trend that we have discussed with our colleague and RPA developer Andrej.

(Andrej loves folklore, so you can easily identify him on a photo.)

How was your first meeting with RPA?

"It was two years ago, after the completion of a previous project, where I worked as a Java developer. At that time, FPT was launching a new RPA automation project for Innogy. Since it was a new thing, I was interested.”

Describe your team and the volume of the automated processes.

"The project has been running since 2017, I joined in the middle of 2018. The integration of the team is currently underway within the new infrastructure of our customer. This is also related to the division of the team into operational and development parts. We have a total of 7 automators in the team, four of them in Košice and also two analysts who prepare processes for automation. The automated processes are diverse, depending on the customer, as they are processes within the entire group. We currently have 13 customers.”

How is the complexity or difficulty of processes that you are automating?

"The complexity of the process depends on the number of technologies used. An example is the process which we start by obtaining input data from the e-mail, which we then use in SAP. We process them there, export them to Excel and process them again in a web application. Finally, we send an email about the successful completion of the requested operation. In practice, this means a large number of steps and, in particular, exceptions that need to be considered. On the other hand, in processes that use less technology, the emphasis is often placed on the processing speed. This involves, for example, processing of large amounts of input data."

What do you consider most challenging in the process development?

"In addition to automating new processes, I also do support for the older ones. This means that the more processes the automator has processed, the more work he has if one of them does not work or needs to be modified. That is why it is sometimes difficult to focus on developing a new process and at the same time make it all on schedule.”

What do you like most about working with RPA?

"I like to see that the automated process works properly and helps the customer in practice. I also like the variety of processes in which I can use knowledge from previous projects.”

What assumptions or knowledge should an RPA developers have?

"Definitely the ability to learn and adapt quickly, always coming up with new solutions. The more technologies a person comes into contact with, the easier it will be to be able to process new processes. It is also good to be able to think like a programmer, ie. know something about recursion or objects - this can be applied to process design.”

What is your view of the RPA perspective? Will it be as widespread in a few years as expected?

"RPA is undoubtedly a very trendy and desirable issue. It saves time and resources when performing repetitive tasks, such as generating monthly invoices for a large number of customers. BluePrism, the RPA tool used in our project, is being improved with each version, so that automation itself is advancing and becoming simpler and more complex. I believe that RPA will be on the rise in the next five years."

You mentioned BluePrism, how do you like working with it?

"In general, BluePrism is considered one of the most comprehensive RPA tools on the market. It is robust and works well with key tools such as SAP or MS Office. Solutions to various tasks are relatively easy to find on the web, but the ability to try this tool is limited. The BluePrism environment itself is logical and clear. The possibility to finish programming your own objects is also excellent. In terms of cost, it is one of the more expensive tools suitable for large companies.”

en_USEnglish