TestBash SF 2019 Live Blog: From Rags to Riches: Turning Your Test Automation Into a Cinderella Story

Ever wonder if the efforts that you put into your test automation will actually yield any meaningful results? Does it seem like the process just keeps getting more and more tedious? I think any and every tester who has worked on an automation project has felt this way. It’s like Cinderella just toiling away for her stepmother and stepsisters. What? I relate to the title. Don’t judge ;).

With the growth of CI/CD pipeline arrangements, the older attitude of QA tests being a side project is quickly being replaced with automated tests being essential and prominent in the product cycle. With that new notoriety, there is greater scrutiny on what it is that testers are writing for automation. If the team is lucky or has given some forethought to the problem, the team has hired people with development skills to write the test automation. If they haven’t and they are expecting us to do so without any special background or training, that’s a large ask but not impossible.

One of the issues that will come into play will be that test data will grow and interacting with it will become progressively more challenging. Additionally, there are often special requirements that will require your tests to reply to dependencies. This is not ideal but it is common, so while it is helpful to have all tests as granular as possible, there are going to be circumstances where avoiding duplicate code will come down to importing rich test data to interact with.

As tests grow and the items tested become ore spread out, it is possible that your serial test runs will become too long to be practical. In many environments, there are benefits to parallelization that can help save a lot of time but it requires approaching tests in as granular a method as possible. While in many cases prerequisites need to be applied, if there is a way to minimize relying on them, Niranjani encourages you to do so (me too :slight_smile: ).

One of the ways to make sure that you have as clean an interaction as possible with your testing is to make sure that your locators are easy to find and have easy to use names. this is a personal recommendation and not necessarily what Niranjani is saying but you can use something like Katalon recorder and just walk through interactions with the system. I consider this helpful because Katalon will go to the deepest level necessary to identify an element. If you come back with deep and ugly xPath links, that’s a good element to take a closer look at and determine why an ID or class value isn’t present.

With a little bit of help and effort, there’s a lot of cool things that our teams can do with automation. We need not be the stepsister any longer :).