The recorded script would still need to have any dynamic data related to session, state, time or business process addressed. It would also need to be parameterized appropriate to the data model for the business process and the user model credentials use. As a rule of thumb, for a skilled individual with Web, you can count on one hour per test step from inception to packaging in a ready to run model. That would include the recording, handling the dynamic items, the data items, the checking for expected results, branching code if the expected results are not met, inclusion of the timing records (transactions), setting state on the transactions, comments related to development and requirements, setting run time settings matched to the load model and QA of the test code. This is happy path assuming you have all of the requirements at hand and no delays due to data. Most common path is 1.5 times this length. If you shortcut the path, "You need to complete these two scripts by lunch...." then you should expect the quality of the test components to suffer. Also, if you have immature tool users you can expect them to take 2-5 times as long to build test code to a comparable level. So, an eight step HTTP test code script would run 8 hours on happy path, 12 hours on most likely path and 24 to 60 hours for an untrained user path. (witness questions online on how to use certain aspects of a tool which are the root of such delays)
