While parameterization is a great tool to promote modularity and reusability, exercise caution deciding what data inputs should really be parameterized.
Action: Populate Funds Transfer Information
Consider the example below. This Action populates information for transferring funds on QBank. You provide following information in the logic.
- Source Account
- Target Account to transfer funds to
- Amount of transfer
- Memo to indicate the reason for transfer
![]() |
You may want to develop a Scenario and write multiple test cases covering various permutations such as different source and target accounts, different amount of funds etc. This can be facilitated by utilizing parameters for appropriate fields.
![]() |
Memo field - To parameterize or not to parameterize?
Consider the Memo field. While you might be tempted to just parameterize "every" data element in the Action, think again. Do you ever need to test Funds Transfer scenario with different values for Memo field? Does it really matter for your testing? If the answer is "NO", then it is better left as a literal data value in the action logic. Memo field can be hard coded in the action logic.
Over-parameterization leads to additional effort while creating test cases, as well as for ongoing maintenance. Remember an Action parameter needs to be supplied with a value in every test case you are building.
Be choosy and avoid parameterizing those inputs which do not really need variation at test case level.
Best Practice tip: In some cases, you may not readily have an idea of data variation requirements for a particular field in your action logic. When in doubt, you can always start without parameters, and introduce parameter if the need arises in the future.
Comments
0 comments
Please sign in to leave a comment.