It's tempting to calculate the return on investment of automation based on time alone...i.e def should_we_automate(dev_time, task_time, frequency): if dev_time >= (task_time + frequency): return...
It's tempting to calculate the return on investment of automation based on time alone...i.e
However, I think it isn't necessarily the only cost to consider. Repetitive tasks can deplete your energy. Testing is a creative intellectual enterprise. This is the crux of QA, at least in my humble opinion. Try to automate away any test/task that's rinse and repeat, it'll help maintain your energy and focus in what can be a stressful environment.
Try to also eliminate any test/task that causes frustration/adversely affects your well-being. Are you manually generating artefacts, test reports, updating release tickets? Whatever test/task is not contributing to your well being and is no colossal task to automate, do so.
On a more practical note, regarding tests specifically, you can start with any build verification (smoke)/regression tests you have. Start with those tests that touch the core of whatever it is you're testing. Those tests that if failing would cause a major problem. Scale the test suite concentrically thereafter.
Anything that's closer to verification than testing should potentially be considered a candidate for automation. As I recall, James Bach speaks a fair bit about this. It's important to draw a distinction between verification and testing and to free up your time to focus on the latter.
Hope that helps :)
p.s it's important to also encourage devs to invest in unit testing. If there's not much of a testing culture, have a friendly chat about the benefits. Most people respond to reason :) Once you've got to that point, take a look at Martin Fowler's testing pyramid.
It's tempting to calculate the return on investment of automation based on time alone...i.e
However, I think it isn't necessarily the only cost to consider. Repetitive tasks can deplete your energy. Testing is a creative intellectual enterprise. This is the crux of QA, at least in my humble opinion. Try to automate away any test/task that's rinse and repeat, it'll help maintain your energy and focus in what can be a stressful environment.
Try to also eliminate any test/task that causes frustration/adversely affects your well-being. Are you manually generating artefacts, test reports, updating release tickets? Whatever test/task is not contributing to your well being and is no colossal task to automate, do so.
On a more practical note, regarding tests specifically, you can start with any build verification (smoke)/regression tests you have. Start with those tests that touch the core of whatever it is you're testing. Those tests that if failing would cause a major problem. Scale the test suite concentrically thereafter.
Anything that's closer to verification than testing should potentially be considered a candidate for automation. As I recall, James Bach speaks a fair bit about this. It's important to draw a distinction between verification and testing and to free up your time to focus on the latter.
Hope that helps :)
p.s it's important to also encourage devs to invest in unit testing. If there's not much of a testing culture, have a friendly chat about the benefits. Most people respond to reason :) Once you've got to that point, take a look at Martin Fowler's testing pyramid.