Best Practice is whatever is best for you. If it is only a manual test, then hard code it for ease of testing. If you use the same test repeatedly for many iterations then it might be better to parameterize the data. You could also have a list of data and insert it whenever you need to. All of these are Best Practice if they work for you. Make it easy on yourself and use the one you are comfortable with.
If the test is automated, then parameterization wins, hands down!
Success is the ability to go from one failure to another with no loss of enthusiasm.
~ Winston Churchill ~
Several scenarios - this is MY practice, not necessarily Best Practice [img]images/icons/smile.gif[/img]
1. Test data is known in advance and is same every time.
In this case, I indicate the explicit data either in a Setup step or within the test step where the data will be used.
2. Test data is known in advance but can change (or be reselected) each cycle.
In this case, I will have a Setup step, but instead of the explicit data, I will document how-to get the data needed. Often this is a query or a list of options to pick from. The expectation then is that the tester will document the explicit data used within the Actuals.
3. Test data is not known in advance.
In this case, I state the need for data within the test step description and the explicit data in Actual. This is only for relevant data. I don't document anything that doesn't further the test or relate to what is being verified by the test.
4. Test data can be whatever.
In this case, the test step description will say "pick one ..." or similar. Actual doesn't have to indicate anything, as it's not relevant to success/failure of the test case.