_ December 4, 2019_ Lucian Costea

The hard to swallow pills of test automation in software testing services

Topics of this article: software testing services,QA automation, test automation.

About the author: Răzvan Vușcan is a software automation tester in our Travel&Hospitality Division

Software testing services can be challenging. Especially when it comes to approaching new technologies in test automation.The idea of this article came to me after several experiences and lessons learned during my time doing test automation in software testing services for the travel industry . Most web applications have a great impact on travel software management. When I first started out, I was eager to learn, explore, but also try to do everything by the book. I figured I had to automate everything, and felt that the programming language and tools used at that time (Java and Selenium Webdriver) were my golden ticket to doing so. Well, since almost everybody was using these. I really felt that these two were foolproof for writing automated tests and that no web application could pose a challenge. And they did work out… for a while.

The process of software testing services

Then times changed. The software testing services became more complex, and the leading travel web applications I worked on starting moving away from their monolithic structure. The one written using conventional programming languages such as Java or .Net. Scripting languages like Javascript started gaining more and more ground. User interfaces were snappier, flashier. The conventional flow that would take users from one page to another was shifting towards single-page applications that were everything to loaded on the same page asynchronously.

Naturally, this complicates things and I felt that the tools I was using were becoming too pretentious for the new UIs. Tests were becoming flaky because they couldn’t handle event loading correctly or async animations and calls. So, initially, I started finding technical solutions to these problems. Since at the time I was doing only test automation for travel management software and no manual testing I could afford to implement all kinds of pieces of logic in order to deal with the technical issues in the test framework. But maintenance was starting to become a nightmare. I started spending way more time in maintaining tests instead of writing new content or running them. Felt that I was getting nowhere. Afterward, I began to understand the test framework much better and started using the programming language a lot more than just for writing tests. I even built several new frameworks from scratch to experiment with different theories and approaches. Also, I worked a lot more on the Continuous Integration pipelines, trying to speed them up, split them in order for them to become more efficient, and generating better reports with a fast turn around time.

Don't forget your roots

But as I advanced down this developer/DevOps-like path, I was just moving away from my initial role as a tester. My technical solutions were becoming more and more complex, for example focusing too much on how to write logic to bypass a loading problem, instead of just admitting that perhaps the page/code is abnormally slow and bugging the developers to look into the issue and find a common solution.

So that was my wake-up call: I was spending too much finding overcomplicated solutions to obvious usability problems that could be a bother to a user, as well as doing WAY too much maintenance on the test automation framework and Continuous Integration pipelines.

Something had to be done. So I started doing some introspection, started by reviewing my system of values and figuring out why I wanted to be a tester in the first place. I remembered that things should be black and white when it came to testing: it’s either a bug or it’s not. Naturally, the next step was to review the automated tests in the travel management software I was working on. I noticed that these had become too long and too complex, taking too much time to run and, being so long, were prone to failure along the way. This meant that the rest of the steps were not being run and bits were no longer being tested. In short, I figured that oftentimes I would stop at the breaking point in a test invest a lot of time to do the maintenance there, but not spending too much time on the remaining part of the flow which was not run. So I had to figure out a solution of breaking up these tests who had become mammoths back into independent, atomic bits that focus on testing one thing.

Welcome the new in software testing services

Finally, the hardest thing to tackle was admitting that the testing tool and programming language I was using was not suited to the needs mentioned above. Applications User Interfaces were now being transformed through the power of React or Angular. Stuff like GWT or Drupal was being dropped in favor of the first two. So, I also needed to find a testing tool that worked well with the asynchronous calls of JavaScript on a webpage in order to spend less time doing maintenance and more time doing test scripting for the given project of software testing services.

Eventually, I found something that worked for me: NightwatchJs, which is an end-to-end test framework written in NodeJs. The learning curve was not that difficult and the switch from Java and Selenium Webdriver not as painful as I initially expected it. I loved the fact that Nightwatch was easy to integrate with Cucumber and could provide test reports written in a human-readable text which any user would understand. It also supported features being split into descriptive scenarios with clear steps. All in all, a powerful but easy to use and to maintain test framework which allowed me to focus more on writing end-to-end tests for the User Interface, but also had the potential for writing API layer tests because of it being written in NodeJs.

The lesson

I believe my greatest lesson learned was that sometimes you must let go and being anew instead of being stuck about using only one test tool or programming language. The best tool for the job isn’t always what’s being used by the masses. So, don’t be afraid to look for something better suited for your project, as I tried to find the one suitable for travel management software, in my case. If you end up wasting too much time on technical solutions or doing maintenance, then perhaps you should rethink your approach and analyze the direction you’re going before it’s too late.

If you want to read more about test automation and software testing services, find more articles about the subject HERE.