An important consideration of Test Automation journey

What is the most important consideration for your team when starting your test automation journey?

Insights:

How much time it takes to onboard and implement the software solution comes to mind.

My biggest considerations are a) how to most effectively plan what we will include in our automation suite so that we maximize test coverage without the expense of “over kill” coding, and b) how to ensure I maintain a balance of a clean, simple, yet expertly crafted (if I can get there haha!) test suite that is also both maintainable and transferable to other QA members as I down the road will onboard others on the team to assist in automation. I’m also very interested in others’ opinions on how to consistently implement the standard of adding to automation suites on a sprint level. I really struggle with making the time for automation within sprints, and would love to hear how other people balance sprint responsibilities with still maintaining and increasing automation suites.

-- Ashley Stuart

Insights:

Regarding a, I suggest to map the most central flows in your platform (The ones that will break it if they’ll fail), and cover them. Regarding b, frankly - we doesn’t work in sprints (but as Kanban). But implying a standart is indeed a crucial point - especially when growing and working in a big team. In our team we maintain confluence & docs which set tests’ conventions, tips, rules and general info.

-- Tom Shlaim

Insights:

How easy is the tool for non-technical people to develop. When I used Selenium with Watr, you had to know how to write Ruby, simple Gherkin wasn't enough to set up page objects and actions that needed to be defined. Using Cypress had its own issues with not being easy to "record" tests. Generally the developer shouldn't be writing the tests, but the Product Owner or QA Specialist should. They know the product, but not how to code (in general), so forcing them to learn code to test is challenging.

When we used Watr, we did training all the time and hired QA that had coding experience. We held classes and tried to build frameworks. Now, we are just starting with Testim, so we need to find the areas to focus on, but the recorder tool is one of the better ones on the market. So far, it has just been editing in the GUI to remove redundant actions. The software I am currently testing against is mostly a SPA and the page has configurable, dynamic modules (even their placement on the page and their titles can change). We haven't yet pushed Testim to the limit to see how it handles changing one configuration with another.

-- Kevin Devine

Insights:

Generally, we do much more than just looking at a single attribute, and in most cases it's doing fine with changes in the page. But it's really hard to say in advance, as every application is very different.

-- Ilan Tchernowitz

I see automation tools with JS increasing in popularity such as Puppeteer and Cypress. I also see mobile automation growing a lot. AI is becoming huge as well.

-- Nikolay Advolodkin

Last updated