Approach and Guidelines for Automation with Robot Framework

Welcome to our guide on Automation with Robot Framework! 

This article provides essential guidelines for teams engaging in end-to-end (E2E) testing. Focusing on UI workflows, settings, test cases, keywords, and variables, this guide equips you with the knowledge needed to streamline your automation processes, whether you're a beginner or a seasoned tester.

UI Workflows: The testing team will collaborate with the Product to understand the key business workflows and automate them using Robot Framework.

Guidelines:

There are four major factors in a Robot framework’s .robot file:

• Settings
• Test Cases
• Keywords
• Variables

Settings:

• This is the section where you import all your Automation-related Libraries

• Ex: Library SeleniumLibrary

• Addressing any relatable files where you might read data.

• Ex.: Resource  ../Directory/filename.robot

• Other usages:

• Suite Setup  <keyword_name>  (To kick start execution)
• Test Setup <keyword_name>  (To start Test Case)
• Test Teardown <keyword_name>  (Closing each Test Case)
• Suite Teardown <keyword_name>  (Terminates the execution)

Example

***Settings***

Library SeleniumLibrary

Resource  ../Directory/filename.robot

Test Cases:

• Start building your test case with proper Descriptions
• Add [Tags] to the Test Cases if wanted to execute any specific Test cases.
• Your Test Steps should follow Gherkin syntax.
• Test Steps should be in simple English.
• Your Test Steps are going to be Keywords which helps other testers to re-use it instead of duplicating the same keywords.
• Your keywords can carry your input data which require for any operations.
• Follow a Next Line and a Tab between Test case Description and each keyword.
• Follow a double space between each input followed by any keywords 
• Mnemonics: 

Ex:

***Test Cases***

User should be able to Log into Moolya successfully

[Tags] e2e

Given user launches Moolya Application to login

And user provides valid credentials  <user_name>  <user_password>

When user clicks on the Login button

Then Moolya home page should be Open 

Keywords:

• Pass along a set of RF command(s) you would like to perform under each keyword.
• Make sure keywords are not duplicated.
• Gherkin syntax need not be copied here from your Test Cases
• A keyword can take tester’s input data as Arguments and return output value if required
• Follow a Next Line and a Tab between Keyword and RF instructions.
• Follow a double space between each input data followed by any keywords.
• If any of an existing reusable keyword name needs to be modified- Inform the team and give a valid reason for changing the keyword’s name.

***Keywords***

user launches Moolya Application to login

Open Browser  <url>  chromebrowser

Maximize Browser Window

user provides valid credentials

[Arguments] username  passcode

Input Text  <locator>  username

Input Text  <locator>  passcode

user clicks on the Login button

Click Element  <locator>

Moolya home page should be Open

${title} =  Get Title

Log to Console Get Title

[Return]  ${title}

Variables:

• Avoid duplication. Before adding a new test script, consider going through the existing variables before creating a new one. 
• Could pass a string, integer, or data type.
• Add Variables to the right section based on the feature so they can be reused for new scripts.
• Can set variable value while running script at Suite level or Test level.
• Follow two spaces between the variable name and value

• Ex: ${name} =  username (or) ${name}  username

***Variables***

${name} =  username (scalar variable)

@{types} =  [abc, def, ghi] (List variable)

&{map} =  name=username  age=29  locale=English  (Dictionary variable)

Good Practices:

1. Create Good, Quality Test Data - Test data required for the automation runs should be maintained in a separate CDS following some convention so the same CDS will not be used for any other purpose.
2. Test scripts should aim to use existing data unless the workflow demands the creation of new data.
3. Test scripts requiring the creation of data should be considered for clearing ONLY if such a possibility is seen.
4. In order to make UI tests resistant to the changes in UI, we need to consider providing unique names to the controls
5. Do not hardcode Credentials or any secure data in the script. Use a separate file like the creds.py file while running locally and Do not commit the creds.py file to the git.
6. Follow unique and proper Indentation everywhere.
7. Make a Pull Request and get the PR approved by at least one peer automation tester before Merging
8. All Tester inputs and locators (aka Dynamic values) should go under ***Variables*** section, do not write directly into **Keywords*** or ***Test cases***

1. Even if a variable is a one-time use, do not write those dynamic values inside the keyword. Reason: when an element is changed in the future, a resource should think of one place where he needs to go and make the necessary changes which should be a Variable section, let’s save the trip from going back and forth between Keywords and Variables.
2. Let’s not have any Keywords under PO_*.robot file. Reason: we’ve already separated the keywords into two sections (Common.robot and feature-level.robot) Let's not again split them into the third section and add it under PO(PageObject) level. PO_*.robot files should have only Variables.

Handling credentials or any secure data:

1. Create a .py file (or any other file that is feasible)
2. Pass all secure data in an individual function or save it as a collection (list or dictionary)
3. Import it to your .robot file under the Settings section (Ex.: Library    secureRead.py)
4. Add the .py file name into .gitignore file

Note: Do Not commit this secure .py file into any git repositories.

Folder Structure:

StMg_RF_Automation

• Applications(Test Case step functions are divided Application level)

• StudyManagement

• Milestones
• Enrollments
• Service Providers

• Task Management

• Study Tasks

• Custom Libraries

• (Any custom Libraries which helps to achieve automation)
• Ex: SecureData.py

• Resources

• (Any Steps which are common for all Test Suites)
• Common.robot
• Utility_UI.robot
• Utility_API.robot

• Tests_UI

• Milestones.robot
• Enrollments.robot
• Service Providers.robot

• Tests_API

• Api_configs.robot
• TC_API.robot

• LocatorVariables.robot
• Requirements.txt

Test Data Management:

Test data is the key to execute automation test suites in different environments (sandbox, e2e). The objective of this section is to understand the process or steps needed for data setup, cleanup, and reusability.

The above objective can be implemented with the concept of Test data setup and tear down functions in Robot Framework:

1. Test data Setup and Teardown are handled part of separate user-defined keywords
2. Both functions can be configured at the test case file level or in individual test cases
3. Test data setup defines the base state for a test suite or individual test case
4. The test teardown function restores the data to the base state after test execution
5. For clean-up activity within study management, the approach is to trigger specific APIs

‍

Final Words

‍

In summary, Robot Framework enhances your E2E testing efficiency. Following these guidelines ensures not just powerful but also easily maintainable automation suites. Embrace good practices like quality test data, secure credential handling, and a clear folder structure for sustained success in your automation journey. 

‍

Happy automating!