If you answer yes to any of these questions, then your test should be seriously considered for automation.
Can the test sequence of actions be defined?
Is it useful to repeat the sequence of actions many times? Examples of this would be Acceptance tests, Compatibility tests, Performance tests, and regression tests.
Is it possible to automate the sequence of actions?
This may determine that automation is not suitable for this sequence of actions.
Is it possible to “semi-automate” a test?
Automating portions of a test can speed up test execution time.
Is the behavior of the software under test the same with automation as without?
This is an important concern for performance testing.
Are you testing non-UI aspects of the program?
Almost all non-UI functions can and should be automated tests.
Do you need to run the same tests on multiple hardware configurations?
Run ad hoc tests (Note: Ideally every bug should have an associated test case. Ad hoc tests are best done manually. You should try to imagine yourself in real world situations and use your software as your customer would. As bugs are found during ad hoc testing, new test cases should be created so that they can be reproduced easily and so that regression tests can be performed when you get to the Zero Bug Build phase.) An ad hoc test is a test that is performed manually where the tester attempts to simulate real world use of the software product. It is when running ad hoc testing that the most bugs will be found. It should be stressed that automation cannot ever be a substitute for manual testing.