Writing test cases for a test with repetitive test steps

Question

I have a task where I need to test payment through different payment methods (31 methods). What is the best practice in writing test cases with repetitive test steps? Should I just use "Repeat steps 1-5" or it is better to be concise and thorough in writing test cases?

Answer 1

• Data:
  • Use each of the following payment methods: X, Y, Z, ...
• Procedure:
  • ....
  • ....
  • ....

I don't see how any professional tester won't understand that you want to validate with each payment method.

If for any reason the tester to whom you are writing this documentation gets confused, a 30-seconds conversation with you probably will solve any miscommunication.

Answer 2

My answer is going to be very opinion-based (as is your question) but, that is the approach we use. We manage our test via Excel (which completely sucks) and, if test steps are shared between tests we basically say "repeat these steps...". We use this same approach for both manual and automated test cases.

Answer 3

I don't think there's any real benefit from being thorough when writing test cases. For two main reasons:

• you want other testers to use their imagination as well, which rarely happens when people follow written instructions
• it would take you so much time that you could spend better, e.g. exploring the system

Sure, there might be some exceptions, but I wouldn't count your example of payment methods as an exception.

Answer 4

As per my experience in the qa services, the practice 'Repeat steps 1 to X' can be followed while creating test-cases with repetitive steps. The only thing we need to make sure is to provide the test-credentials separately for each test method.

The other approach that can be followed, is to segregate those common steps in one section and that section can be referred to, while testing the payment methods. Please refer to below example

Pre-requisite: Test-credentials in case these are different for each payment method

Bank/Payment Mode linking section:

1. Enter credentials
2. Click Okay
3. Perform common action1
4. Perform common action2

Testcase steps for validating Payment methods:

1. Login into app
2. Select Payment method A and enter credentials
3. Perform steps 1 to 4 from 'Bank Linking Flow' section
4. Confirm the expected result
5. Select Payment method B and enter credentials
6. Perform steps 1 to 4 from 'Bank Linking Flow' section
7. Confirm the expected result
8. Select Payment method C and enter credentials
9. Perform steps 1 to 4 from 'Bank Linking Flow' section
10. Confirm the expected result and SO ON....

Answer 5

We actually have a great solution for this case in PractiTest: 1. Create a test case with the sequence of steps that are going to be repeated; 2. Now you can use this sequence in any other test cases: for example, if you need to enter this sequence after the step “Switch from Payment Method 1 to Payment Method 2”, you just use “Call Steps from another Test” option, and they’re automatically inserted. You can read more about this option here

You mentioned that you’re doing this because you’re testing 31 different methods. I’m not sure the best way to manage it is creating one test case with all the methods as repetitive steps. If one step in Method #8, for example, fails - would you consider the whole test case as Failed? Without referring to other methods that work correctly? The alternative would be to create a generic Test case with steps needed to check, and then create 31 different test scenarios for this test case. The results for each scenario will show you the correct coverage of testing results. This also can be applied in PractiTest. In PractiTest you won’t need to copy/paste the same scenario 31 times: you create one test scenario and then create Permutations for this scenario per each method. It’s actually done with a couple of clicks. You can read here about how to create Test Set (Scenario) Permutations with our tool.

These are two options I can think about, both are relatively easy to implement.