Product testing is one of the final stages of NoCode development before app deployment and distribution. During the testing phase, it is necessary to:

• make sure that there are no critical errors and technical failures that can occur with the expected (or unexpected) behavior of the user;
• automate the testing process and build tests into the overall development pipeline.

When there is no need to write code for tests, not only developers and testers can be involved in the testing process, but also other specialists interested in the quality of the product. However, before diving into the tools of NoCode testing, it is necessary to know some common terms.

Types of tests

There are different approaches for classifying tests. For example, according to the hierarchy of structural units – from individual blocks and their interaction to the whole system:

1. Unit testing checks small blocks of code: isolated functions and classes. In the context of NoCode-technologies, unit testing is the responsibility of developers of building blocks of NoCode-applications and those who create their API.
2. Integration tests verify the mechanics of the interaction between the basic blocks checked during unit testing. Workflow platforms are responsible for this level of testing, where zero-coders connect blocks of subprograms into complete apps.
3. System testing is aimed at examining the product as a whole thing. For small programs, this is usually manual testing, but for large services the process is automated. It is this level of testing that is most significant for the NoCode, so we will focus on it below.
4. Operational testing checks how the system meets the real needs of the end user. In fact, operational testing takes place at the MVP stage. Not only the software components but also the context in which the NoCode app operates affects the success of the project.

Another essential way to classify tests is the timeline of corrections:

1. Smoke tests – identifying obvious errors, without which it makes no sense to give the program more in-depth testing.
2. Re-testing – verification of corrections of previously identified problems.
3. Regression testing – checking that the changes made do not cause errors in the rest of the program.
4. Acceptance testing – checking for compliance with the customer's initial requirements.

The general idea of NoCode testing systems

The field of software testing has been evolving for several decades, so there are enterprise products for testing large systems with many features and test subspecies, such as BrowserStack.com, TestComplete, TestArchitect, Usetrace, or Opkey. But for small and medium businesses, these solutions are redundant.

NoCode testing as NoCode development minimizes user effort. So the most common technique for creating tests is record-playback. Recording a test is not much different from recording a screencast:

1. The developer of the NoCode app starts recording in the browser extension of the test platform and uses the NoCode app as a common user of the product.
2. The testing service identifies specific actions: clicking on items, entering forms, dragging, swiping, hovering, loading a file, or copying to the clipboard.
3. When finished, the record is converted into a test script, which the developer modifies in the visual editor: remove unnecessary steps, add special checks, set variables, and actions before or after the test runs. And all this without writing any code.

The Reflect and Rainforest QA tools create video files of the test execution in addition to the step-by-step script, synchronized with the sequence description. As a result, each failed test presents a self-documented bug report with exact instructions on how to reproduce the problem. It turns out that the developer doesn't even need to learn the test tool itself.

There are other strategies for testing applications, which we will talk about later, but the general idea of testing comes down to the one described above.

Codeless product testing platforms

Codeless testing tools can be divided by the mechanics of how the test writing is implemented. Some of the features the applications have in common, but the following can be identified as global strategies:

• test editors with a record of manual test actions: record-playback (the most common variant) and subsequent visual coding;
• visual programming of an automated test;
• crowdsourcing – transferring the task of manual testing to the QA community;
• finding and testing the most likely cases of user interaction with the application using machine learning.

Below we reviewed the key ideas of each test approach and gave examples of tools.

Record-playback

Web app testing tools: Katalon Studio, Cypress, Reflect, Screenster, Preflight, Ghost Inspector, mabl.

Testing tool for mobile apps: Waldo.

Idea: The result of a manual test is recorded with a browser extension and converted into an editable automated test script.

For simple tests, the results of such a record as we described above are sufficient. For more complex tests the testing platforms allow the LowCode approach with short scripts written in a JavaScript editor.

Visual programming

Web app testing tools: Leapwork, Ranorex Studio, AutomationHQ, Boozang, Opkey.

Testing tool for mobile apps: Waldo.

Idea: to build a test chain, the user connects blocks visually with drag-and-drop mechanics.

The advantage of such systems is the ease of reuse of individual blocks and the possibility of multiple branching of the same test, which can be displayed as a MindMap-like structure.

Crowdsourcing

Tools: Rainforest QA, CloudQA.

Idea: not all problems can be tracked through autotests, manual tests in real-world use cases cannot be completely dismissed, but we can make it easier if we involve the QA community.

Rainforest QA offers access to a crowdsourcing platform for manual app testing in addition to automatic record-playback-style tests.

Machine Learning

Tools: Testsigma, Testim, Perfecto, Virtuoso, Applitools acceIq.

The idea: routine repetitive actions should be handled by algorithms, not humans. To improve the quality of testing and complete test coverage, such platforms use artificial intelligence capabilities to analyze the structure of apps.

Thanks to machine learning, these tools are able to create and run automated tests without the help of a tester. Under the hood, the services use JavaScript code that can later be edited and used to collaborate with Selenium, the most common classic auto testing tool.

Testsigma and Virtuoso focus not only on code analysis but also on natural language processing. Thus, in the case of Testsigma, you can describe the necessary test in plain English, and the service will automatically create the necessary test script.

Conclusion

What to look for when choosing a test automation tool:

• Is there NoCode support for the most time-consuming and repeatable tests of the project? Usually, these are regression and smoke tests.
• How adaptive tests are to visual changes in the design of the NoCode app?
• Is it possible to test the app in multiple operating systems or, in the case of web applications, in multiple browsers?
• How adequate the financial costs are to the current state of the project?

Most of the presented tools are easy to integrate into standard software development chains, so even when you switch from NoCode to traditional development, you will be able to use your testing experience.