Shared Suite | Bondar Academy
Course: Mastering testRigor
Module: Reusability and Optimization
Instructor: Artem Bondar
Lesson Summary
Lesson Overview: This lesson discusses the concept of shared suites in testing environments, specifically how to manage multiple test suites for different environments using a feature called test trigger . Key Concepts: Shared Suites: Allows sharing of existing tests, test data, and information across different test suites. Test Environments: Different environments (e.g., QA, Staging) require separate configurations. Creating Test Suites: New test suites can be created for different environments without modifying the original suite. Steps to Create a Shared Suite: Create a new test suite (e.g., Playground Staging ). Configure the new suite's settings independently. Use the inheritance feature to pull in test cases, test data, and reusable rules from the parent suite. Inheritance Details: Test cases and rules from the parent suite can be inherited but not modified in the child suite. Test data can be overridden in the child suite, allowing for environment-specific values. Test cases can be disabled in the child suite to exclude them from execution. Best Practices: Avoid double inheritance; only single inheritance is allowed. Clearly label parent test suites for easy identification. In summary, shared suites facilitate efficient testing across multiple environments by allowing inheritance and modification of test data while maintaining the integrity of test cases and rules.
Video Transcript
In this lesson, we will talk about shared suites. So in most of the companies and most of the projects, you may have a several test environments where you need to run your tests. So shared suites feature of the test trigger can help you to achieve this when you can share your existing test, test data and other information with other test suites to be executed in the different environments. So let's get into it. So this is our current Playground QA test suite. So let me go to the test suites and we have just a single test suite over here. And current test suite is configured to execute the test against this URL, playgrounds.bonderacademy.com. But you may have a different environment for your application, for example, staging environment when you need to run your test against a different environment. One of the ways doing this, you can of course just update this URL and click rerun. And all your tests will be executed against different environment. But this is not the best way because you need to go back and forth and update this URL. The best way would be to create a new test suite dedicated to a different environment. So let's do this. I go to the test suite and I create a new test suite. For example, I call it Playground Staging. Something like this. And since I don't have any other URL, I will use the same URL for this demonstration, but assumption here that as a base URL, you would use a different one. For example, playground-staging and your application something. And I keep everything as a default and just create a test suite. Okay, a new test suite is created and it is empty. It doesn't have any test cases, reusable rules or anything like that. Also, this test suite has independent settings for this test suite. So this thing we need to configure for this particular environment. And let me open the other environment in a new tab. So we'll have them in parallel. And I want to make the adjustments for the new test suite according to our current suite. So for example, we were using here in advanced section, we were using this stroke attribute. And I want to add it as well into the staging test suite. So advance, and I want to add this attribute. Also, I would like to adjust. So save. And also would like to adjust in speed optimization here, five seconds timeout and remove this checkbox just to speed up the test execution. And that's it. So we don't have here reusable rules. It's empty, test data, it's empty and the test cases empty as well. But what we can do, we can inherit the test cases, test data and the reusable rule from the parent test suite. And in our example, the parent test suite will be this one, Playground QA. And staging will inherit this information. So I go to the shared suite section and I select the test suite, which I want to inherit from. And I select Playground QA. And now we can select, okay, which data do I want to inherit? And let me start, for example, with a test data and rules only. I will not inherit the test cases first. Then I click save. All right, and now if we go to reusable rules, we have this new tab, parent suite rules. Here we go. And here we have all the rules that are in the parent test suite available for us. So you can review those rules. You can navigate in the folder structure, but you cannot change anything for this rules. You cannot modify any information. You just can review and to see what this rule is about. You cannot add the tags or anything like this. Also, if we go to the test data, we also have a test data inherited from the parent suite. So now if I go to the test cases, and let's say I want to create a new test case, then those rules are available for me. So navigate to, and here we go. I can navigate to the form layouts page, for example. So this rule is inherited from the parent test suite. And if I will go back to the parent test suite and will modify this rule, for example, navigation rules and form layouts page, if I will modify these steps of the parent rule, the inherited step in playground staging test suite will be updated as well automatically. All right, so this is how it works. And now let's inherit also test cases. So if I go to the shared suite settings and I put this check box and click save. All right, and now we go to the test case and here we go. Now we have a list of the test cases from the parent test suite available in the child test suite. And again, you can only view the steps of this test case. You cannot modify anything in this test case. All you can do is view steps and retest, and that's it. And also you can disable the test case. And the disabled test case is a useful feature when you want, for example, exclude some of the test cases from the execution. So normally lower end environments, for example, your QA environment and this playground QA test suite have a larger number of the test cases that covers multiple flows. And let's say for the staging environment, you would like to cover only some portion of the test or only some of the scenarios can be executed in the staging environment. So that's why the scenarios that cannot be executed, you just can go in something like do, okay, disable this. And this test case right now will be disabled. And when you execute the entire test suite, this test case will not be executed. Additionally, how you can control what should be executed and what is not, you can go here and additional run settings right here. You can specify which labels have to be executed or which labels should not be executed. But you cannot add those labels on the test cases and the test case level right here. So labels are also inherited from the parent test suite. So what you can do, for example, as a future proof, you can go to the test cases. And when you create a test cases, you can add the label. For example, this login page have to be executed only in dev environment, something like this. And then when you go to the child suite for the playground staging, you can add here something like this dev. And the test cases that have this label dev will not be executed in the child test suite. What else? Let's go to the test data, test data right here. So test data is also inherited from the parent one and data sets and so on. And you cannot modify this test data. But what you can do is either add your own test data or override the existing test data. So let me show you the example. So going to the test cases, and one of our test cases has, I think it's this one, view steps. Yeah, so when we were navigating to the login page and then we fill username with stored value, super user email. But our staging environment, for example, can have a different credential for the super user email. We cannot update this step from the parent test case, but what we can update is override this variable in the data set with a different credentials. So going back to the test data, and I create a new value with the same super user email variable. So text, variable name, I provide the same variable name. And for example, it will be superuser2 at test.com and click add. Now you can see a new label showed overridden. So this variable will have a new value only for this particular test suite. And if we run this test case right now, let me find this out. Enter user credentials. Yeah, and let's retest. Okay, interesting, unrecognizable instruction. Let's see, view steps, navigate to login page. Oh, I see, in the previous lesson, we made a rename of our usable rules, but we did not update the test case. So let's go and update the parent test suite. And this is the step, and it start with login page, fill username. Let me copy this, test cases. And where is this test case? Navigate to different pages, enter username. This one, quick edit, and I need to update this with a correct name. Okay, the parent test case updated. I click validate and save. I will not rerun it. Then I go in here, click refresh. Now let's see this test case that failed before. View steps. Now it's updated with correct steps as well. And I click retest. All right, and test passed successfully. Let's check it out. Now you can see we were using superuser2 at test.com. So we were able to successfully override the test data value inside our child test suite with a new value that we want to use for this test case. And one more thing that you need to know that you cannot create double inheritance for your test suite. For example, we have a parent suite, then you create a children suite, and you cannot create a second child suite out of the previous child suite. So this double inheritance will not work. You can create only a single inheritance from the parent. You can also create several child suites inheriting from the parent test suite. And also probably a good idea would be to name your parent test suite with some kind of parentheses. For example, Playground QA, and put parentheses and put parent. In this case, in the navigation of the test suite level, you will always know which test suite is your parent one, which has the initial reusable rules, variables, test cases, and so on. All right, so let's make a quick summary of this lesson. So you can inherit reusable rules, test data, and test cases from the parent test suite. This is very useful when you have several environments and you need to inherit the test cases and test data between the environments and to execute in different environments. You cannot modify test cases or reusable rules in the child test suite, but what you can modify and override is the test data inside of your child test suite. All right, that's it. And see you in the next lesson.