1. categorizing dependent test cases

I have one doubt,can anybody plz give solution for that....
In group of dependent test cases, by executing one test case we can tell the result of remaining test cases in that group.
Even this will happen in the case of Equivalence partitioning.
so can we categorize both as same?
regards
arunar

2. Re: categorizing dependent test cases

In Equivalence partitioning you are more involved with a particular test case rather than linked test cases. By adopting this EP approach you will get a good hit rate, to discover the most errors with the smallest number of test cases. So equivalance paritioning is more of a process to generate the equivalances classes (each member of the class causes the same kind of processing and output to occur) hence creating the test cases and executing the test cases are the result. So you cann't categorise both as the same. Also valid input can cause all others test cases to give valid result however the reverse may not be true. It's like 2+2 will always yield 4 but 4 doesn't mean that it will be only for 2+2, it can be also 3+1. So for group of linked test cases there may be diffrent set of equivalnce class for each test scenarion. Hope that it helps.

3. Re: categorizing dependent test cases

<font color="brown"> </font> Let's discuss this with example for each of the following.
[1] Equivalence Class Partitioning.
Here say there are two classes viz., Class A and Class B. If a test case in class A fails then we can say that all test cases in class A will(should) fail. Same in the case of class B.

[2] Group of dependant test cases.
Here say there are 'n' test cases. For example, TC#1 depends on TC#2, TC#2 depends on TC#3 and so on till TC#n-1 depends on TC#n.
Now, if TC#1 fails then all test cases from TC#2 to TC#n will fail. But, if TC#3 fails then all test cases from TC#4 to TC#n fails expect for TC#1 and TC#2.
Where as in the case of point [1], if a test case in Class A fails, then all test cases in that Class are expected to fail.

4. Re: categorizing dependent test cases

Equivalence Partitioning is a test design technique which we follow to reduce the number of test cases by performing partitions in the inputs as valid invalid-low and invalid-high. So we expect all of these test cases to pass.

But where as if we consider the Test cases if those are for a specific module in the software then if the test case on main functionality is failed and this functionality is inter related to all the others in that module then we can conclude that the test cases of that specific module are likely to fail . But if that passes and the other which is not that much related to the entire application then if that fails we can not conclude that all the test cases will fail because the others may work.

5. Re: categorizing dependent test cases

continuation with MaxAKK,
thanks for replies and now i am thinking of one more doubt.that is

Let's say ,In a group of 10 dependent test cases if 1st and 2nd test cases are pass and 3rd case is fail.then can we say
the remaining test cases are fail.
regards
arunar

6. Re: categorizing dependent test cases

I advise you to reread MaxAKK's number 2 again. Perhaps you missed the point.

7. Re: categorizing dependent test cases

hai arunar,

you had asked that 1st and 2nd TC had passed and 3rd TC failed then all the other TC's will fails or not.

For this question they had already answered very clearly. Once again i will clear you. If all the other Tc's are dpendant on the 3rd Tc then they will fail. If they are not dependent on 3rd TC they they don't fail.

8. Re: categorizing dependent test cases

What is the general practice when you do that? I mean, if your test case fails, do you still try to execute dependent test cases or you mark them fail and re-execute all of them later? The reason why I am asking this is because, sometime you might not be able to execute test case, but can certainly explore areas surrounding it.. This has helped me in the past in identifying more defects.

9. Re: categorizing dependent test cases

hi arunar
If one test case fails then the overall status of the document would be fail and you have to re-execute the entire test case document along with associated regression areas.

10. Re: categorizing dependent test cases

[ QUOTE ]
What is the general practice when you do that? I mean, if your test case fails, do you still try to execute dependent test cases or you mark them fail and re-execute all of them later? The reason why I am asking this is because, sometime you might not be able to execute test case, but can certainly explore areas surrounding it.. This has helped me in the past in identifying more defects.

[/ QUOTE ]

i'll provide a bit of background on why this is occurring. the reason you're finding defects surrounding a failed test case is because the other areas you're testing are actually not part of the partition that contains the defect. each partition is a decision path in the software.

here's an example....let's say you have a dependency that you're TV is on in order for the speakers to work. If you can't turn on the TV you should not be filing a defect that says the speakers don't work. the defect is in the actual turn-on functionality...the speakers work perfectly provided they are provided input. this is where you'd want to partition your app into speakers and turn-on/off functionality

[ QUOTE ]
<font color="brown"> </font> Let's discuss this with example for each of the following.
[1] Equivalence Class Partitioning.
Here say there are two classes viz., Class A and Class B. If a test case in class A fails then we can say that all test cases in class A will(should) fail. Same in the case of class B.

although this sounds kind of nit picky it's actually quite important to proper partitioning. Classes and member functions are the implementation details of a particular decision path. If the decision path is implemented via private member functions in class A you need to test the decision paths in Class B because they can't access class A's member functions unless either class A or B is a base class. If either is not a base class, derived classes will inevitably contain different decision paths because there's really no reason to define the same routine/decision path in 2 classes.

[2] Group of dependant test cases.
Here say there are 'n' test cases. For example, TC#1 depends on TC#2, TC#2 depends on TC#3 and so on till TC#n-1 depends on TC#n.
Now, if TC#1 fails then all test cases from TC#2 to TC#n will fail. But, if TC#3 fails then all test cases from TC#4 to TC#n fails expect for TC#1 and TC#2.
Where as in the case of point [1], if a test case in Class A fails, then all test cases in that Class are expected to fail.

[/ QUOTE ]

I think this requires a bit of background
1. Do test cases equate to decision paths or do they fall into a particular partition? This may vary depending on your test planning process but is key to understand.

[ QUOTE ]
So equivalance paritioning is more of a process to generate the equivalances classes (each member of the class causes the same kind of processing and output to occur)

[/ QUOTE ]

If you have multiple member functions of a class outputting the same result there are some real issues with the implementation. Even if this were to occur you wouldn't want multiple partitions since a failure in member function A of Class1 would be default mean a failure in function B of Class1 since the return type/output is the same.

Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•

vBulletin Optimisation provided by vB Optimise v2.6.0 Beta 4 (Pro) - vBulletin Mods & Addons Copyright © 2016 DragonByte Technologies Ltd.