If you could estimate how much of your testing effort involves test automation, what would you estimate it as?
Bonus points for added commentary or reason on why. 
- < 25%
- 25-50%
- 50-75%
- 75-100%
0
voters
2 Likes
Hey Rosie,
I’d say about half to three-quarters of our testing is done using Cypress automation. We use it where it works best like on Regression, Visual testing. We focus our human testing on things that need more thought/creativity & of course on the new features introduced/non-automatable stuff. This helps us deliver faster & make sure everything is top-notch.
3 Likes
Right now, nothing.
The software I mostly work with will be decommissioned within a month or two, so the automation has been shut down. The only testing I’m doing is for tools to help the transition, and that’s rather limited in scope.
I used to have a basic regression suite that covered essential function and which I was working on getting fully stable before starting expansion. I also have/had a number of semi-automated shortcuts I used for data validation work.
3 Likes
For me this varies from project to project.
I view my primary role as a tester with a focus on the things the team may naturally miss, its my strongest area as a tester with an emphasis on discovery, exploration, experimentation and investigation of risks to both evaluate the product and find things that could impact the quality of the product.
For me this tends to be my highest value contribution so generally want to be spending most of my time in this highest value for me area.
Its fast and curious and I’m comfortable jumping into and out of projects at short notice doing short bursts of test sessions. As such is also my fastest testing approach and covers a broad range of risks which I realise goes against what some people argue as being slow and using automation to go faster, its not the case with this focus.
I also highly value automation and on some projects that is also at times my primary role even if I view it as a secondary skill for me. One key difference for me related to these percentages is that when I am working on automation it takes more focus and jumping in and out is not ideal so when this is my focus role I prefer it to be up at the 80% focus.
Given the choice though I’d prefer about 80 percent of my projects were the former, highest value contribution but the reality is driven by project needs and often there remains a perception sometimes from managers and often from customers that the automation is of higher value so I end up on my secondary skill area quite a lot.
1 Like
I think nowadays automation has become like “oh i have to automate stuff in testing to showcase the clients that we are doing “automation” in the project” - this is my personal experience can be different for others.
So automation should be done organically, by doing a joint exercise with project management, development and testing team to understand “is automation really neccessary for our project?” keeping in mind the longevity of the project, the amount of changes that might be done to the application and any other relevant factors.
Based on that automation should start after one successful release when the system is stable( may be I am sounding old fashioned here - but that would be my logical step to save time,effort and ensure the reusability - which are key for automation)
So for me automation should always be AFTER manual testing - when the testing team is very clearly aware of their application and then it can start to range from 25% to even 100 %
3 Likes
Context is really King. It entirely depends on how much your job can benefit from automating, and also on what you class as automated test.
You might for example write a CRON job to start your app 4 times a day and verify that the app logs successfully into some or other cloud back end, as a simple service uptime and performance test. That, is still automation. Even a script that downloads the latest packages from a repository and starts an app, is automation, even if you still start the script manually. It’s always tempting to exclude things that are not in your CI/CD as not being automated. But that said, some things are not valuable to, nor worth automating. And for me that’s why I spend anywhere from 1/4 to 1/2 of my day doing some kind of manual testing, but with the help of some automations where possible to speed it all up.
Sure we all know that automating a repetitive task can help reduce errors, so managers will always be super keen on automation as a way of eventually replacing you (bwah ha ha). But it’s good to have in your head ways to optimise your time, and find ways to remove drudgery but instead to deliver value early as possible in anything we do, not just testing.
2 Likes
I try to get everything automated that we can but with time constraints and deadlines some things are stuck being manual especially if they involve new tech or security features that are harder to automate. I have had features that trigger on bluetooth connections or rely on coordinating multiple devices to work together which can probably be automated but it’s hard to get the time investment to build it up.
2 Likes
With you @sean_t . Far too much time I have wasted automating thing that not been auto-mate-able. BUT in that itself sometimes we learn more about the product implementation than we wanted to. For me learning too much about the implementation means I’m probably going down that same road of automating the impossible.