Power Hour - Software Testing Automation

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.

I talk about this at length in my course, Setting a Foundation for Successful Test Automation, which I’m sure you’ve already taken. A notable quote from the course:

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 ( :roll_eyes:), 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.

1 Like

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 :stuck_out_tongue_winking_eye:

1 Like

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:

  1. 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!

  2. 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.

  3. 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!

2 Likes

Check out my video on answers to technical interview questions for test automation.

Review my free course, Setting a Foundation for Successful Test Automation, where I cover:

  • how to develop a test automation strategy that meets your business needs
  • how to cultivate a culture within your organization that is conducive to the success of your test automation initiative
  • techniques that application developers can employ to support test automation
  • how to choose the right tools for your test automation initiative
  • early considerations that should be made to better prepare you for the future of your test automation project
  • how to optimize and scale your automation project for your business needs
  • how to quantify the return on your investment and share the value of your test automation with your organization
1 Like

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.

1 Like

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

1 Like

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.

2 Likes

Check out my video on refactoring automation code. I talk a lot about how the code should be architected.

I’ve worked on projects using each of these setups:

  1. 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.

  2. 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.

I haven’t done much with this, sorry. Greg Sypolt who I trust, has written a post about it though. https://saucelabs.com/blog/the-challenges-and-benefits-of-model-based-testing

1 Like

Oooh, your priorities change! lol. I recommend reading Jerry Weinberg’s book Becoming a Technical Leader

Good luck!

1 Like

Amber Race has a great free course on API automation

There are also mobile and API courses on the Dojo that would be very helpful for you:

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.

Ok folks, that’s my time! I think I answered all of your questions. Hope it’s been helpful. Happy automating!

3 Likes

Thank you for sharing your thoughts Angie!

1 Like

Thanks for answering my question. Is there a recorded online book? It’s ages since i read a hard copy.
Regards

Stella

Den tis 30 juli 2019 21:14Angie via The Club ministryoftesting@discoursemail.com skrev: