In addition to the existing answers, another factor in ROI is how often the test cases need to be run.
If automating the test cases will take you 500 hours, they need to be run once a year, and it takes an hour to run each test case manually, by the time the automation has "earned back" the initial development time, the software is likely to be obsolete.
If, on the other hand, you need to run the same test cases three times a day (after each build), then it's worth doing, because you will be into positive ROI within a year.
Other things you should consider:
- Number of moving parts - how many different aspects of the software does your test case need to interact with? If you're checking straight database input, your test case will be simpler than if there is data manipulation downstream of the data entry. Similarly, entering data is a lot simpler than performing tax calculations.
- Preconditions - the more things that need to be in place for your test case to run, the more complex your automation or framework needs to be.
- Maturity of framework - I've worked in an environment where the framework was mature enough that adding a test case for a new feature could be as simple as one new function, one line of code to call that function, and half-a-dozen rows of data added to the run files and baselines. Without that, you're looking at a much longer time to automate and likely more repeated code.
- Postcondition validations - the more changes the test case makes, the more validations you will need to perform on completion of the test case. You may have software that has a single button-click action to kick off a complex process with dozens of validations needed. That will take more time to automate.
- Existing automation - it's often faster and easier to add to existing automation than to build from scratch. If you can make use of existing test harnesses, you can call and possibly expand on already built helper functions, which reduces your automation time.
Don't forget to include time to test and deploy your automation. In my experience building it is the fastest part. Testing it to ensure it's stable and does not generate false positives or false negatives and getting it deployed to run on a regular basis takes a lot longer.