How to Get Started with Automation Testing

Start automation testing by choosing one important behavior with an observable result, then write a small test that prepares known state, performs an action, and checks what changed. Use a browser test only when the browser itself is part of what you need to verify; many logic checks belong in faster unit or integration tests.

This guide uses Playwright with JavaScript for a complete first example. The same approach applies with Selenium or Cypress: match the tool to your existing language, browser needs, and debugging workflow rather than assuming one framework is right for every project.

1. Decide whether the behavior needs a browser

Browser tests exercise the application as a user sees it, which can uncover problems across the frontend and backend. They also take more setup and infrastructure than lighter tests. Selenium’s guidance starts with the question, “First, start by asking yourself whether or not you really need to use a browser.” It recommends considering unit tests or lower-level checks when those can answer the question. Selenium: Overview of Test Automation

Good first browser-test candidates include signing in, submitting a form, adding an item to a cart, or confirming that a menu opens and exposes the expected content. A pure calculation, input validation rule, or data transformation often does not need a real browser.

• Use a unit test for a small function or business rule.
• Use an integration test when you need to check cooperating application components or an API boundary.
• Use a browser test when the user-visible interaction, browser rendering, navigation, or end-to-end wiring matters.

Pick one narrow, frequently used behavior with a result you can observe. Avoid starting with a long journey that signs up, configures an account, checks out, and changes settings in one test. If it fails, a large scenario makes the cause harder to identify.

2. Choose a framework that fits your project

Begin with the language already used by your project if practical. Then consider the browsers you need to cover, how the tool runs and debugs tests, and how it fits the application’s development workflow. The official guides describe different approaches; they do not establish one universal winner.

Tool	What its official guidance illustrates	Good questions to ask
Playwright	Tests use fixtures such as a page and built-in assertions. Writing tests	Does its test and assertion model fit your project? Check the current official install and browser support guidance for your setup.
Cypress	The first-test guide walks through visiting a page, finding an element, interacting, and asserting the result. Its app-testing guide recommends starting the development server separately. First Cypress test · Testing your app	Does the documented run and debug workflow fit your application and how you want to work?
Selenium WebDriver	WebDriver is a language-neutral browser-control interface. Getting started involves a language binding, a browser, and a browser driver; Selenium also documents Selenium IDE as a record-and-playback introduction. Getting started	Does your project need the WebDriver workflow and language ecosystem? Would IDE help you explore the basics?

Choose one framework and follow its current official first-test instructions. Avoid comparing tools by unsupported claims about popularity, speed, or reliability; the right choice depends on your stack and needs.

3. Set up a first Playwright test

The following example assumes Node.js is already installed and uses Playwright Test. In your project directory, install the test package and its browser binaries using the current official installation instructions. Package versions and browser installation details can change, so consult Playwright’s getting-started guide for the latest commands.

npm init playwright@latest

Follow the installer prompts. It creates a test configuration and an example test. To keep the first test easy to understand, create tests/homepage.spec.js with this complete example:

const { test, expect } = require('@playwright/test');

test('example page shows its main heading', async ({ page }) => {
  await page.goto('https://example.com');
  await expect(page.getByRole('heading', { name: 'Example Domain' })).toBeVisible();
});

Run the test with:

npx playwright test tests/homepage.spec.js

This visits a public example page, finds its heading by accessible role and name, and asserts that it is visible. For a project test, replace the URL with your local application URL and the heading with a meaningful result from your own workflow. Prefer a user-visible outcome over checking implementation details.

For a local application, start the development server in a separate terminal using the project’s normal command, then run the test. Cypress explicitly recommends starting its app server separately instead of trying to launch it from within Cypress scripts; this also keeps the server lifecycle clear when learning. Configure a framework’s built-in web-server support later if it fits your workflow.

4. Build the test around a clear behavior

A dependable first test follows three steps: arrange known data or application state, perform one or two meaningful actions, and assert the result. This matches the basic flow described in Cypress and Selenium documentation. Cypress first-test flow · Selenium test flow

1. Arrange: make the starting state predictable. Use a dedicated test account or test data where available. If your system has a supported API for preparing data, it may be simpler than navigating through setup screens in every test.
2. Act: perform the smallest user action that exercises the behavior, such as submitting a form or opening a menu.
3. Assert: check a visible, meaningful result, such as a confirmation message, changed status, or destination heading.

Use accessible locators such as roles and labels when they describe what a user would perceive. If your application provides dedicated stable test attributes, they can be appropriate for elements without a useful accessible name. Avoid selectors tied to incidental styling classes or deeply nested markup; those can change during unrelated interface work.

Give each test one clear reason to exist, use a descriptive test name, and keep actions short. Independent tests are easier to diagnose and less likely to depend on leftover state from another test.

5. Make the first test repeatable

A test that passes only when run immediately after manual setup is not a dependable automation check. Make its starting conditions explicit and avoid relying on data created by an earlier test.

• Use a test environment and data that can be reset or recreated.
• Give each test the state it needs; do not depend on execution order.
• Wait for a condition that matters, such as a result becoming visible, instead of adding arbitrary pauses.
• Keep external services and network dependencies in mind. Where appropriate, provide controlled test data or mock a service instead of relying on an unrelated system.
• When a failure occurs, inspect the assertion, browser state, and test output before adding retries or longer timeouts.

Do not automate every manual check immediately. Selenium’s guidance notes that automation may be a poor short-term investment when the interface is about to change considerably or there is not enough time to build it. Start where repeatability and user impact justify the maintenance.

6. Grow coverage in small steps

Once the first test is clear and repeatable, add a second test for another behavior rather than expanding the first into a complete user journey. Add browser coverage when a real requirement calls for it, such as validating more than one browser or running checks in continuous integration.

1. Run the test locally and confirm that it can start from a clean state.
2. Add it to the project’s normal test command or CI workflow when the team is ready.
3. Choose browser and operating-system coverage from actual support requirements. Cross-browser matrices increase setup and execution work, so do not add them without a reason.
4. Keep logs, failure output, and any screenshots or traces produced by your framework where your team can inspect them.
5. Review tests as application behavior changes; remove checks that no longer protect a meaningful user outcome.

7. Troubleshooting a first automation test

Symptom	Likely cause	What to do
Browser executable or driver is missing	The framework package is installed, but required browser binaries or a browser driver are not available.	Follow the framework’s current browser installation instructions. For Selenium, confirm the selected language binding, browser, and driver setup; Selenium Manager is documented as managing drivers and browsers by default in current bindings. Selenium setup
Connection refused or navigation times out on localhost	The local app is not running, is listening on a different port, or is not reachable from the test process.	Start the app separately, verify its exact URL in a browser, and use that URL in the test.
Locator finds nothing	The page has not reached the expected state, the locator does not match, or the element is inside a frame or another context.	Inspect the rendered page and accessible name, verify the locator, and wait on a meaningful visible condition. Check frame behavior in the framework documentation if relevant.
Test passes alone but fails in a suite	Tests share data or depend on order, or a prior test changes persistent state.	Make the test independent; arrange its own data and clean up or isolate state.
Intermittent timeout	The test races the application or waits for a slow external dependency.	Wait for the actual outcome rather than a fixed sleep, make test data predictable, and reduce unrelated network dependencies where suitable.
Assertion passes locally but fails in CI	The CI environment may differ in configuration, available browser dependencies, or application readiness.	Compare the URL, environment variables, browser setup, and startup logs; make the CI setup reproduce the documented local prerequisites.
One failure hides the actual defect	The test covers too many workflows in one sequence.	Split it into smaller tests, each with its own setup and one outcome to diagnose.

8. Performance, reliability, and cost

Browser tests cost more execution time and infrastructure than many lower-level checks because they launch and control a browser. Keep the browser suite focused on behaviors where browser-level coverage adds value, prepare data outside the browser when safe and supported, and avoid repeating lengthy setup in every scenario.

Reliability comes mainly from clear boundaries: deterministic starting state, short independent tests, stable locators, condition-based waits, and useful failure output. A retry can help identify intermittent failures, but it does not explain or repair the underlying race or shared state.

Tool pricing and infrastructure costs depend on your selected framework, CI provider, browser matrix, and whether you use hosted services. The cited documentation does not establish a universal cost or speed comparison, so estimate using your own workflow rather than assuming a specific framework is cheaper or faster.

Or skip the browser setup

If your immediate task is to capture a page image or PDF rather than verify an interactive behavior, ScreenshotNeo provides a website screenshot API and MCP server. One GET request can return a PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

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}`);

ScreenshotNeo accepts cookie and consent banners like a visitor and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, failed loads, timeouts, and cache hits cost nothing, and response headers report the page verdict and billing status. Its MCP server offers take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000 shots. Screenshot capture helps inspect or save rendered pages, but it does not replace an interactive browser test that asserts application behavior.

Create a free ScreenshotNeo account and get 1,000 screenshots a month with no card.

Frequently asked questions

How do I start automation testing if I’m a beginner?

Pick one user-visible behavior, follow one framework’s official first-test guide, and write a short test with known starting state, one interaction, and one observable assertion.

Should I automate every test case?

No. Automate repeatable checks where the value outweighs the setup and maintenance. Some checks are better handled manually or at a lighter testing layer.

Do I need a real browser for every test?

No. Use a browser when browser behavior or the end-to-end user experience is part of the question. Use lower-level tests for logic that can be checked without a browser.

Can a screenshot prove that a feature works?

A screenshot records appearance at a point in time. It does not by itself prove that an interaction, server-side change, or workflow produced the intended result.