Rules Management and Tests Structure | Bondar Academy
Course: Mastering testRigor
Module: Reusability and Optimization
Instructor: Artem Bondar
Lesson Summary
In this lesson, we explore how to manage reusable rules in TestTrigger and the importance of effective test design for successful automation frameworks. Key Differences in Automation Projects The success of an automation project is not solely dependent on the choice of the tool but rather on how it is utilized. A significant number of automation projects (approximately 80% ) fail due to poor maintenance and design, leading to frameworks that become burdensome to support. Importance of Test Design To prevent frameworks from becoming obsolete, it is crucial to implement a correct test design that minimizes maintenance efforts. Key aspects include: Naming Conventions: Establish clear naming conventions for projects, reusable rules, and test cases. Documentation: Create a comprehensive document outlining these conventions, which should be accessible to all team members. Examples of Naming Conventions For test cases integrated with tools like Zephyr , a naming structure might include: RT01_FeatureName_Description For reusable rules, a suggested format is: PageName_Action_ExpectedOutcome Best Practices Each reusable rule should begin and end with an assertion . Use specific verbs for actions (e.g., check , fill , navigate to , create , add ). Organize rules into folders for better navigation and maintenance. By adhering to these guidelines, teams can enhance the maintainability and reusability of their automation frameworks, ultimately leading to more successful outcomes. In conclusion, prioritize naming conventions and documentation before writing automation scripts to ensure a robust framework.
Video Transcript
In this lesson, we will talk about how to manage the reusable rules in TestTrigger and overall about test design to make your framework successful. So here's the question. What's the difference between the successful test automation project versus the unsuccessful automation project? And this is definitely not the choice of the tool. This is the way how the tool was used. Of course, the tool itself matters because newer tools or newer frameworks helps you to deliver faster results and be more efficient. But the tool itself will not make a difference if you will not use it the right way. I think I will not be too far if I will say that 80% of automation projects will die within like a couple of years. And of course, sometimes the reason behind that is just project is not relevant anymore and the framework goes away. But in most of the cases, the main reason why the framework become abandoned is the maintenance. So if the correct test design was not implemented for the framework, the amount of maintenance for this framework is growing exponentially and very quick. And eventually you have a situation when you need to spend more time on just maintaining your existing test rather than spending the time on adding new tests to your framework. And eventually all your time is just supporting this framework, maintaining and keep it afloat. And if your tests become flaky or unstable, then the framework just become useless because it loses trust from the development team. And this framework just doesn't make sense to keep and support. And eventually a new person come to the company and says, hey, we're going to use XYZ framework. It's a wonderful and it's going to solve all of our problems. And it will be true or not, depending on if this person will implement the best practices and the right test design for this particular framework. And the test rigor is not exception as well. So in test rigor, you can either create a masterpiece and very well-functioning framework or it can be a maintenance nightmare. And in order to keep the test rigor framework well-maintained, you basically need to keep three main things well-organized, such as develop a naming convention for your project, develop the naming convention for the reusable rules and for the test case. Let me show you an example how this naming convention and the framework style guide can be created for your project. So I created this document, just an example. You need to create the document like this as a Google Doc, as a Wiki page, as an Excel spreadsheet or any other format that's going to work for you. You need to share this document with all your team members. And this document have to be the very first thing to read for the person who's going to touch the framework and adding any new test to the framework, because it defined the rules and guides how this person is supposed to interact with this framework. So here's what it can look like. For example, test case naming. And let's say that our framework is integrated with Zephyr, test case management tool, and test rigor supports multiple different tools to integrate with. For example, TestTrail, Zephyr, Jira, and so on. Let's say it's integrated with Zephyr and we say the framework integration with Zephyr and the test case should start with a test case ID, followed by the feature name and the description. And this is the example, how would we want, for example, for our framework to name the test case? For example, RT01, the ID of the test case, then the feature name, and then the description of the test case. Something like this. All of this have to be defined because when you have a lot of test cases inside of your test suite, the strict naming convention with some ID or some feature or something like this will help you to quickly find those test cases inside of the test suite. Also in test rigor, you can use and have to use labels right here. So if you click on the add button, you can develop your own labeling system for different types of the test cases. And those labeling system also have to be mentioned inside of this document. The next step is the reusable rules naming. And for example, this could look something like this. Every usable rule name has to follow the following template, page name plus action according to the naming convention and expected outcome of action. So again, the pretty strict structure, how the name has to be defined for the reusable rule in a couple of examples. Form layouts page column, fill in user credentials at horizontal form, submit to be taken to the user page. So form layout page is the page name. Then the action is this one and expected outcome to be taken to the user page. The second example, smart table page, create a new user with first and last name and the expected outcome to be saved at the first row of the table. And also one of the test rigor best practices that every reusable rule should begin and end with the assertion. And again, this is just an example how you can define the rules for the naming for the reusable rules and also action naming convention. This is also highly recommended way to use. And for the actions, you have to define how would you word different types of actions that your reusable rule will perform. For example, we use check if we want to interact with the check boxes or we use keyword feel when user need to enter data in the input field or type we use only when we want to emulate a human typing type of a behavior. Navigate to used for navigation across the application using a navigation menu. So only for navigation across the application, use navigate to nothing else. Or for example, create when a new entity to be made and add when an entity piece of data is a part of larger parent entity. For example, in this example, smart table, I used create a new user intentionally because we are creating a new entity inside of the table. And if I would like to add first and last name, this would be updating the existing entity. And I would use a word add. So it means that I want to update the existing user. I don't want to create first and last name, right? I don't want to type first and last name. I don't want to feel first and last name. I create because by this action, I create a new entity. For example, here as well, I use the keyword feel intentionally. It's not just random, most suitable word. Feel because feel according to our naming convention is used to interact with the input field. I do not click an input field and type something over there, right? I feel in input field. And so on and so forth. And for example, keyword click can be used only for the types of icons, links, and buttons. And that's it. You don't click on the dropdown menu. You select a dropdown menu because select according to the naming convention used to select options from the dropdown as well. You don't click on checkboxes. You check on the checkboxes. I think you got the point, right? So why is this important? So when you have a strict rule naming for your reusable rules, for you, it will be much easier to find those rules later on inside of the list of reusable rules and inside of the test cases as well. And one more thing, you can even add the graphics like this. If your application has a specific types of the UI elements that are repetitive for your application, you can put the graphic and say, hey, this type of element, we call a hamburger menu, and this is a kebab menu, and this is bento menu, and so on. So everyone will be on the same page. And when you type something like click hamburger menu, it's clearly understandable that click is related to the icon links and buttons. Hamburger menu is a button. You click on the hamburger menu button. Pretty clear, right? Also you can use something like verify. You can use verify for the reusable rules that are used only for the verification of the particular steps. And yeah, so let's go back to our framework and look into our existing reusable rules. Here we go. So we already have navigate to type of the rules according to the naming convention. When I was creating those, I intentionally created them like that. But let's look at the other one. For example, fill username with username and password and click button to be taken to dashboard page. So it's already according to the usable rule. All we need to do is just to update this that it's related to login page, save. And now we know that this rule only can be executed on the login page. Okay, so go back here, submit form with name, form name and super user credentials. Again, so this one is not mentioned in our naming convention as of right now, but you can add it. For example, if you have applications that have a bunch of different forms and you need to work with different forms, you can add this word into the list of the naming convention and use this. So what we need to do is just add form layouts page and save it. And then confirm friendly reminder. Again, we don't have any rule right now. For example, we can create auto apply at the beginning so it will be easily searchable or not edit at all. We can just put this into that separate folder. We will talk about it in a second. And then why is this important? So now when we go to the test cases and I create a new test case, and when you want to find a particular rule, all you need to do is type that page where this rule has relation to, for example, form layouts page. And here we go. You can find the rule, which start with form layouts, and then you can see, okay, which rules do I have that belongs to the form layouts page? Is this rule related to this page and to certain action on this page? And this way you can filter quickly the list of the rules. And trust me, you will have a lot of rules later on, like hundreds of rules. And to easy navigate across your rules and avoid the duplications of those rules, avoid the dead rules that were deleted from the test case and not used anymore. That's the good way to organize it. Or for example, let's say if I type name, look at this. So when I type just name, TestRigor pull everything what has kind of name in it. It put the name inside of form layouts page, on login page it also has user name, and even navigate to smart table page, it found a name in this kind of combination of letters, just because M-A-M-E, right? So it can be confusing. If you will search the rule by partial match of the maybe suggested name of the rule, but if you search it by the page where this rule is located, for example, okay, login page, here we go. And you will see the list of the rules related to the login page, or the form layouts page. And like that, or you need to navigate, here we go. This is the rules related to the navigation. And that's pretty easy how you can find the rules inside of the test case, all right? And the last thing about the reusable rules. So in the reusable rules, you can also, as I mentioned before, add labels. So use this functionality as well. And you can add labels into your naming convention, into the document, okay? Which labels and how do you assign labels to your reusable rules? Also, you can create a folders. For example, I can create a folder and call it Navigation Rules, Add. And then you can put all your navigation rules into this folder. So move to Navigation Rules, and here we go. Unfortunately, I cannot select them all at once, but we don't have a lot of them. Move here. All right, and now the rules are a little bit better organized. Navigation Rules located in the Navigation Rules folder, and the other rules right now in the room. But when you have more rules related to different pages, for example, then you can create other folders related to those pages and put the rules over there. It will be, again, easier for you to navigate and organize later on. And it will improve the maintenance and simplify the maintenance of your framework by a lot. All right, that's all I wanted to share with you guys. So start with the naming convention. Develop it first before you even begin writing any automation for your framework. If you already started, pause over there, develop the naming convention, refactor your existing framework according to your rules. Discuss this with your team. Is everyone on the same page? Make this document publicly accessible to all of your team members and ask everyone to follow this document. If you will do so, your framework will be highly reusable. It will be highly maintainable and will give you only excellent results. All right, thank you guys and see you in the next lesson.