Unit 6: Web Testing Tools - Subjective Questions

Playwright is an open-source browser automation framework used for end-to-end testing of web applications. Its main features include:

• Support for Chromium, Firefox, and WebKit browsers.
• Support for JavaScript, TypeScript, Python, Java, and .NET.
• Automatic waiting for elements to become ready before actions are performed.
• Support for multiple pages, browser contexts, frames, popups, and downloads.
• Built-in screenshots, videos, tracing, and test reporting.
• Network interception and request mocking capabilities.
• Isolation through independent browser contexts.

These features make Playwright suitable for testing responsive, multi-browser, and highly interactive web applications.

The typical installation and configuration process is:

• Install Node.js and verify it using node --version and npm --version.
• Create a project directory and initialize it with npm init -y.
• Install Playwright Test using npm init playwright@latest or an equivalent package command.
• Select the programming language, test directory, and whether to add a continuous integration workflow.
• Install the required browser binaries using npx playwright install.
• Configure playwright.config.ts with settings such as testDir, use.baseURL, browser projects, retries, workers, screenshots, and traces.
• Create a test file and execute it with npx playwright test.

The configuration file centralizes execution settings and makes tests consistent across local and CI environments.

Playwright provides locator-based methods for interacting with common controls:

• Text fields can be filled using locator.fill() or updated character by character with locator.pressSequentially().
• Checkboxes can be selected with check() and cleared with uncheck().
• Radio buttons can be selected using check().
• Buttons can be activated with click().
• The state of controls can be verified using assertions such as toBeChecked(), toBeEnabled(), or toHaveValue().

Example:
await page.getByLabel("Email").fill("user@example.com");
await page.getByLabel("Accept terms").check();
await page.getByRole("button", { name: "Submit" }).click();

Locators should describe the user-visible role or label whenever possible because they are more readable and maintainable than fragile selectors.

Dropdown handling depends on the HTML implementation:

• For a native <select> element, use selectOption() with a value, label, or option index.
• For a custom dropdown built with div or button elements, click the control and then click the visible option using a suitable locator.
• For multi-select controls, pass multiple option values to selectOption().
• Verify the selected value using expect(locator).toHaveValue() or verify the selected option text.

Example for a native dropdown:
await page.locator("select#country").selectOption({ label: "India" });

Example for a custom dropdown:
await page.getByRole("button", { name: "Country" }).click();
await page.getByRole("option", { name: "India" }).click();

The correct method must match the control's actual DOM behavior.

Playwright can capture screenshots of an entire page or a specific element. Common uses include debugging failures, visual validation, and test evidence.

• page.screenshot({ path: "home.png" }) captures the visible viewport.
• fullPage: true captures the complete scrollable page.
• locator.screenshot({ path: "component.png" }) captures a selected element.
• type: "jpeg" can be used when JPEG output is required.
• quality can be specified for JPEG screenshots.
• mask can hide sensitive or dynamic content.
• Test configuration can automatically capture screenshots on failure.

Example:
await page.screenshot({ path: "artifacts/home.png", fullPage: true });

Screenshots should use predictable file names and should avoid exposing confidential data.

An iframe contains a separate document embedded within the parent page. Playwright supports frames through FrameLocator and frame objects.

• Use page.frameLocator("iframe").locator("selector") to locate elements inside an iframe.
• Use page.frame({ name: "frameName" }) or inspect page.frames() when a frame object is required.
• Interact with the frame element after locating it, just as with elements in the main document.
• Nested frames can be addressed by chaining frame locators.

Example:
const paymentFrame = page.frameLocator("iframe[name='payment']");
await paymentFrame.getByLabel("Card number").fill("4111111111111111");

The main page locator cannot directly access elements inside an iframe because the frame has its own document context.

The terms represent different levels of browser isolation and navigation:

• A browser is the overall browser process.
• A browser context is an isolated session with its own cookies, local storage, and permissions.
• A page represents a browser tab or window.
• A popup is a new page opened by an action such as clicking a link with target="_blank".
• Multiple pages can exist in the same browser context.

A popup should be captured before the action that opens it:
const popupPromise = page.waitForEvent("popup");
await page.getByText("Open report").click();
const popup = await popupPromise;
await popup.waitForLoadState();

Contexts allow parallel tests to run independently without sharing authentication or application state.

Playwright represents JavaScript alert types as dialog events. The dialog must be accepted or dismissed, otherwise the page action that triggered it may remain blocked.

• Use dialog.accept() to accept an alert or confirmation.
• Use dialog.dismiss() to cancel a confirmation.
• Pass text to dialog.accept("response") for a prompt dialog.
• Use dialog.message() and dialog.type() to inspect the dialog.

Example:
page.on("dialog", async dialog => {
if (dialog.type() === "confirm") await dialog.dismiss();
else await dialog.accept();
});

For a single action, page.once("dialog", dialog => dialog.accept()) can be used. Dialog handlers should be registered before triggering the action.

A Playwright test normally contains a test declaration, browser fixture usage, actions, and assertions. Tests are organized in files such as login.spec.ts within the configured test directory.

Common commands include:

• npx playwright test to run all tests.
• npx playwright test login.spec.ts to run one file.
• npx playwright test --project=chromium to select a browser project.
• npx playwright test --headed to display the browser.
• npx playwright test --debug to run in debugging mode.
• npx playwright show-report to open the HTML report.

Tests can use fixtures such as page, browser, and context. Configuration controls retries, parallel execution, timeouts, reporters, and failure artifacts.

A locator identifies an element and provides operations and assertions for that element. Examples include getByRole(), getByLabel(), getByText(), getByPlaceholder(), and locator().

Playwright automatically waits for conditions such as:

• The element being attached to the DOM.
• Visibility and stability.
• The element being enabled for actions.
• Navigation or required action completion.

For example:
await page.getByRole("button", { name: "Save" }).click();
await expect(page.getByText("Saved successfully")).toBeVisible();

Auto-waiting reduces failures caused by timing assumptions. Semantic locators also make tests easier to understand and less sensitive to changes in layout or implementation.

Katalon Studio is an integrated testing platform that supports web, API, mobile, and desktop application testing. Its major features include:

• Record-and-playback testing for users with limited programming experience.
• Manual and script modes for combining visual workflows with code.
• Built-in keywords for browser actions and assertions.
• Object Repository for storing and reusing test objects.
• Object Spy for identifying web elements.
• Test suites and test suite collections for test organization.
• Support for CSS selectors, XPath, data-driven testing, and reports.
• Integration with CI tools and external test management systems.

It helps teams create maintainable automated tests while still allowing advanced users to add Groovy-based custom logic.

The installation process generally involves:

• Downloading the correct Katalon Studio package for the operating system from the official source.
• Installing or extracting the application according to the distribution format.
• Launching Katalon Studio and signing in or activating the required license.
• Creating a new project and selecting a project location.
• Configuring browser preferences, execution settings, and proxy settings when required.
• Installing or verifying browser drivers and ensuring supported browsers are available.
• Selecting a default execution profile and reviewing project settings.

Before test creation, the tester should confirm that the application is reachable, credentials and test data are available, and the selected browser can be launched successfully.

A typical recording workflow is:

• Open or create a Katalon project.
• Create a new test case and provide a meaningful name.
• Start the Web Recorder and select the target browser.
• Enter the application URL.
• Perform actions such as opening pages, entering values, clicking controls, and navigating menus.
• Allow Katalon to capture the actions and identify the related test objects.
• Stop recording and review the generated test steps.
• Rename objects and steps where necessary for clarity.
• Add verification checkpoints and save the test case.
• Execute the test and inspect the results.

Recording accelerates initial test creation, but the generated workflow should be reviewed and cleaned up before it is used as a maintainable regression test.

Verify Options add assertions that check whether the application produced the expected result. Common verification types include:

• Verify element is present or visible.
• Verify element is enabled or disabled.
• Verify text or attribute value.
• Verify page title or URL.
• Verify element is selected or checked.

For example, after submitting a login form, a verification can check that a dashboard heading is visible. A recorded click alone proves only that an action was attempted; it does not prove that the application behaved correctly. Verification steps convert a sequence of actions into a functional test by comparing actual results with expected results. They should be specific, stable, and related to the business requirement being tested.

Object Spy identifies web elements and stores their properties as test objects in Katalon's Object Repository. The process includes:

• Start Object Spy and select the target browser.
• Navigate to the required page.
• Capture an element such as a field, button, link, or message.
• Review its properties, including ID, name, class, text, and XPath.
• Select stable properties for object identification.
• Save the object with a meaningful repository name.
• Reuse the object in test cases and keywords.

Object Spy separates element definitions from test logic. If the page changes, the object can often be updated in one place instead of modifying every test step. Dynamic or unstable properties should be avoided when more reliable attributes are available.

A Test Suite groups related test cases so that they can be executed together. To create one:

• Open the Test Suites section and create a new test suite.
• Provide a meaningful name based on a feature, release, or testing objective.
• Add the relevant test cases from the project repository.
• Arrange their execution order when order matters.
• Configure execution settings and save the suite.
• Run the suite and review the combined results.

Test suites improve organization, reduce manual execution effort, and support regression testing. Examples include Login Tests, Checkout Regression, and Smoke Tests. A suite should contain tests with a clear relationship rather than becoming an unstructured collection of unrelated cases.

A Test Suite is a group of individual test cases that are executed as one logical set. It normally represents a feature, module, or testing purpose.

A Test Suite Collection is a higher-level group that combines multiple test suites and can execute them with shared settings. It may define:

• The suites to run together.
• The execution environment or browser.
• Parallel or sequential execution.
• The number of iterations.
• Scheduling or CI execution requirements.

For example, separate Login, Cart, and Payment suites can be combined into a Release Regression Collection. Suites provide test-case organization, while collections coordinate larger execution campaigns.

CSS selectors identify HTML elements based on attributes, element names, classes, IDs, and relationships. Examples include:

• #username for an element with a unique ID.
• .submit-button for an element with a class.
• input[name="email"] for an input with a specific name.
• form button[type="submit"] for a submit button inside a form.

A good selector should be:

• Unique enough to identify one element.
• Based on stable attributes rather than changing styles or generated classes.
• Short and readable.
• Independent of unnecessary parent-child levels.
• Validated in the browser before being used in a test object.

CSS selectors are usually concise and efficient, but they cannot directly select an element based on its visible text in the same flexible way as XPath.

XPath is a path expression used to locate elements in an XML or HTML document. Examples include:

• Relative XPath: //input[@name="email"]
• Text-based XPath: //button[normalize-space()="Login"]
• Attribute-based XPath: //a[contains(@href,"account")]

An absolute XPath begins at the root, for example /html/body/div[1]/form/input[2]. It is highly dependent on the complete DOM hierarchy and breaks easily when the page structure changes.

A relative XPath begins with // and identifies an element using meaningful attributes, text, or relationships. It is generally more maintainable. XPath is useful when an element lacks a stable ID, when text must be matched, or when relationships such as an adjacent label must be used.

Both CSS and XPath can identify web elements, but they have different strengths.

CSS selectors:

• Are concise and commonly understood by web developers.
• Work well with IDs, classes, and attributes.
• Are often efficient for straightforward element selection.
• Are suitable when stable CSS-oriented attributes are available.

XPath expressions:

• Can locate elements using visible text.
• Support parent, child, sibling, and ancestor relationships.
• Can use functions such as contains() and starts-with().
• Are useful for complex DOM relationships or elements without stable attributes.

CSS is preferable for simple and stable selectors. XPath is preferable when text matching, structural relationships, or more complex conditions are required. In both cases, selectors should be unique, readable, and resistant to expected UI changes.