How to Choose an Automation Tool

I hope everyone is feeling good and before anything, I want to thank you all so much for being here today. I am Lia, and I'm going to show you a process that you can use to choose an automation tool. I am going to do an overall comparison of three frameworks that I think are the best at this moment, and I'm going to talk a little bit about other tools that you can integrate in your automation process.

So a quick insight into who I am. I am a software engineer at Nocare. My main focus is on test automation. And let's dive into this. So this is a three-step process, like all the good ones, of course. But each step will need attention and work. So let's move on and dive into the first phase, that is, analyze.

So analyzing means answering some questions. And the first one is not really a question. It's understand your application. So look at it and be really critical about it. Try to understand what are the weak points, the features that you can break more easily, and try to think of edge cases in the application. So just have an overall picture of the application that you are going to test and make a list. Make a list of the tests that you want or need to do. And at this moment, it will be a good idea to talk with the development team and try to understand what are the coverage of unit testing that they have, if they have, and knowing their coverage you can avoid duplication of work by your side.

And if they don't have unit testing, it's a really good opportunity to meet with them and with the management team and think of a way to do a coverage since the develop until the production. And this means that have automation tests in all parts of the process. So the development team will have unit testing and you can have end-to-end security, accessibility, whatever types you think are more suitable for you. So having this, you will need to ask yourself if you want to call or not, and ask your team if they feel comfortable doing this. And in which language do they feel they will be more comfortable working. So having this, you will end up with a list more or less like this in what you have, the development team has unit testing or not, what type of tests that you are going to do, and you will have a language that you feel more comfortable working with, if you choose to code.

So if you do not want to code, that is not a problem because here we are inclusive and we have options for everyone. And if you don't want to code, I will give you two options that I know, and be aware that I believe there are a lot more options for you, so if this option that I am going to give you does not suit your or accommodates your needs, just search for it. And we are kind of entering here in the next part that is search, but I am going to previously tell you about testing and perfecto, and this two are similar in the things that they can do, but just in a quick explanation, this two record your manual testing, and for each action that you do in the browser they make a block. And when you finish you will have your test case and your automation that is a group of blocks and just like in coding you can create a group of blocks that you can reuse between tests, you can create folders to run in each deployment, you have a full group of options that you can have just like in the coding. So if you don't want to code, just take a look at this tool and dive into this because I'm sure that you will have options for you as well. So if you do want to code, I'm going to do some comparison between Selenium, Cypress and Playwrights.

And this is more or less what you are going to do in the search part with the frameworks that you choose to compare. And for Selenium, starting with Selenium. Selenium is a framework that is here for a long time, and this means that Selenium has a large community supporting it. And you will not be alone working because you will have a Stack Overflow to help you with a large group of people that can help you.

And overall, it is a really good framework, but it will need third parties to work with certain types of tests. So Selenium automates the browser. So it simulates a real browser interaction, meaning that if you need to do API testing, you will need to integrate with a third party to have the API testing. And since Selenium does not support by itself parallel testing, you will need to integrate with Selenium Grid and a cross-browser tool to make it work. And for me, the most downsides for Selenium is it does not have an in-built report tool, so you will need to have a third party like X-Ray or Test Rail, that I'm going to talk a little bit in the end, to support this. And it does not support iframes or popups. So, if your application depends on third party iframes, Selenium is going to be a really not go-to framework. But, if this is something that you can live without, Selenium is really really good to work with a large set of tests, but, like I told you, it will need third parties integration for some type of test, and this will make it more difficult to work in the beginning. I'm not saying that it's impossible because nothing is impossible, but, you will need to have some experience and some expertise to understand what are the workarounds that you need to do here, okay.

So, it is a good tool. If you want something easier to start with, let's move on to the other tool and understand what are the differences here. So, with Cypress, Cypress is a all-in-one tool, meaning that you can have the development team doing unit testing and you doing the other types of tests in your site, and have the whole team working with the same framework, and this is cool because you can take it out with each other and try to understand and review code from each other, and it is very complete, it has an in-built report, you don't need to integrate with any third parties here, but the downside is that you only work with JavaScript here and it does not support parallel testing and multitap testing, meaning that if you need to have certain types of configurations that need to be run at the same time, for example, if you want to have a browser with a device and various configurations about this, you will need to run them separately. So, it will be a very huge time running the test case. If you need to have various set of configurations here, various environments running at the same time, you need to consider if Cypress is going to be a good tool for you. But for starters, and for a small medium group of tests, Cypress is really good. It's a very simple tool to work with if you work with javascript, of course. It's a very simple tool to work with and it has a lot of documentation, the community is growing so you will have help for with Stack Overflow for any type of data that you need. But it has its downsides, just like all frameworks that you will encounter here.

Moving on to Playwright, Playwright is a fair new framework. The first time that I heard about it it was here in 2020, if I'm not mistaken, and it is, I think, the most complete of the three. You can have all types of tests running in Playwright, it supports parallel testing so you can have various sets of configurations and environments running at the same time. It has context isolation so you can have tests for new tabs and clicks open in a new tab, it can capture videos and screenshots so you can have visual testing in comparison. But it is a new framework so be aware there are some types of features that are not completely developed so if you look for a framework that is settled, maybe playwright is not the go-to. And since it is a new framework, the community is not very large compared to the other two, so you will need to have some experience with coding and expertise, programming and searching for things because you are going to be a little bit alone in this. You will have the community of playwrights taking doubts, but Stack Overflow is not really filled with questions and answers for how to move with playwrights. So, be aware that you will need to take a lot of time trying to move with playwrights and documentation is a bit confused because since it does a lot of things it's kind of messy to work around with.

But if you want to take the time to work with the framework that does it all for itself, I think it will be very good to work with playwrights. So just in an overall of this tree I think that you need to choose what you feel comfortable with. So have a look at the tree, just play around with each one of them, if you have that time, and choose one that you feel comfortable working with. Because this is something that you're going to work with, like, six hours of your day.

So don't choose one because your friend told you that this is the best or I tell you this is the best. Just choose one that you feel comfortable and that fulfill most of the needs that you have for testing an application.

So, moving on to this, you will end up with a board, or you should end up with a board, more or less like this, where you have the type of test that you need at the right, at the left, I'm sorry, and check and cross or ups and downs of the framework that you are comparing. And just in a side note, each of them has options to work with accessibility tests. The one that I know is AX, that you can integrate with the frameworks, and you can have ApliTools to each one of these three to run visual testing. Have in mind that Cypress and Playwright do this by itself with screenshots and videos, but if you want to have a third party working with this, you can work with ApliTools.

So after this, you will choose, or not, a reporter, and this is going to be a quick comparison because I don't want to go very deep into this, because I think that choosing a reporter is not a decision of the quality team only, it should be a decision of all the product team because everyone should be integrated in the process. But just in a quick comparison, Xray has integration with Jita, TestRail also has integration with Jita, but it's not so obvious that it's there. And Xray, you can create test plans, test execution to integrate with the issues that you have in Jita, this having in mind that you work with Jita. If you don't work with Jita, this is not a very good option for you. But in my opinion, Xray is a more integration tool with Jita and to be visible for everyone in the team what is been testing and what is being doing for the quality team. And TestRail is more on the downside. So if you want a tool that's the quality team will work with separately from every other team I will go with TestRail. And if you want a tool that is more integrated with the process and the product team and the development team I will go with X-Ray.

But moving on to the plan part. That is the important... I will not say the important, but the part that you have to take a little more time to understand how you are going to do this. So the key word here is prioritize. And what I mean by prioritize is choose what tests are you going to do first. And this could be the most painful end to end test that you do manually. And it can be the simpler test that you do just to start with and try to understand if you can work with this framework. So just unite a team and if you are by yourself don't feel sad, just do this. And think about it, really sit down and take a look to what you are going to do and what is going to be the first thing that you are going to do. And parallel to this, do documentation. This is very important because the knowledge cannot be only in your mind, you need to share it with the world, with the team, with the company so that people know what you are testing to be reassured that the application is stable to go to production. And just for you to have some place where you can rely to understand what you did in the past.

Because right now if you are starting, it is very easy to understand what you are doing, but in 6 months, or 1 year from now, I really doubt that you remember what you are thinking when you start the project. So, if you have documentation, it will help you to have place to go, to remember what you are thinking in the beginning, to show to other people what are being tested in the application, and it is good practice.

I know that some development person people really don't wanna take the time to do documentation, but just do it. It is good practice and you are going to thank me in the end, believe me.

And after you have this, after you have the list of test types that you wanna choose and that you choose to do, I'm sorry, the framework that you choose to work with, the author that you think is best for the team to use and the prioritizations of the tests that you are going to implement, now it's time to schedule a meeting with the management team or with the manage. So have this really structure in a way that when you present this, there is no option for them to say no.

So you did all the work, you analyze the product use search for the frameworks, you plan the work that you are going to do in the next month, two months, in the next time. So present this with the certainty that the team and you want to do this and are very sure that this is the best thing for the team and for the product and be confident about it. This is important to tell you because I think that sometimes people just think that this is my opinion but be really confident that this is the best thing to do and you are going to do this. And share that confidence with the management team and be reassured that they will not cut your legs, they will be really really happy to let you do this.

So, have lots of fun working with this, programming or not programming and if you have any doubts just go for it. Thank you so much and see you next time.