I am looking to find out what the term Automation First means to different people.
Where a company has this as one of their main principles/focuses of testing, does this result in you spending majority of your time on automated testing - writing, updating, reviewing, debugging, fixing etc OR do you balance your time equally with other quality engineering tasks?
If you have a good balance - please describe what that looks like and what it includes you doing.
If you focus the majority of your time working on automated tests, is there another role/person responsible for other aspects of testing and quality?
Not specific to company I worked for, just my personal take on this:
One way I would think of automation first is start a project (new feature, etc.) with (test) automation in mind from the beginning (or as early as possible in development cycle). For example include QA/automation assessment/review for product feature / project during the phases of UX mockup (review/discussions), product/project requirements review/discussions. From those review sessions or discussions, or reviewing the documents/mockups, the automation staff can prep for what (tests) to automate and how to approach the automation (e.g. how to design the page objects and test libraries, etc. not the automated test cases themselves - that is later step or for other team members to do). You don’t need a working UI to start automation work on page objects and test library code - skeleton code can be put in place to fill in details (like element locators) when the rest are ready later on. Such a process can improve automation code design and speed up the automation process.
A few years ago, I worked on a project where the UI was developed after the functionality. I developed tests for the API using Postman and then paired with a developer to create an API testing framework. The tests ran as part of CI. I think that was “automation first”.
During my 35 ys in SW business, testing as a technician or management always with an eye on testing this has been a litte back and forth. In the days of CLI’s and regexps to evaluate results it was pretty straightforward to automate(Primarily large telecom systems), and it was like the way the test instruction was made.
Then with windows, web and stuff things got more messy and automation was either neglected or made a religion, spending enormous money on doing it.
With Chatgpt its a nobrainer, but still, since the days of web applications the emphasis has been more on manual tests than back in the days.
I once worked for a company, where the developers used Test Driven Development. While extending the program, automated tests were added at a low level. They even peer reviewed these tests.
Overall, the quality of the software was good. I asked, what my role as a tester was in this company. “We need some one who knows about exploratory testing.”
My ideal view of automation first is, that automation is used in early phases of software development. This leaves more time for complicated testing.
Automation first, to me, is a bit of a buzzword that goes alongside others like,
“Secure by design”, or “Less is more”, all lofty goals. But when applied with experience, automation first is the means to the end, not the end itself.
I suspect that most automation coders have eventually seen the value in using the “is it automatable” question to decide on whether an app is architected right, by being architected for ease of testing. Basically this implies that the product is open for inspection at the right points, and thus probably also open for extending too. And by being testable, apps are also decomposable or interchangeable in the longer term. So, using automation not to test the functionality, but to test the architecture, is super valuable.