How to get rid of problems of automation testing

We’ve explored the bumps on the road that you’re likely to run into in your journey with test automation. This article is targeted to help you avoid them. We’ll recap the problems for those of you who missed it, (those interested can read it here[hyperlink]), and move on to the measures you can adopt to overcome them.

The first problem that we had mentioned was about preparing the database.

“Consistently repeatable results rely, to an extremely large degree, on the data that you use in your database. If you run into problems and suspect it’s a flaw in your data, it might be because you’re using a system that is different from your testing framework to set up the database in question. Additionally, many people use alien database contents, which is outside the influence of the reach of their own project. Some projects may also have no dedicated databases used exclusively for automated tests.”

One approach to fix this is effective communication. Why? Because users and contributors outside the project don’t know what the project goals and aims for test automation are. This gains importance when you don’t have your own database in a CI environment. If you’re using a shared environment, check if its possible to demarcate a certain set of data to be used only for automated tests.

In setting up the test data, you could also run into the problem of the data set getting invalidated due to system changes. Often, finding a solution that fixes all your problems is impossible. If the changes that might take place in the external systems that you’re using aren’t happening very frequently, then a good choice would be to use a reproducible approach when generating valid test data.

If you’re creating your own data sets using the own application and then using the same data for further testing, you’re going to run into problems. Doing this means assuming that the SuT will be able to create everything required, which is rather fallacious in most cases. Also, the tests stand to become unstable and slow if and when large data sets are used. When those tests fail, there is no way to know if other parts of the application are working as they should. These and more are the dangers of not using a reproducible approach when creating test data. It might be a little bit of an effort, but not having the test delete the data and ending up with dead system data is, in our humble opinion, worth every bit of it.

The second problem was accessing the CI server.

“Oftentimes, developers responsible for performing configuration tasks don’t have full access to the system. Access can also be hampered if the same server is over-burdened by too many projects, slowing it down and even negatively impacting other projects on the same server. Selenium-based servers are especially prone to this. Another potential problem one can run into is not being able to access all parts of the system simultaneously.”

This isn’t, unfortunately, a problem that you can do much about. If you’re a small organization, then it’s easier to fix. Communication is key here, as the system guys will be able to help you solve it.  Generally, nagging the tech team until you get access seems to be the most used approach!

The last problem that we covered in the first part of this article was web application testing.

“In these projects, often the test is rendered unstable, and the results vary widely even when the SuT (system under testing) has not been changed from one test to the next. Sometimes, the SuT is based on a web framework that is hard to test. For example, some web frameworks change the id-values of HTML elements in every instance of someone accessing a page – variables like these will affect your test results. Frameworks like AJAX are also hard to test.”

The solution here usually depends on the environment the project is based on. If you really want to avoid as many problems as possible, it’s best to plan from the ground up and choose your software environment keeping test automation in mind from the seed stage level.

When looking for solutions to this, people often overlook cutting down on the number of GUI-dependent tests. It’s not as easy to get to the service layer directly, and oftentimes the GUI is reused in this regard. However, implementing specific tests with service-layer access works out much better in the long run because you end up with faster, more stable tests. This doesn’t preclude the need or the option for GUI-based testing. However, try and separate the service-layer-based tests from the GUI-based tests as much as possible.

Finally, we want to bring up another problem that you’ll likely run into – the complexity of designing a good test.  This is extremely underestimated in most cases and arguably leads to the most amount of problems. Quoting Coldplay, “Nobody said it was easy, no one ever said it would be so hard.”

You need to write tests that can be easily maintained when the number of tests increase and making them inaccessible to changes in the SuT as far as possible. It will be near impossible if you have a disorganized and not-well-planned approach to both writing and maintenance. The only solution is to have them planned as part of the project, and not added on later as a minor task that needs to be completed.

Test automation should be part and parcel of every software development plan that comes up. With the popularity of test automation rising every day, solutions like CloudQA should be explored and incorporated during the skeleton planning stages of software development. It is an extremely integral part of software development, not just a fad that is catching on.

If you want to learn more about being more productive with Test Automation, contact us at CloudQA (info@cloudqa.io)