6

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?

  • What stops u from doing that ? – PDHide Feb 19 at 18:01
  • It's bec of the super long test case. I want to make sure I'm doing it the right way. – Venmar Feb 19 at 18:48
  • your approach looks fine , why do you want to do anything else ? . The main intension of manual test case is to ensure it could be executed by anyone who reads it .and repeat steps 1 to 5 is easily understandable and makes the test cases shorter – PDHide Feb 19 at 18:55
  • Actually our current approach is to write the test steps one by one and not the "repeat phrase". – Venmar Feb 19 at 19:02
  • 1
    community.atlassian.com/t5/Marketplace-Apps-Integrations/… according to this , u can give a link to the step – PDHide Feb 19 at 19:46
6
  • 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.

|improve this 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.

|improve this answer|||||
2

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.

|improve this answer|||||
0

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....
|improve this answer|||||
0

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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.