Tips when using a new test automation tool, Where do I start?

OpenMarket – October 1, 2021

by Priscila Arreola

 

In the life of software test engineers, some of us are used to working with a specific test automation tool and suddenly just because you changed to another job or moved to another team, you have the necessity to learn and to understand a new testing tool.

If you are not afraid of changes and like learning new things, this situation sounds exciting and fun. You start taking courses and reading all existing documentation to start learning the new testing tool.

When you think you are ready, you start the funnier part, Coding! So if you are working with an  existing testing framework you check the code, make sure it runs in your local environment, and after that start adding your new test on it.

Sometimes after a few days,  when you feel ready you start adding new tests and when you try to run the test scripts, in the ideal world, everything works, but in the real world several times it doesn’t!.

At this point the fun feeling starts turning into frustration. Then you realize it is not always as smooth and easy as we would like when changing test automation tools. Sometimes we try to just base on an example already done with the new testing tool  but it gets complicated when you are not familiar with it and your head is still thinking the way you used to do it. Eventually in the worst case scenario you’ll get overwhelmed and stop having fun while coding.

So here are some tips that have worked for me when I have to change from one automation tool to another without removing the fun, lowering the frustration and having a happier testing experience:

  • Learn the basics: Take some courses, read and code the exercises so you start getting familiar with the testing tool
  • Start simple: You can probably start with something similar to a hello word, it could be just opening the browser and typing in an input field if you are working with the front end or just trying to create a simple get request if you are working with the back end. Example:
it('Hello world', () => {
   cy.visit('http://google.com')
   cy.get('[name="q"]').type("Hello World")
 })
  • Add more tests but still keep it simple: Once your basic test is working you can start adding more test scripts, and make sure every test runs before adding a new one. So you can easily identify what is wrong with your script in case you have an error or your script fails. At this point I like to still keep some “hard coded” data just to make sure my scripts are designed and coded correctly. Example:
it('Search for Openmarket in google', () => {
   cy.visit('http://google.com')
   cy.get('[name="q"]').type("Openmarket{enter}")
   cy.contains("OpenMarket: SMS").should('be.visible')
})
  • Start adding complexity once simple cases are working: If the scripts are running correctly then I start adding complexity, like removing the hardcoded data and using the data driven design pattern or maybe refactor some code and create functions or commands for actions that are commonly used between the tests. Example:
beforeEach(()=>{
   cy.visit('http://google.com')
})
it('Search for Openmarket in google', () => {
   cy.fixture("searchText.json").then((data) =>{
       cy.get(data).each((search)=>
       { 
           cy.get('[name="q"]').type(search.searchText+"{enter}")
           cy.contains(search.searchResult).should('be.visible')
           cy.go('back')
           cy.get('[alt="Google"]').should('be.visible')
       })   
   })
})
it('Hello world', () => {
   cy.get('[name="q"]').type("Hello World")
})

Simple data file used:

[
   {  
       "searchText":"Openmarket",
       "searchResult": "OpenMarket: SMS"
   },
   {
       "searchText":"Infobip",
       "searchResult": "Infobip Enterprise Solutions"
   },
   {
       "searchText":"omtechblog",
       "searchResult": "omtechblog - DEV Community"
   }
 
]
  • If your test is failing and you cannot see the issue, take a break and get some coffee, maybe you will see after that.
  • Ask for help and don’t get stuck with the issue. When you are working for a long period of time with the same thing, sometimes you get tired and cannot see the problem. On some occasions at the moment I ask the question, I instantly know where my error is.
  • Document your test script, at this point you can be as extensive as you want, you can simply add what the test does, but I prefer adding what the tests do and what data is required and what steps does it follow so I don’t forget what was the intention of every test script. Example:
/*******************************************************************
*  This test checks if a user can use google to search text using the searchText.json data file.
*  First enter the search word and press enter (searchText from data file)
*  Then check the result we are looking for is displayed (searchResults from data file)
*  And finally it checks user can go back to the google.com page
*******************************************************************/
it('Search for Openmarket in google', () => {
   cy.fixture("searchText.json").then((data) =>{
       cy.get(data).each((search)=>
       { 
           cy.get('[name="q"]').type(search.searchText+"{enter}")
           cy.contains(search.searchResult).should('be.visible')
           cy.go('back')
           cy.get('[alt="Google"]').should('be.visible')
       })   
   })
})
  • Make sure you run your test scripts at least 3-5 times getting the same result, this will help you to increase the confidence level when you run them and avoid flaky tests.
  • If you are going to use some code from the web for a specific function, test it separately and make sure that it works with a simple case, so you can identify any errors before adding it to your code.

 

Hopefully at least one of these tips is as useful to you as they have been for me, and next time you have to learn and code with a new testing tool it does not stop the fun experience and the happy testing.

See all tech blog posts

Related Content