Make Tests, Not Tasks
There’s an odd trend in AQA currently: Automating tasks. Not tests, tasks. The concept is the test automation tools have the ability to programmatically ‘do things’ in the application, thus why not have it do some tedious manual tasks? Sure, it’s not “testing” but we’re already interacting with this form anyway, why not just do this thing while we’re there?
Oh, we need a dozen users? Lets create an automation script that go through and generates random users. We need to get all these accounts are in this specific state? An automation script can iterate through that. We need to run this report every couple days? Lets have automation click that button.
This is a misuse of AQA time and resources, and it won't result in the time savings you think it will.
Realistically all you’re doing is shifting the same task to another person. Rather than spending 5 person-hours/month doing a task, you’re instead going to spend 5 person-hours/month doing a task - but under a different department.
Sure, you think running a script to do a thing will save you time, but this disregards how long it takes to build the script and the maintenance costs of keeping it running. It may take 60 minutes every week to setup an initial data set for manual testing. Running a script to do this will take the same amount of time (assuming worst-case front-end automation), but you then factor in the days spent building and debugging, and the ongoing maintenance cost of keeping it running - plus when (not if) the script fails, you’ll end up doing it manually anyway.
Specialized Tools for Specialized Jobs
AQA frameworks are not designed for tasks. They are not what I would consider ‘stable’. AQA frameworks often overload and subvert the very system they are built in - just look at the runtime stack of TestNG. They are built to automate tests - often in a very specific way. They are not built to automate tasks - that is outside their design. Using them to automate a task means subverting their already subverted design and you’re just asking for headaches built upon mounds of bugs in your code.
Best case you’ll build the tasks such that they exist outside your tests as some wholly separate entity - meaning you’ll basically have to write a whole new framework and mode of action around handling tasks - which begs the question why are you not using some other non-AQA framework to start with.
Finding the Root Problem
Finally, you’re covering up the root problem. If the only way to alter data in your system is some tedious process that even you don't want to do, think about your customers frustration! The real solution here is to redesign your system to allow more easy access/creation/deletion of whatever it is you want to automate. Your users will love you, your devs will love you (and have probably been asking for this anyway), and your AQA will love you.
If there are tasks in your system you can't design around that you do feel the need to automate, don't turn to AQA - turn to Automation. There is an entire specialty called ‘Automation Engineer’ (note: no ‘test’ in the title) that do exactly this, and they are far better at it then your AQA.