Don’t put cart before the horse.

It is essential to have a test strategy first, and then automation, otherwise you may end up with a complex code testing simple code.

It is essential to have a test strategy first, on how different parts of the system will be tested, how different parts will be automated in phase approached, and what tools will be used.

Let me share a real world experience.
The Problem
Requirement was to test a web-service (A Merchant Boarding Service for one of our core products in payment industry) which had around 200 input fields. It is like a gateway where some fields goes to one end point (processor) some other goes to another endpoint like one to many and for EACH field MINIMUM of 3 tests required for test coverage.

Problem was to test EACH combination = it was a 3 ^ 200 combination which is difficult to do, very time consuming even with automated testing, no matter how good your test framework or test tool is.

The Solution
a) Equivalence partitioning to the rescue.
One of the primary goals of testing is to find the optimum number of tests in which maximum coverage can be achieved. We planned a Test Strategy and reduced the tests for effective testing of the web-service.

Strategy – To Test only for Mandatory fields
Action taken –

  1. We figured out all the Mandatory Fields. (Around 100 Mandatory fields).
  2. Then, applied Testing Technique – Equivalence Partitions OR Equivalence Classes.
    As we all know, in this technique, we divide the set of inputs into partitions which are equivalent (i.e. will be treated in the same way by the system) and we test only one condition from each partition.
    – If one condition in a partition works, we assume all of the conditions in that partition will work, and so there is little point in testing any of these others.

– Similarly, if one of the conditions in a partition does not work, then we assume that none of the conditions in that partition will work so again there is little point in testing any more in that partition.
In our case, out of a total of 200 fields, there were 100 mandatory fields, and 100 non-mandatory. The good thing was that the fields were independent of each other.

Step 1:  We took one field and assumed all combinations of the other fields as one equivalence class (as the fields were independent), the variation in value of each field need not to be tested with all other combinations of other fields. So, testing all the values of one field with just one valid combination of the other fields.
Test values were
1) Null
2) Valid
3) One above the maximum limit

Step 1 generates about 300 tests as each type would have its own tests.
Next step was to include Non-Mandatory fields-

Step 2:
Again as they were independent, we tested only one non-mandatory field at a time with a valid combination of mandatory fields and did not test the combination of all non-mandatory fields.

Tested one input with all non-mandatory fields in.
Step 2 generates about 200 – 300 test cases as each type would have its own test cases.

In total we were able to generate about 500 – 600 tests as each type would have its own test case.

To conclude, once the Test Strategy got implemented, test conditions got ready. By using a web service automation tool ”SOAP UI Pro” we automated all the tests and run the whole test suite in one go which took very less time to generate the test report.

Overall, 500 – 600 tests were quite reasonably effective to test the overall application in a timely manner.

*Web Service Automation Tool used – SOAP UI Pro is an open source web service testing tool for service-oriented architectures (SOA).

https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Automation-Strategy.jpg?fit=490%2C276&ssl=1https://i0.wp.com/www.testingcircus.com/wp-content/uploads/Automation-Strategy.jpg?resize=150%2C138&ssl=1Sarika GroverArticlesAutomation,Test StrategyDon’t put cart before the horse. It is essential to have a test strategy first, and then automation, otherwise you may end up with a complex code testing simple code. It is essential to have a test strategy first, on how different parts of the system will be tested, how...