FAQ

FAQ

What types of testing do you have?

We provide comprehensive testing for a range of products, including web UI testing, mobile web testing, mobile native and hybrid app testing, API testing, and database testing.

• Web UI Testing: Our web UI testing allows for cross-browser testing, ensuring that the application is running properly across multiple platforms.

• Mobile Web Testing: We offer testing for mobile websites, ensuring that the website is running properly on multiple mobile devices.

• Mobile Native and Hybrid App Testing: We test mobile native and hybrid apps on emulators, as well as on physical devices. This helps to ensure that the application is performing as expected on both emulators and physical devices.

• API Testing: API testing allows us to make sure that the API is functioning properly and that the API calls are returning the expected data.

• Database Testing: Our database testing checks that the database is functioning properly and that data is being stored and retrieved correctly.

What is your testing approach?

Unlike our competitors, we have one approach to absolutely all types of testing. The structure of scripts, commands, and their parameters - everything is identical both in WebUI and in API, Mobile or other types of testing. This means that testers do not have to waste time customizing scenarios depending on the type of testing. The same approach even allows combining several types of testing within one scenario. This is advantageous because it not only saves time, but it also ensures that the testing process is thorough, accurate, and comprehensive. With this approach, testers can be sure that all aspects of the testing process have been fully evaluated and that no crucial details have been overlooked.

Is it possible to integrate your framework with our pipeline?

Testlum is designed to seamlessly integrate with various CI/CD pipelines. We understand the importance of having a smooth and efficient pipeline for your development process, which is why our tool is compatible with a wide range of popular CI/CD tools such as Jenkins, GitLab CI/CD, CircleCI, Travis CI, Bamboo, and Azure DevOps.

Additionally, Testlum can be customized to fit your specific pipeline requirements. Regardless of the tool you use, our tool can be integrated giving you the flexibility to choose the tool that works best for you.

Why it's No Code Tool?

QA Engineers do not need to learn separate libraries or tools (such as Selenium, Appium, Postman, DB drivers), do not need to learn a programming language and write the code, which is necessary to work in the above-mentioned tools - all this can be done within Testlum by learning only the functionality of necessary commands and understanding the approach to writing scenarios.

Basic knowledge of the XML markup language, which Manual QA should know even only for manual testing, allows you to write full-fledged scripts and automatic tests without using any of the programming languages and, accordingly, without writing code, as Automation QA does, regardless of the type of testing.

By the way, in the vast majority of our competitors, as soon as you need to test APIs or databases, the tester needs to write code in one of the programming languages (Java, Python, JS).

Dynamic React Elements

Q: Dynamic IDs: how to handle it. More specifically: ServiceNow is using a new UI for a couple of years and, a very similar, same approach: each time that page renders, it’s a different ID - how we can add automation to that?

For each component that you have inside the React, you can put this part of your UI inside the static container so it will have a fixed ID. Maybe internally it will render the dynamic ID part, but inside this dynamic ID part, you will have a predefined container and component. So if everything changes around this component, this won’t affect this container. Because we’ll find this container by the direct ID number so you don’t need to use XPATH to define this container.

Under the hood of our tool, we use Selenium that’s why we use all the possibilities with JavaScript, XPATH - everything to have access to the standard DOM inside the browser so if it’s technically possible to do it from the command line from the browser with help of jQuery or standard JS libraries - we can do this as well.

The tool is a layer that calls direct driver (Selenium driver in this case).

Regarding dynamic React elements, it’s a generic question about how to work with DOM structure but not with our tool.

How does it run?

It runs in Jenkins, you can split it by components (such as back-end, front-end, etc.). For instance, the back-end component reflects the API calls database execution, working with queue variables and so on.

Then you'll receive the log in JSON kind of view.

You can also see the reports in Testlum Reporting Tool.

What does it look like when tests fail?

You can find all failed test cases and all details in Testlum Reports. Also, here you can find full information about both passed and failed test cases (scenarios), execution time and other useful information.

Usual time frame for setup?

Usually it takes up to 2 weeks to setup, configure Testlum. The time frame for setting up Testlum largely depends on the complexity of the project and the size of the business. If the project is extensive and requires a lot of functionality coverage, the setup may take longer than two weeks. On the other hand, if the project is not complex and covering all required functionality does not take much time, the setup period may be shorter.

Use case driven: how are you managing and alternate flow or an exception flow?

In the RESOURCES folder structure, there is a "Scenarios" folder, which contains all the scenarios for the project. With the help of the subfolder structure of this folder, you can sort all the scenarios, or alternative, negative flows for each scenario in a convenient order and in convenient groups and subgroups.

From a data set perspective, we use a variation file. With the help of variations, you can dynamically inject a different set of data into the same script. This eliminates the need to repeatedly copy and paste the same scenario. Instead, you can simply use a CSV file as a basis for different data inputs.

Does Testlum has a scheduler?

Short. Yes, you can set when you want the automation to run on the recurring basis. Or you can integrate the scheduler into your CI/CD pipeline (for example, in Jenkins) by the trigger.

Long. Testlum has a flexible scheduler that allows you to create custom schedules for your automated tests. With this feature, you can specify the exact times and days when you want the tests to run. The platform's scheduler also supports recurring schedules, so you can set up tests to run automatically on a daily, weekly, or monthly basis.

Furthermore, Testlum's scheduler is highly configurable, meaning you can adjust it to meet the unique needs of your test suite. Users can create multiple schedules and assign them to different test suites or test cases, enabling you to organize your test runs efficiently.

In addition to the built-in scheduler, you can also integrate Testlum with your CI/CD pipeline, such as Jenkins. This integration allows you to trigger automated tests in response to certain events, such as a code commit, a build, or a deployment. This means that you can streamline your testing process and ensure that your code is always up to standard before it's released into production.

How the regression looks like?

So regression looks like the table with a components as a columns and runs as a rows. It's eliminated as a full regression. It spin ups all the components (back-end components, admin panel, front-end), which should have inside the system.

Do you support Chrome extensions? Any experience with testing those?

Yes, we support testing Chrome extensions with Testlum using the Selenium driver, allowing us to interact with the UI and use the same commands and scenarios as for other testing types. Our platform includes automated testing tools, enabling us to deliver high-quality testing regardless of extension complexity.

When you're creating test scenario, how are you managing and alternate flow or an exception flow?

To manage alternate or exception flows when creating test scenarios, we divide the process into positive and negative cases. For positive scenarios, we describe the expected flow and results. For negative scenarios, we outline potential issues and expected error messages. We create detailed test cases with input data and configurations to trigger expected errors, ensuring a robust system.

What if we need to test different data variants within the same scenario?

To test different data variants within the same scenario, we can use variation files. By adding a variation file, we can inject new data sets dynamically without having to copy and paste the scenario. CSV files work well for this purpose, allowing us to easily change test data and add new data sets. Variation files save time and ensure thorough testing with different data inputs.

Does Testlum have settings? How to configure it?

To configure Testlum, a 'global-config.xml', 'ui.xml', and 'integration.xml' files are used. These files allow you to configure the environment (one or several, in the case of using parallel execution), connect to integrations and databases, and specify the behavior of the scenario (e.g., using the command to control the passage of your test scenarios). Additionally, you can configure cross-browser compatibility, connect the required browsers, specify delays between scenarios, and more.