Hi Penny! This is such a great question and one that lots of teams struggle with. They want automation but have underestimated the time and effort that must be dedicated towards it.
Make no mistake, test automation is a software development project in and of itself. It takes a considerable amount of time and skill to do it. If you treat it as a side task that people only contribute to whenever they have time, it will fail.
I recommend that leadership take this course. If they are too busy to do so ( ), might I suggest that you put together a short presentation and map some of the points to issues you see in-house. Let them know youāve done the research and here are the findingsā¦unfortunately, sometimes leadership listens to outside voices more than their own people.
Visual testing has truly changed the way I write tests. I realized how much I wasnāt covering before, even when I thought I was being thorough. It also requires me to write less code which helps me move faster.
You should definitely try it out. But first, focus on getting the time needed from your leadership for automation in general
As much as we as an industry pretend that there arenāt leadership teams demanding that we automate everything, this is simply not the case in real life.
Iām very glad that you showed the manager my formula for figuring out what to automate! It sounds like now you need to build a case for why automating everything is a really bad idea. Stress these points:
Automated tests have to be maintained! They are running against a moving target, meaning when your app changes, your automated tests will need to be updated. This eats up so much time!
The more tests you have automated, the longer they take to run. Even if you run them in parallel, this is still something to consider. One of the goals for test automation is to gain fast feedback. If it takes forever for all of these tests to run, then you lose that value.
Low value automated tests are nothing but noise. Ask yourself, if a particular test fails, do you really want to stop a deployment? If the answer is no, then why would you bother with automated it?
Put these points together in a way to allow your manager to see reason. Good luck!
Hi Jim! Yes there are open source options for visual testing. Joe Colantonio reviewed several of them. Many are not as sophisticated as Applitools, which also has a free account tier, but definitely check them all out to see which one best meets your needs.
Oooh good question! While there are no Page Objects, you should still abstract out useful/repetitive things like any boilerplate code to make the calls and parse the responses. Mark Winteringham has an API framework on github that you can review.
I used to discourage the use of Record and Playback tools because Iāve been burned by them in the past. In fact, I wrote an open letter to codeless automation tool vendors outlining what we need to do proper test automation! Many responded and accepted the challenge to address our needs. I like what Iām seeing so far. However, Iāll be honest, I am not 100% sure how well codeless suites will scale. When thereās hundreds or thousands of these tests, how manageable is it? Iām not sure.
Iām glad that youāre modifying the exported code to make yours more maintainable and robust! I actually have a talk on refactoring bad automation code that you and others may want to check out. Itās probably very relatable to the code that you receive from the tool exports.
Check out my talk on refactoring test code. But generally, Iād put the CustomWebDriver class and any other classes that deal with the āhowā of interacting with the app in src/main/java
Yes, try Rest-Assured if youāre using Java. Iāve used this for API testing at scale and love it! Also, check out ApprovalTests to make the verifications much simpler.
Iāve worked on projects using each of these setups:
One repo for all projects. This worked out pretty well actually. We were really good and separating out the packages for each project and clearly identifying the common code. In fact, the top level package of the shared code was called common lol. So if anyone wanted to change anything here, the people from the other projects would need to be involved in the discussion and agree.
Then at another company, I used the second approach you mentioned. We had the common code as its own project, and then every project had its own repo and imported in the common code. This worked ok but I found it annoying any time I had to write tests and needed to add simple things to the common repo as well. It required me checking out 2 code bases. I much preferred the first approach. The communication was key.
Have a look at WinAppDriver for desktop based apps.
For ML, do you mean ML tools or actually testing ML? For ML tools, there are a few such as Appliools, Test.ai, Appsurify, etc. For actually testing AI, check out my experience report on test automation for machine learning.
Thereās also a community of testers who want to learn more about AI called AISTA.
To be honest with you, it doesnāt sound like an environment thatās ready for test automation just yet. Review my course on Setting a Foundation for Successful Test Automation to identify how to get there.
), might I suggest that you put together a short presentation and map some of the points to issues you see in-house. Let them know youāve done the research and here are the findingsā¦unfortunately, sometimes leadership listens to outside voices more than their own people.