Test Case generation using Equivalence Partition [ISTQB Adanced Level Test Analyst]

You are testing a computerized gas pump that allows users to pay using credit cards. Four types of cards are accepted:

• Visa
• Mastercard
• Discover and
• American Express

The pump will reject any other type of card.

1. If given an accepted credit card, the pump validates the card.
2. If the card is valid, the pump is turned on and the customer is told to begin pumping gas.
3. The pump remains on until the transaction ends. The transaction ends when one of the following events occurs:
• Pump handle is returned to pump
• Amount reaches transaction limit for card
• No gas is pumped within two minutes of validation of card
• Emergency shut-off switch is thrown by the station attendant

Assume that a test is consists of a triple set of values.

• card type,
• card validity,
• transaction ending

Design the minimum number of tests needed to cover all the equivalence partitions for each card brand, including both valid and invalid cards of each accepted type, along with covering each equivalence partition for transaction endings.

How many tests do you need?

1. 4 Tests
2. 5 Tests
3. 9 Tests
4. 17 Tests

The correct answer given was 9 Tests

My Question is : What is the reason behind the answer?

My assumption is

• 4 Tests for valid Visa, Mastercard, Discover and American Express.
• 4 Tests for invalid Visa, Mastercard, Discover and American Express.
• 1 Test for any other type of card
• Transaction ending events (Pump handle is returned to pump, Amount reaches transaction limit for card, No gas is pumped within two minutes of validation of card, Emergency shut-off switch is thrown by the station attendant) will be tested with the above 9 Test Cases.

Is my assumption correct? or is there any other school of thought that should be exercised when it comes to questions like this?

Thanks

PS : Those who are interested can read the original question here : http://m.softwaretestinggenius.com/?page=details&url=istqb-advanced-level-test-analyst-and-technical-test-analyst-exam-sample-paper-q-111-to-120

• so u dont have any TC for "transaction ending" test? Commented Apr 1, 2017 at 16:10
• We can test Transaction ending with other test cases right? Commented Apr 3, 2017 at 1:02

Here specific combinatorial testing is requested for the card type cross the card-validity. For an "invalid card type", card validity is irrelevant (so only one test case). The 4 transaction endings are not tested in a combinatorial manner, so covered with the 4 valid card-type test cases. I hope, my thoughts and the table are correct and help.

There are 3 variables involved in this flow which are:

Card type, with 4 possible values

1. Visa,
2. Mastercard,
3. Discover, and
4. American Express

Card validity, with 2 possible values

1. Valid, and
2. Invalid

Transaction ending, with 4 possible values

1. Pump handle is returned to pump
2. Amount reaches transaction limit for card
3. No gas is pumped within two minutes of validation of card
4. Emergency shut-off switch is thrown by the station attendant

Hence the total scenarios required to cover the functionality should be cross product of all variables

4 * 2 * 4 = 32

Now,

Business logic says option 3 will not be valid if card is invalid, hence new scenarios would be

``````4*1*4 = 16 // Valid Card Scenarios
+
4*1*1 = 4 //Invalid Card Scenarios
=
20
``````

But,

Since the questions ask for following

Design the minimum number of tests needed to cover all the equivalence partitions for each card brand, including both valid and invalid cards of each accepted type, along with covering each equivalence partition for transaction endings.

and based on satisfaction of this scenario it would be

``````4*1*1 = 4 // Valid Card Scenarios, since only one transaction ending would do.
+
4*1*1 = 4 //Invalid Card Scenarios
=
8
``````

And there would be one end scenario for invalid as well that need to be included, let’s say Emergency shut-off switch is thrown by the station attendant

Hence, we need to add this scenario as well.

Thus, the total scenarios required become = 9

Getting error: `NoSuchElementException - Unable to locate the element with ID attribute`

The error message from Selenium is descriptive about the reason why the test is failing, i.e., Selenium is not able to find the element in the DOM

But, the thing that is not mentioned in the error is why it was not able to find the element, and that is because the expected DOM is not loaded in the first place due to an incorrect URL passed as input to Selenium

Hence, after this when it went to find the element, it was not able to find the element with id="query"