Automating poorly defined manual tests won't reduce the manual effort and will probably result in more time overall spent on testing. The manual tests must therefore be well-defined if they are to serve as the basis for the automated tests. The people writing automated scripts who treat test automation as programming ought to follow good programming practices such as establishing coding conventions, using source control, conducting code reviews of the test scripts, and testing the automated tests before relying on their results. Deciding which tests to automate first is like deciding which new feature to implement first in a software project. It depends on who is available to automate the tests, what the goals of the project are, and which tests will have the biggest impact if automated.
Smoke tests are useful after a build to ensure that nothing obvious has broken.
Because the smoke test usually involves simple tests, it may seem simple to automate. Ironically, smoke tests are often more difficult to automate because of the breadth of the test. The more parts of the software involved in the test, the more complex the test automation becomes, and the longer it takes to develop. Therefore, if you need to see quick results from automated testing, the smoke test is probably not the best place to start. If your organization is new to automated testing, start with a focused, well-defined series of tests for a specific feature.