Grow Your Skills with Low-Code Automation Tools

Mikeharris52 - Apr 13 '23 - - Dev Community

Some of the tools we can use to automate tests are low-code tools. One of the tools I use to automate browser testing is the low-code tool Ghost Inspector. You can develop reliable automated tests and learn a great deal about test automation by using Ghost Inspector.

Ghost Inspector can be used to automate tests without writing any code. You can build a test out of steps that do not require coding. You can identify elements in the web page that you are testing using an identifier such as an XPath or a CSS selector, and then choose a test step that interacts with the element in the way that you require, for example by clicking or by assigning a value. This provides a simple way to create automated tests. Creating tests without writing code can be valuable because it enables a tester who can not write code to start creating tests. However, if a large number of tests are created in this way they can become can be time-consuming to maintain and hard to read. They can take a lot of time to maintain because if an element on a page that you are testing changes you will have to find every use of that element and update it. Tests created in this way can also be hard to read as when you read the steps see a step that clicks on a div whose class starts with a certain string, and then a step that waits for an element that is a span whose class contains a certain string, and you are left trying to remember what do these steps do.

There are a number of things that you can do to make the most of low-code tools and make your tests easier to maintain and read.

Also check, Black Box testing its merits, demerits, types & techniques.

Maintaining your tests

One way to make your tests easier to read and maintain is to encapsulate groups of steps in a module that you can then import the module into tests. Encapsulating steps in a module helps to make tests easier to maintain because if a page element changes you only need to update the steps in the module instead of updating steps in many tests. This makes maintenance easier and quicker. Creating tests is also quicker if you have created modules because instead of creating new steps for your new test you can use these modules to create new tests. An example of this would be importing a module “login”, that contains the steps to log in, rather than creating all the steps to log in each time you create a test. The login module can be used whenever a test needs to log in.

The naming of these modules is important for two reasons. Firstly you need a name that you can find easily in your library of modules and secondly, the name needs to be descriptive so that when you read the name of the module in a test it is clear what the module does. Having modules that are named well also makes your tests much easier to read.

Run Appium mobile testing of native and web apps. Improve your app quality with instant access to real devices on LambdaTest. Register now for free

Dynamic behavior with variables

Ghost Inspector is a low-code tool that supports the use of variables. When you start to create tests you can create tests without using variables, but using variables also makes your tests easier to create, maintain and read. A variable holds a value that can be updated. The value it holds can be a URL, an email, a password, a CSS selector and something else that a test uses. If the value represented by the variable changes you only need to change the value held in the variable, instead of everywhere the value is used. Giving your variables names that can be clearly understood will help the readability of your tests.

Variables work in a given scope. The scope could be a test, a test suite or be ‘global ‘ so that the variable can be used in all the tests and test suites. Variables that you create within a test only work within that test. Variables that you create in a test suite only work within tests that are part of that test suite, and variables that you create under your organization work globally on all tests that you create.

Modules can use the variables that you create. An example of a module using variables would be to assign values to variables for email and password and then have the login module use those variables to log in. This would enable the login module to be used to log in as different users.

A comprehensive UI testing tutorial that covers what UI testing is, its importance, benefits, and how to perform it with real-time examples.

Accessing the power of the browser with JavaScript

Ghost Inspector also enables the user to use JavaScript to create steps in tests. You can create steps that execute JavaScript, in which JavaScript returns true, or extract a variable from JavaScript. You don’t need to use JavaScript to create Ghost Inspector tests but using JavaScript in test steps enables you to extend Ghost Inspector functionality and provides a way to learn JavaScript. You can learn at your own pace. There are lots of resources to learn JavaScript. You can start by storing variables in a JavaScript object in an Extract From JavaScript Object step like this:

const emailAndPassword = { email: "user@email.com", password: "password" };
return emailAndPassword
Enter fullscreen mode Exit fullscreen mode

You could then use the variable in a module to log in to the application that you are testing.

You can also create steps that extract values from page elements or create a variable from one of the values held in a JavaScript Object. Ghost Inspector includes a step that checks for the presence of one element on a page, and if you want to check for more than one element with the same CSS selector you can write a step to do that uses document.querySelectorAll(selector).length to get the number of elements and then use an ‘if loop’ to check that the number of elements is correct. If the correct number of elements is found the step will return true if not the step returns false and the test fails. Creating steps with JavaScript can help you develop your skills with JavaScript at your own pace.

Your tests will be more consistent and easier to maintain if you create standards for your tests. An example of a standard you could create would be a naming standard for variables. You could create a standard for naming variables that states that variables should have a prefix to show if their scope is local to the test, to the test suite or that they are global variables that can be used throughout your tests. A standard for naming variables could look like this:

  • Names of standards should be camel case

  • Names of organization-level variables should start with org

  • Names of test suite-level variables should start with ts

A standard like this will help you maintain and develop tests because when you read the variable’s name, you will know its scope.The standards can be extended to include other points that you find useful such as what type of element selector is preferred, and how libraries of modules should be organized. Using standards when creating tests will also help collaboration because everyone who is creating the tests should use the standards when creating tests.

In this Ad hoc testing tutorial, let’s deep dive into what Ad hoc testing is, its advantages, disadvantages, types, characteristics, and their best practices.

The Five S’s

It is also useful to use the Five S’s to create a disciplined structure to help you create and maintain automated low-code tests. The Five S’s are recommended by Mary and Tom Poppendiek as a way to create the discipline necessary to develop quality software. They wrote that “the five S’s are a classic lean tool to organize a workspace” [1].

The Five S’s can help keep Ghost Inspector automated tests in a state where they are easy to maintain, have no flaky tests and are easy to read.

The Five S’s are described in Implementing Lean Software Development [1] by translating the original Japanese words into English and by giving examples of using each of the S’s in the kitchen, in the workplace and for a development project. I have used Mary and Tom Poppendiek’s idea and created a table showing the English translation of the Japanese words and examples of using the Five S’s in the kitchen, workplace and Ghost Inspector test automation.

JAPANESE ENGLISH KITCHEN WORKSPACE GHOST INSPECTOR TEST AUTOMATION
Seiri Sort Sort through kitchen tools and throw away any unused tools. Sort through the servers, and find old files that will never be used. Delete or back them up. Remove unused modules
Seiton Systemise Find a place for everything and make it easy to find. Craft desktop layouts and file structures so that things are easy to find Organise tests, test suites and modules so that everything is easy to find.
Seiso Shine Clean the kitchen. Clean whiteboards and desktops. Bring old tests in line with the standards
and improve performance.
Seiketsu Standardise Fill and run the dishwasher every night Put automation and standards in place. Reduce complexity, improve ease of maintenance and create standards.

In many ways, Sustain is the most important of the Five S’s because it is by sustaining the practices you create using the Five S’s that your automated tests will become more reliable, easier to maintain and easier to read.

In this Data driven testing tutorial, let us deep dive into what data driven testing is, its pros & cons, its types, data driven testing in an agile environment, benefits, and their best practices.

Wrapping up

In making the most of low code test automation you will create reliable automated tests and learn a range of software development skills such as using the scope of variables, coding in JavaScript, encapsulation to create modules, writing standards, and how to use the Five S’s. These skills will help you create stable test automation with Ghost Inspector and will help you develop your test automation skills.

Run your Jest testing automation in massive parallel across multiple browser and OS combinations with LambdaTest, Read more.

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .