using OR , AND in If statement

Hello Sprithi,

The short answer is no, this is not possible without code. In fact, even in code you cannot instruct Test Studio to execute specific non-coded steps. In code it's possible to achieve the same net effect by doing everything in code, or use code to run whole subtests i.e. our Test-as-step feature via code.

Now back to a high level view, most of the time when we hear such a request we discover the tester is trying to implement two different test cases into one test, where one test case is a description for testing one specific behavior or feature of the application. We're a firm believer that every single test case deserves it's own test. This is the reason we don't support what you're asking for.

The main problem the tester runs into by implementing two test cases in one automated test is that when the test fails you don't know if feature A is not working or feature B. You have to spend additional time studying the results to find out. But if every test is only testing one feature, you know instantly which features are working and which are broken simply by listing which tests are passing and which are failing.

The other complication is the structure of the test itself is more complicated. This makes it more difficult to maintain as the application changes.


Regards,
Cody
Telerik

Hi Cody,

Thank you for the reply. I will then use coded step for everything.

However, I do not completely agree that including this feature would reduce the testing efficiency because it is not always about two different test cases. Sometimes when we want the tests to handle dynamic data created during execution, this feature comes in very handy. Lot of software applications built are such that the features/functioanlity available on a page vary based on what is selected in the previous field or previous page. If we have to code a separate test for each permutaiton and combination it would be an endless effort.

In my case my application can generate about 20 different doc ids, and the following functionality would be such that some steps ( may be 3 or 4 of them) would be executed for lets say just 5 -6 types of doc ids and there may be some other steps that should be executed for 1 or 2 other doc ids. Having the possibility of including AND , OR, NOR  kind of operations in the 'IF' statement would make life so simple without compromising the testing quality.  And then if I have to test all 20 doc ids, I would just use data driven concept and execute the same test for all 20 doc ids without having to worry about writing different test cases. Also I think the maintenance would be easier - fix just one test.

Hope I am not totally wrong here. :)

Best Regards,

SHK

 

 

Hi Sprithi,

Lot of software applications built are such that the features/functioanlity available on a page vary based on what is selected in the previous field or previous page.

Yes and that is the very thing I'm referring to. If the value of the data being entered into an application changes which feature is being activated and made available on the next page, that is the very definition of two or more different test cases which should be split into different tests. Test A activates and exercises feature A while test B activates and exercises feature B and so on. They should not be mixed into just one automated test.

If we have to code a separate test for each permutaiton and combination it would be an endless effort.

Yes you're right. The key question to ask is whether or not it's a permutation of the same feature or one that activates a different feature. Having different data sets for different distinct features is not an endless effort.

And then if I have to test all 20 doc ids...

IMO creating 20 similar tests is no where near an "endless effort". Especially if you take full advantage of our Test-as-step feature in which you can modularize your tests. You can easily make 20 master tests which mostly call other modules to do different parts of the testing. Module 1 can enter fields 1-5, the module 2 can enter fields 6-10 and so on. Piece together the different modules using Test-as-step as appropriate for each of your 20 different doc types. You will have one subtest to change when that portion of the application changes, or change the master test when there's a major change to that particular doc type.

Taking this approach you have the best of both worlds, separate tests for separate doc types, but no real duplication of test steps because the real work is being done in the common subtests which can be reused by multiple parent tests.


Regards,
Cody
Telerik