1) Identify the tests, which call for extensive involvement of the testing engineers or the ones that would be sparingly run. These tests should be certainly dropped from the list of tests for automation.
2) Identify the application paths with high frequency of use during full-scale production run of the application. Automated testing shall be best for evaluating the performance of such application paths. These can include activities with higher volume with larger probability of failure of the software such as billing / invoicing or other customer records etc.
3) Identify the special processes having critical importance for the business like processing of sales order etc. Such strategically important activities must be identified for automated testing.
4) Identify the events requiring repetitive testing, which would be ideal for automated testing.
5) Identify the applications having longer life span during production, since automation of such applications shall provide maximum benefits.
6) Try to avoid the dynamic screens. Although we can automate them but the script tends to become too complex.
7) Try to avoid screens involving dynamic creation of objects.
8) Try to avoid business scenarios involving use of complex hardware.
9) Try to avoid scenarios, which call for complex coding for automation. Our endeavor should be to have less complex script, which would eventually be easily maintainable.
10) Try to prove the scenario with tables having provision of identifying every row by a unique number. Script complexity should be reduced while handling enterprise wide applications like price list tables etc. A complex script tends to take more time for execution especially when the table contains large number of rows for picking up the data.
Many More articles on Test Automation Frameworks