This section introduces the most frequently asked questions and tips for operation in the early stages of installation. If you have not yet used MagicPod, please refer to Started Guide first.
Table of Contents
-
Test Creation
- Not familiar with MagicPod-specific terms such as "UI", "UI elements", etc.
- Cannot select a UI element
- UI element you want to operate is off-screen
- Not sure which locator to use
- There are multiple operations that are performed over and over again across test cases, such as login
- Click on a specific position of a UI element
- Generate different strings for each execution
- Close an alert
- Move to a different tab or window
- Test a site with Basic authentication enabled
- Different options for "Open Browser" command
- Make test steps easier to manage
- Know what other commands are available
- Test Execution
- Test Management
- Other
Test Creation
Not familiar with MagicPod-specific terms such as "UI", "UI elements", etc.
Please refer to Start guide: 4 - 5. Description of terms for more information.
Cannot select a UI element
There is a possibility that other UI elements overlap with the UI element and cannot be selected. You can select the UI element you want to select by clicking Temporarily hide several times to hide the overlapping element.
If you still cannot select a UI element, you can send an inquiry by clicking Inquiry about this UI from the menu of the UI in UI List. Please refer to the help page about locators
Reference: About locators
UI element you want to operate is off-screen
With Element selection mode deactivated, scroll the cloud browser manually to display the UI element you want to manipulate on the screen. Then capture or start the element selection mode again to retrieve the element.
If you need to scroll repeatedly, it is recommended to capture the entire screen UI. With Element selection mode deactivated, check the Capture whole page checkbox, click Capture, and then retrieve the element.
When executed, even if you click elements that are off-screen, selecting the Click command for that element means that the click will be performed after it has automatically scrolled without adding the scroll commands.
Reference: Test screens where you need to scroll
Not sure which locator to use
Basically, the suggested locators are the first ones specified and recommended from the top of the list of candidates. Add a new locator if necessary, as a locator with a value that changes from run to run or a long locator will be unstable.
Reference: About locators / Add/Edit a locator
There are multiple operations that are performed over and over again across test cases, such as login
If multiple operations such as Input -> Click on the same screen appear in multiple test cases, you can define the operation as a Shared step so that it can be used as a single command from other test cases. When fixes are necessary, only a single fix of the content of the shared step is required, thus reducing the time and effort required for test case maintenance.
Reference: Utilize shared steps
Click on a specific position of a UI element
A UI element you want to manipulate is overlapped by another UI element.
You can click on the non-overlapping part of the UI element, such as the left edge.
A UI element not recognized by MagicPod
The UI element is intentionally placed outside of other recognizable UI elements nearby, such as at coordinates X=50,Y=200. (X=0,Y=0 for the upper left corner and X=100,Y=100 for the lower right corner)
This is only done when the "Cannot select a UI element" does not solve the problem, as it tends to be unstable.
The normal Click command operates by directly calling an event associated with a UI element, but the Click specified position command operates by clicking based on the apparent position, such as left edge or coordinates.
Reference: Click specified position
Generate different strings for each execution
You can use the Store unique value generated based on the current time command to create a different variable for each execution.
You can use the variable as it is or use it as Name_${Variable name}.
Close an alert
You can close an alert with the Close alert command.
The alert is a JavaScript alert dialog.
Other dialogs/popups/modals etc. can be recognized as UI elements and operated as usual.
Move to a different tab or window
You can use the Select new tab/window and Select previous tab/window commands.
Reference: Test separate tabs and separate windows
Test a site with Basic authentication enabled
For example, if you want to access https://example.com with user name user1 and password pass1 for Basic authentication, it can be accessed by using the URL https://user1:pass1@example.com.
Note: Test a site with basic authentication enabled
Different options for "Open Browser" command
Please refer to Open browser for differences in behavior.
Basically, (by first-time-only process restart), (by first-time-only process restart with clearing cookies), and (by process restart) are faster in that order, but not by much. For usage, select (by first-time-only process restart with clearing cookies) if you do not want to take over login information from the previous test when a batch run is performed, or (by process restart) if information remains in auth0 and so on.
Make test steps easier to manage
When you want to make a chunk of test steps easier to understand, you can use the Comment command to explain the contents, or the Blank line command to insert a blank line.
When you want to include a note, use the Comment command to highlight it with a pictogram.
Know what other commands are available
You can see all commands in Command List.
Test Execution
Get an error saying UI element not found
Put a wait time before the failed step.
Basically, it automatically waits until the screen has finished loading, but there are cases where the UI element cannot be found due to insufficient loading. In such cases, a command to wait until the UI element is visible/exists/equals, or a command to wait for a fixed value of X seconds, etc., can be placed before the failed step.
Reference: Wait command
Change the locator specified for the UI element of the failed step
When MagicPod searches for UI elements, it uses locators. For example, if the locator changes with each execution as shown below, the test will fail because the locator is different from the one used when the test was created. Therefore, it is necessary to change the locator from one of the proposed locators to another or add a new locator.
- Based on Amount/DateTime
e.g.) xpath=//output[text()='$70.00']
- Based on value, id, etc. that may change
e.g.) xpath=//input[@value='mp62130']
Reference: How to maintain a test when it fails - Fix an unstable test case
Cannot understand the contents even if you see the failure message
You may find a solution by searching for that failure message on the help page. If you cannot find it, or if it is difficult to identify the cause even after reading the help page, please contact us by clicking Inquiry about the test failure.
Reference: Inquiries About Test Failures
Inquire about a test failure
If you do not know the cause of the error, click the Inquiry about the test failure to inquire about it.
Reference: Inquiries About Test Failures
Run regularly based on a schedule
Use MagicPod's scheduled run feature to set up periodic execution.
Reference: Start guide: 3 - 1-1. Create MagicPod batch run settings
You can also call MagicPod's WebAPI with CI tools such as CircleCI, Bitrise, or Jenkins. In this case, you can also execute it every time it is pushed to Git.
Reference: Run tests regularly with CI services
Notify test results
You can be notified via email and Slack.
Alternatively, you can use MagicPod's WebAPI to send notifications to Teams, etc.
Batch run takes a long time
Parallel run
You can reduce execution time by running tests in parallel.
For more information, please refer to this page.
Capture only specific steps
By default, all steps are captured, but you can save time by capturing only specific steps.
Select Every UI transit or Failure capture only from Every step in the Runtime Screenshots field on the batch runs settings screen. If there is a specific step you want to capture, add the Take screenshot command after that step.
Execute with multiple browser patterns
You can run multiple browser patterns in parallel.
For more information, please refer to this page.
When running tests in parallel across multiple types of browsers and devices
Succeed in single run but fail in batch run
Internally, there is no significant difference in behavior between a single run and a batch run. Therefore, it is highly likely that the test is unstable or failing due to the influence of tests run before the target test.
Please refer to this page:
Tests that succeed in single run fail in batch run
Test Management
Manage test cases
We recommend using the Folder management feature and Labels to organize. Enabling the generative AI feature automatically displays test case descriptions in the test case list, making it easier to understand.
Reference: Test Case Summary Feature
Manage test results
- Use generative AI tools
- By using the MagicPod MCP Server together with generative AI tools such as Claude, you can automatically generate dashboards for test results management.
- Use cloud tools to manage test results (Testrail, QualityForward, etc.)
- By retrieving test results by MagicPod's WebAPI, results data can be automatically accumulated.
- Paste result captures and result URLs into Spreadsheet/Excel.
- You can download all result captures from the test results of a batch run. You can also selectively download by adding the Take screenshot command.
Reference: Manage test results
Divide and counting projects
It is recommended to assign one project to one product.
Reference: What Is a Project?
Shared UI and shared steps can be used between test cases in a project.
For example, since the development environment and the production environment will have only one target product, we recommend that you do not separate projects, but share test cases. The execution environment can be changed by changing the base URL from the settings.
Reference: Switching Test Execution Environments (Switch Domain to Use Test Case)
Other
Which items to start creating tests from
First, create tests for basic features such as login, and payments, which pose the greatest risk for quality assurance.
Once you have several test cases, run them daily. When you run the tests every day, you will encounter various problems that you were not aware of until you started running the tests, such as test stability. As you solve these problems, you gradually increase the number of tests.
After that, you will cover a wide and shallow range of features and screens. Rather than automating the manual test cases at hand in order from the top to the bottom, it is more efficient to prioritize and automate only the basic test cases first.
Reference: Start guide: 5. Establish test automation habits as quickly as possible (Browser)
Another method of prioritization is to weight test items based on their suitability for automation and compare the scores.