Getting Started with Katalon Studio

Katalon Studio is a desktop test automation environment for web, mobile, desktop, and API testing. For a first web test, install and activate Studio, create a Web project, record a short interaction with the Web Recorder, save the test and its captured objects, run it locally, and inspect the execution log and report. This guide follows Katalon’s official quick guide for testers.

1. Install and prepare Katalon Studio

You need a Katalon account and a downloaded, activated copy of Katalon Studio. The installation guide covers macOS, Windows, and Linux. It lists a valid email address and an active internet connection as download requirements. Check the current supported environments before installing, since operating system and browser support can change.

Create or sign in to your Katalon account.
Download the Studio edition and package for your operating system using Katalon’s official download page.
Install or extract the package following the platform instructions, then launch Studio and activate it.
On Linux, the cited installation instructions specify OpenJDK 21. Follow that guide for the supported distribution and verify the selected Java runtime with java -version. This platform-specific instruction should not be treated as a universal Java requirement for macOS and Windows.

On Windows, the installation guide calls out write permission when extracting outside the user folder. On Linux, it describes selecting OpenJDK 21 if multiple Java versions are installed. If launch fails, check the current installation guide for the operating system and Studio release you are using.

2. Create your first project

In Studio, select File > New > Project. Enter a project name, choose a project type, choose a blank or sample project, select a location, and optionally add a description. Click OK.

Project type	Use it when
Web	You are automating a browser based application.
Mobile	You are testing a mobile application or mobile workflow.
Desktop	You are automating a desktop application.
API / Web Service	You are testing service endpoints rather than interacting with a browser UI.
Generic	You want a general project structure and will choose the workflow yourself.

Project types and the available options can vary by Studio version. A blank project can optionally include a .gitignore file or a build.gradle file. A sample project is useful for exploring an existing test structure; a blank project keeps your first exercise focused on your own test.

3. Record a first web test

The quick guide uses the CURA Healthcare Service demo at https://katalon-demo-cura.herokuapp.com/. Use the public demo only for learning; use an environment you are authorized to test for your own application.

Click Record Web in the main toolbar.
Enter the demo URL and choose a browser in the recorder. The quick guide uses Chrome.
Click Record and wait for the browser and page to open.
Interact with the page as a user would. In the quick guide’s example, click Make appointment, enter the demo credentials provided by the demo or current official tutorial, and click Login.
Verify the resulting page by hovering over the Make appointment heading and choosing the recorder’s Verify Element Present action.
Close the browser, stop recording, and choose Save script.
Choose or create a folder in the Object Repository for the captured objects, then name the test case. The recorded actions and objects appear in the test case editor.

The Web Recorder captures the browser interactions as test steps and saves the interacted-with elements as test objects. Those objects let the test refer to page elements when it runs. Review the generated steps and object locators; a recording is a starting point, and it may need editing if the page changes or if the recorded flow includes unnecessary actions.

Recording choices

The recorder supports launching a new browser or using an active browser. The official recorder documentation lists Chrome, Chrome with Profile, Firefox, and Edge Chromium among new-browser options, with Internet Explorer available only on Windows in the cited documentation. Active Browser mode uses a browser with the Katalon Recorder add-on installed. Available choices can differ by Studio version and installed browser.

To set the default execution browser, the recorder documentation points to Project > Settings > Execution > Default execution. For a one-off capture, select the browser in the Record dropdown beside the URL field.

4. Run the test and read its result

Save the test case, select a browser from the run control, and click Run. Start with local execution so you can observe the browser and diagnose the first failures. Inspect the execution log for the step that failed, its error, and the associated test object. Studio generates execution reports; the execution documentation lists JUnit, HTML, PDF, and CSV formats, with some report options depending on whether you execute a test case or suite.

Confirm the test case and project are saved.
Select the intended browser and execution environment from the Run control.
Run the case and watch for the browser to launch and perform the recorded actions.
When execution ends, open the log and locate the first failed step. Later failures can be consequences of that first failure.
Open the generated report for a readable summary; use the detailed log to investigate failures.

As the test grows, put related cases into a test suite and run the suite. Katalon’s execution guide describes running cases and suites. For automation outside the Studio UI, Runtime Engine provides a command-line execution path; its setup and licensing requirements are covered in the Runtime Engine guide. Cloud execution is another documented path, but access and plan terms can change, so check Katalon’s current subscription information before choosing it.

5. Make the test easier to maintain

Keep the test focused. Start with one user outcome and a small number of steps.
Review captured objects. Give object folders and test cases names that explain their purpose. Check locators when a test fails after a page change.
Separate test data from test logic. Avoid embedding real passwords or personal data in a recording. The recorder documentation says it uses the Set Encrypted Text keyword when typing into a password field; still review how credentials are managed for your project and execution environment.
Use the editor to refine recordings. Remove accidental clicks, add meaningful verification steps, and keep only the actions needed to prove the expected behavior.
Choose the project type deliberately. For mobile, desktop, API, or BDD testing, use the corresponding workflow rather than stretching a web recorder tutorial to cover another project type.

6. Common problems and fixes

Symptom	Likely cause	What to check
Studio does not launch after installation.	Unsupported environment, incomplete extraction, permissions, or an unsuitable runtime configuration.	Check the current supported-environments and installation pages for your OS and version. On Windows, verify read/write access to the extracted folder. On Linux, follow the documented OpenJDK 21 setup.
The recorder cannot launch a browser.	The browser is missing, unsupported, or blocked by a version-specific recorder issue.	Choose another supported browser in the Record dropdown, check the recorder documentation, and confirm your Studio and browser versions.
Recording fails with Chrome 142.	Katalon’s warning applies to Studio versions 8.x and 9.x: Chrome 142 stopped supporting unpacked extension loading at runtime, affecting new-browser recording.	Check the current recorder support page against your actual Studio version. The cited workaround is Edge Chromium, Firefox, or Active Browser mode. Do not assume this version-specific warning applies to all Studio releases.
A test step cannot find an element.	The page has not finished loading, the element changed, or the saved locator no longer identifies it.	Inspect the failed step and captured object, verify the page state, and update the object or add an appropriate wait before interacting.
The test passes while recording but fails during a later run.	Timing, changed page content, browser differences, or different test data can alter the flow.	Reproduce with the same browser and data, inspect the first failed step, and make the wait and verification reflect the page’s actual behavior.
The report is missing a desired format.	Some formats are available only for particular execution report types or settings.	Check the execution and report documentation. Katalon’s guide notes CSV and PDF availability for test suite reports in the described reporting settings.

7. Performance, reliability, and cost considerations

A local run is the simplest way to learn because the browser is visible and the execution log is close at hand. Browser startup, page response time, test data, and synchronization all affect how long an end-to-end UI test takes. Keep the initial flow small, wait for the state you need before acting, and avoid repeating setup steps unnecessarily. A longer test that spans many unrelated behaviors is harder to diagnose when it fails.

For repeatable execution, keep the project, browser choice, and test data controlled. Use suites when you need to run related cases together. If you need headless or CI execution, review the Runtime Engine requirements and licensing before building the pipeline. Cloud execution and paid plan terms are time-sensitive; the cited getting-started guide does not establish a current price comparison, so consult Katalon directly.

Or skip the browser setup

If the immediate task is getting a clean website screenshot for a test artifact or visual review, ScreenshotNeo is a website screenshot API and MCP server. It does not replace Katalon’s interactive browser testing; it can return a screenshot or PDF from one request. See the ScreenshotNeo API documentation for the options and response details.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await Bun.write('shot.webp', res);

ScreenshotNeo removes cookie and consent banners, newsletter popups, and chat widgets before capture; each cleanup step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server gives AI agents tools for screenshots, page information, and PDF capture. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 screenshots.

8. What to learn next

After the first case runs successfully, create a test suite, add additional cases, and learn how to debug and organize test objects. The Katalon Help area includes onboarding tours, video demos, and online courses from beginner to advanced; see Katalon Help. For project types beyond web, follow the dedicated Mobile, Desktop, API, or BDD documentation linked from the quick guide.

FAQ

Do I need to know programming to make my first test?

The Web Recorder can create test steps from browser interactions. Reviewing and maintaining tests is easier when you learn how objects, waits, and verification steps work.

Can I start from a sample project?

Yes. The New Project dialog offers blank and sample project choices. The project type and sample determine which workflow and files you begin with.

Can I run a Katalon test without opening Studio?

Yes. Katalon documents command-line execution through Runtime Engine. Check its current setup, environment, and license requirements before using it in CI.

Is ScreenshotNeo a replacement for Katalon Studio?

No. Katalon Studio records and runs interactive tests. ScreenshotNeo captures a page as an image or PDF through an API or MCP server, which is useful when you need a capture rather than a browser interaction test.