While it isn't possible to create generic calculations for things like test execution and test script creation without knowing something about the context of the situation, there are general practices you can follow that will help you estimate test steps. Test experts Karen N. Johnson and Mike Kelly provide advice to a listener from their recent webcast, "How to plan your software tests."
We don't currently know of any way to create generic calculations for things like test execution and test script creation without knowing something about the context of the situation. There are just too many factors that can influence calculations like those for us to be able to come up with anything reasonable.
If your project team has worked together before and you can look at your test execution velocity for past projects, you should have some idea of how fast your team can execute if the work is similar in form and scope.
If this is your first time working together as a team, or if the work is significantly different, you may just need to set high-level execution goals for each round of testing and adjust your estimates as the project unfolds. To better make the adjustments, create a burn-down chart as your project progresses measuring how fast your team executes their tests. You may also find it helpful to track downtime (time where you're team can't test). Those two measures can be helpful in correcting any early estimates you made based on the goals you set.
You might also find that depending on how buggy the first software releases are, the speed of test execution will be impacted. The more defects being found and reported, the slower the testing will proceed – which is one reason speed of execution might not be a good measure of project progression. You might find that adding the number of defects reported is just as valuable of a measurement as the number of test cases executed.
Determining when to include automation depends on the type of automation your team will be doing. Depending on the goals of the automation, you may start writing it before your manual test phase begins. It may also depend on who the resources are and what other work they have on their plate. If the automation effort is significant, you may want to plan it out separately, noting dependencies with other test project work as you go.
