Unit 6: Web Testing Tools

I. Orientation — Principles of Web UI Automation

Web testing tools automate interactions with browsers to verify that web applications behave correctly. They locate page elements, perform user actions, observe application responses, and compare actual outcomes with expected outcomes.

• Core workflow: A test normally follows arrange, act, and assert:
  • Arrange: Open the browser, prepare data, and navigate to a URL.
  • Act: Click, type, select, upload, or switch browsing contexts.
  • Assert: Verify text, visibility, URL, state, or another expected result.
• Element identification: Tools locate elements through semantic roles, labels, text, CSS selectors, XPath expressions, or stored object definitions.
• Synchronization: Modern tools wait for elements to become actionable; explicit waits remain useful for application-specific conditions.
• Isolation: Independent tests reduce order-dependent failures and simplify parallel execution.
• Repeatability: A test must produce consistent results under the same environment, data, and application state.
• Evidence: Reports, screenshots, traces, videos, and logs help diagnose failures.
• Tool models: Playwright is primarily a code-first browser automation framework, while Katalon Studio combines recording, object repositories, keywords, scripting, and graphical test management.

II. Playwright — Code-First Cross-Browser Automation

Playwright is an open-source automation framework developed by Microsoft. It controls Chromium, Firefox, and WebKit through one API and supports JavaScript, TypeScript, Python, Java, and .NET.

A. Introduction to Playwright tool

Playwright provides browser automation with automatic waiting, isolated contexts, resilient locators, and integrated test-runner capabilities.

• Browser coverage: The same test logic can target Chromium, Firefox, and WebKit.
• Browser contexts: A context is an isolated browser session with separate cookies, storage, and permissions; it is faster than launching a new browser process.
• Locator model: getByRole(), getByLabel(), and getByText() describe elements through user-visible semantics.
• Auto-waiting: Before actions such as click(), Playwright checks whether the target is attached, visible, stable, and enabled.
• Assertions: Web-first assertions such as toBeVisible() retry until they pass or reach their timeout.
• Typical structure:

import { test, expect } from '@playwright/test';

test('page title', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page).toHaveTitle(/Example/);
});

B. Installation and configuration of Playwright

A Playwright project requires a supported Node.js installation, the test package, browser binaries, and a configuration file.

• Project creation: The initializer creates example tests and playwright.config.ts.

npm init playwright@latest

• Existing project: Install the runner and browser binaries separately.

npm install -D @playwright/test
npx playwright install

• Configuration: playwright.config.ts defines test directories, retries, reporters, timeouts, and browser projects.

import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  testDir: './tests',
  use: { baseURL: 'https://example.com', trace: 'on-first-retry' },
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } }
  ]
});

• Environment separation: Base URLs and credentials should come from configuration or environment variables, not hard-coded test steps.

C. Handling Inputs

Playwright handles text fields, checkboxes, radio buttons, file inputs, and keyboard-driven controls through locator actions.

• Text input: fill() replaces existing content, whereas pressSequentially() emits individual key events.
• Binary controls: check() and uncheck() establish the requested state without an unnecessary click.
• File upload: setInputFiles() assigns one or more files to an <input type="file">.
• Verification: Assertions confirm the resulting value or checked state.

await page.getByLabel('Email').fill('student@example.com');
await page.getByLabel('Accept terms').check();
await expect(page.getByLabel('Email')).toHaveValue('student@example.com');
await expect(page.getByLabel('Accept terms')).toBeChecked();

• Preferred targeting: Labels and roles usually remain more stable than selectors based on layout classes.

D. Handling Dropdowns

Dropdown handling depends on whether the control is a native HTML <select> or a custom component.

1. Native dropdown: Use selectOption() with an option value, label, or index.

await page.getByLabel('Country').selectOption({ label: 'India' });
await expect(page.getByLabel('Country')).toHaveValue('IN');

2. Custom dropdown: Click the trigger and then select the visible option by role or text.

await page.getByRole('combobox', { name: 'Country' }).click();
await page.getByRole('option', { name: 'India' }).click();

• Multiple selection: Pass an array, such as selectOption(['html', 'css']), when the native element has the multiple attribute.
• Validation: Verify the selected value or displayed option rather than assuming the action succeeded.

E. Capturing Screenshots

Screenshots preserve visual evidence of a whole page, viewport, or individual element.

• Page screenshot: page.screenshot() captures the current viewport by default.
• Full-page mode: { fullPage: true } includes scrollable content.
• Element capture: locator.screenshot() limits output to a selected element.
• Example:

await page.screenshot({
  path: 'screenshots/checkout.png',
  fullPage: true
});
await page.getByRole('main').screenshot({
  path: 'screenshots/checkout-main.png'
});

• Failure evidence: Configuration can automatically retain screenshots only when tests fail using screenshot: 'only-on-failure'.
• Visual testing: expect(page).toHaveScreenshot() compares current rendering with an approved baseline; stable data and animations improve reliability.

F. Handle Frames and iFrames

A frame is an independent document embedded within a page, so its elements must be located through the correct frame context.

• Recommended API: frameLocator() locates an iframe and continues with normal locator operations.
• Concrete example:

const paymentFrame = page.frameLocator('#payment-frame');
await paymentFrame.getByLabel('Card number').fill('4111111111111111');
await paymentFrame.getByRole('button', { name: 'Pay' }).click();

• Named frames: page.frame({ name: 'payment' }) returns a Frame object when direct frame APIs are needed.
• Nested frames: Chain frame locators according to the document hierarchy.
• Boundary rule: A locator created from page cannot directly find content inside an iframe.

G. Handling Windows, Tabs and Popups

New windows, tabs, and popups are represented as additional Page objects within a browser context.

• Event ordering: Begin waiting for the new page before performing the action that opens it.
• Popup example:

const popupPromise = page.waitForEvent('popup');
await page.getByRole('link', { name: 'Open report' }).click();
const popup = await popupPromise;
await popup.waitForLoadState();
await expect(popup).toHaveURL(/report/);

• Context-level pages: context.waitForEvent('page') detects a new page that may not be directly tied to one opener.
• Independent control: Each Page supports navigation, locators, assertions, screenshots, and closing.
• Synchronization: Use load states or web assertions instead of fixed delays after opening a tab.

H. Handling Alerts in Playwright

JavaScript alerts, confirms, and prompts generate a dialog event that must be accepted or dismissed.

• Dialog types: alert, confirm, prompt, and beforeunload are available through dialog.type().
• Accepting: dialog.accept() confirms an alert; for prompts, dialog.accept('value') supplies text.
• Dismissing: dialog.dismiss() represents Cancel or rejection.
• Example:

page.once('dialog', async dialog => {
  expect(dialog.message()).toBe('Delete record?');
  await dialog.accept();
});
await page.getByRole('button', { name: 'Delete' }).click();

• Timing rule: Register the handler before the triggering action because dialogs block page interaction.
• Default behavior: Playwright automatically dismisses dialogs when no listener is registered, but explicit handling is required when dialog behavior is under test.

I. Running Playwright Tests

The Playwright CLI discovers tests, schedules workers, selects configured projects, and produces results through reporters.

• Run all tests:

npx playwright test

• Targeted execution: Use a file path, --grep, or --project=chromium to narrow execution.
• Visible debugging: --headed displays browsers; --debug opens Playwright Inspector with step controls.
• Reports: npx playwright show-report opens the generated HTML report.
• Parallelism: Test files run in worker processes; shared mutable data can therefore create collisions.
• CI execution: Retries, traces, screenshots, and reduced worker counts can be configured specifically for continuous integration.

III. Katalon Studio — Integrated Keyword and Script Automation

Katalon Studio is an automation platform built around Selenium and related technologies. It supports web, mobile, API, and desktop testing through manual steps, recorders, reusable keywords, Groovy scripts, object repositories, suites, and reports.

A. Introduction to Katalon Studio

Katalon Studio combines low-code authoring with script-level customization for testers with different programming experience.

• Test cases: Store executable keyword steps or Groovy code.
• Object Repository: Stores reusable Test Object definitions and locator properties.
• Keywords: Built-in web keywords include openBrowser, navigateToUrl, click, setText, and verifyElementPresent.
• Execution profiles: Hold environment-specific global variables such as base URLs.
• Reports: Record passed, failed, error, and incomplete execution results.
• Extensibility: Custom keywords allow shared Groovy methods to be added when built-in keywords are insufficient.

B. Installing Katalon Studio

Installation involves obtaining the appropriate distribution, extracting or installing it, activating the product, and validating browser support.

• Prerequisites: Use a supported Windows, macOS, or Linux version with adequate memory and disk space.
• Distribution: Download the edition matching the operating system and processor architecture.
• Startup: Launch the executable, sign in to a Katalon account, and complete licensing or activation.
• Browser setup: Install supported browsers and permit required drivers or extensions where applicable.
• Verification: Create a web project and run a minimal test that opens and closes a browser.

WebUI.openBrowser('')
WebUI.navigateToUrl('https://example.com')
WebUI.closeBrowser()

C. Writing test case using Katalon Recording with Verify Options

Web Recorder captures browser interactions as editable test steps, while verify options add checkpoints for expected behavior.

• Recording process: Create a test case, start Web Recorder, enter the application URL, interact with the page, and save captured objects and actions.
• Generated steps: Typing and clicking may become WebUI.setText() and WebUI.click() calls.
• Verify options: Add checks such as verifyElementPresent, verifyElementText, or verifyElementVisible.
• Concrete checkpoint:

WebUI.verifyElementText(
    findTestObject('Page_Result/lbl_Status'),
    'Order confirmed'
)

• Review requirement: Replace unstable generated selectors, remove accidental actions, and confirm that assertions test meaningful outcomes.
• Verify versus assert: Verification commonly records failure while allowing execution to continue; failure handling settings determine whether a step stops the test.

D. Work with Object Spy

Object Spy inspects a live application and captures element attributes for storage in the Object Repository.

• Capture flow: Launch Object Spy, open or attach to the browser, highlight an element, capture it, and save the test object.
• Properties: Common attributes include id, name, class, text, href, and XPath.
• Selector quality: Prefer unique, stable attributes connected to meaning; avoid dynamic IDs and long absolute paths.
• Repository benefit: Updating one shared object can repair multiple test cases that reference it.
• Validation: Highlight or verify the stored object to ensure its selector identifies the intended element uniquely.

E. Create Test Suite

A test suite groups test cases for ordered or parallel execution under shared settings.

• Creation: Add a Test Suite artifact and insert selected test cases into its Test Case List.
• Configuration: Choose browser type, execution order, retries, and failure-handling behavior.
• Data binding: Connect test data columns to test-case variables for repeated execution with different records.
• Lifecycle: Suite setup and teardown logic can prepare and clean shared resources.
• Result scope: A suite report consolidates the status and duration of its included test cases.

F. Create Test Suite Collection

A test suite collection coordinates multiple test suites, often across browsers, environments, or execution strategies.

• Composition: Each collection entry references an existing suite and specifies its execution configuration.
• Sequential mode: Suites run one after another when order or limited resources matter.
• Parallel mode: Independent suites run concurrently to reduce total execution time.
• Cross-browser use: The same regression suite can be assigned to Chrome, Firefox, and Edge entries.
• Constraint: Parallel suites require isolated accounts, test data, and environments to prevent interference.

G. Use CSS and XPath in Katalon Studio

CSS and XPath are locator strategies used by Katalon test objects when stable identifiers or recorded properties are unavailable.

1. CSS selectors: CSS is concise for IDs, classes, attributes, and hierarchy.

form#login input[name="username"]
button[data-testid="submit"]

2. XPath expressions: XPath supports text matching, ancestor traversal, and complex relationships.

//button[normalize-space()='Submit']
//label[normalize-space()='Email']/following::input[1]

• Relative locators: Prefer selectors anchored to stable attributes over absolute expressions such as /html/body/div[2]/form/input.
• Uniqueness: A locator should normally resolve to exactly one intended element.
• Trade-off: CSS is often shorter and easier to maintain; XPath is more expressive when locating by text or document relationships.
• Katalon usage: Set the test object’s selector method, enter the CSS or XPath expression, validate it, and reference the object through findTestObject().