Where to Practice QA Automation: Using the BecomeQA Lab

Writing tests against a real production site is the obvious practice approach until a CAPTCHA appears, a CSS class gets renamed in a deploy you didn't know about, and you spend two hours debugging a broken selector instead of learning the technique. Practice sites built for automation have stable data-testid attributes, predictable state, and scenarios designed to cover what interviewers actually ask about. This article describes what's in lab.becomeqa.com, how the scenarios map to specific automation techniques, and which other practice sites cover what the lab doesn't.

Why you can't just practice on random websites

The obvious approach is to open some website and write tests against it. It works until it doesn't.

Real sites change without warning. The login form gets a new CAPTCHA. The element IDs change. A CSS class you relied on gets renamed in a deployment you never knew happened. Your test suite breaks at random, and debugging takes longer than writing the tests did.

Practice sites built for testing are different. They have stable selectors, predictable state, and features specifically designed to cover automation scenarios. You can reset data, create users, break things, and experiment without consequences.

What makes a good practice site

A useful practice environment has:

• Authentication: login/logout flows, protected routes, invalid credential handling
• Data tables: sorting, filtering, pagination, row selection
• Forms: validation errors, required fields, dropdowns, date pickers
• Modals: open/close behavior, confirmation dialogs, form submission inside a modal
• File upload: drag and drop, file type validation, upload progress
• API: same backend accessible directly for API testing in parallel with UI tests
• Stable selectors: data-testid attributes or reliable IDs that won't change

The scenario coverage matters more than visual polish. A site built for practice will have all of these; a random production site will have maybe two.

The lab.becomeqa.com practice environment

We built a dedicated practice lab for the exercises in this course. It lives at lab.becomeqa.com and it's free.

What's on it:

• Valid login flow (email + password)
• Invalid credentials → error message
• Protected routes that redirect to login if you're not authenticated
• Logout

• Add, edit, delete items
• Status column: Planned, In Progress, Completed
• Filter by status
• Sort by columns
• Pagination

• Add item opens a modal with a form
• Edit item: same modal, pre-filled
• Delete confirmation modal
• Close by clicking X, close by clicking outside, close by pressing Escape

• Upload files by click or drag-and-drop
• File type and size validation
• Upload progress indicator

• Card number, expiry, CVV
• Validation errors on invalid input
• Simulated payment flow

• REST endpoints for all data operations
• Authentication via Bearer token (same credentials as UI login)
• OpenAPI documentation available at /api-docs

Default test credentials

URL:      https://lab.becomeqa.com
Email:    admin@becomeqa.com
Password: admin123

These are shared credentials for practice. Don't store real data. The lab resets periodically.

A simple test to confirm the setup

Before going further, verify that your environment connects to the lab correctly:

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

test('lab is reachable and login works', async ({ page }) => {
    await page.goto('https://lab.becomeqa.com');
    await page.getByLabel('Email').fill('admin@becomeqa.com');
    await page.getByLabel('Password').fill('admin123');
    await page.getByRole('button', { name: 'Sign in' }).click();
    
    await expect(page.getByText('Travel Items')).toBeVisible();
});

If this passes, you're ready.

Other practice sites worth knowing

The lab covers the main scenarios for this course. For variety, these are also worth knowing:

A classic. Covers: dropdowns, checkboxes, JavaScript alerts, iframes, drag and drop, file upload, infinite scroll. Good for specific technique practice but doesn't have a realistic app structure.

A fake e-commerce site from Sauce Labs. Login, product listing, shopping cart, checkout. Useful for practicing a complete purchase flow. Has broken versions of the app to practice debugging (locked_out_user, error_user).

A public REST API that returns fake user data. No UI, API only. Useful for practicing API testing without setting up your own backend.

Covers forms, widgets, interactions, alerts. More UI component-focused than workflow-focused. Good for practicing specific element types.

What to practice and in what order

Follow the order of this course. Each module introduces a new technique; the lab exercises apply it against a real feature.

The progression:

1. Write a login test (basic navigation, form fill, assertion)

2. Add table row assertions (finding elements in a list)

3. Open and fill a modal form

4. Test form validation (error messages on invalid input)

5. File upload

6. API request interception (checking network calls from UI actions)

7. Full workflow (login → add item → verify in table)

By the end of module 5 (enterprise POM), you'll have a full test suite covering the entire lab. That suite is portfolio-ready. It demonstrates the same structure used in production automation projects.