10 Best Practices for Test Automation

After working with hundreds of teams, we've identified the practices that separate successful automation efforts from failed ones. Here are the 10 most important.

1. Start with a Clear Strategy

Don't automate blindly. Before writing a single test, answer these questions:

• What's the goal? (Faster releases? Better coverage? Cost reduction?)
• Which tests should be automated? (Not everything should be)
• What's the success criteria?
• What's the timeline and budget?

Pro tip: Use the test automation pyramid as a guide:

• 70% unit tests (fast, cheap, reliable)
• 20% integration tests (moderate speed/cost)
• 10% UI tests (slow, expensive, brittle)

2. Choose the Right Tool for Your Stack

One size doesn't fit all. Consider:

For Web Applications:

• Playwright - Modern, fast, excellent debugging, auto-waiting
• Selenium/WebDriver - Industry standard, wide language support
• Cypress - Developer-friendly, JavaScript-only

For Mobile:

• Appium - Cross-platform standard
• Detox - React Native specialist
• XCUITest/Espresso - Native options

For API Testing:

• Playwright - Built-in API testing capabilities
• REST Assured - Java developers
• Postman/Newman - Non-programmers

Don't choose based on hype—choose based on your team's skills and needs.

3. Implement Page Object Model (POM)

Bad:

// Brittle, hard to maintain
test('login', async ({ page }) => {
  await page.fill('#username', 'user');
  await page.fill('#password', 'pass');
  await page.click('button[type="submit"]');
});

Good:

// Maintainable, reusable
class LoginPage {
  constructor(page) {
    this.page = page;
    this.usernameInput = page.locator('#username');
    this.passwordInput = page.locator('#password');
    this.submitButton = page.locator('button[type="submit"]');
  }
  
  async fillUsername(username) {
    await this.usernameInput.fill(username);
  }
  
  async fillPassword(password) {
    await this.passwordInput.fill(password);
  }
  
  async submit() {
    await this.submitButton.click();
  }
  
  async login(username, password) {
    await this.fillUsername(username);
    await this.fillPassword(password);
    await this.submit();
  }
}

test('login', async ({ page }) => {
  const loginPage = new LoginPage(page);
  await loginPage.login('user', 'pass');
});

Benefits:

• Changes to UI require updates in one place
• Tests are more readable
• Easier to maintain as app grows
• Locators are defined once and reused

4. Make Tests Independent

Each test should:

• Set up its own data
• Clean up after itself
• Not depend on other tests
• Run in any order

Why?

• Parallel execution (faster CI/CD)
• Easier debugging (no cascading failures)
• More reliable results

Bad:

test('create user', async ({ page }) => { /* creates user */ });
test('edit user', async ({ page }) => { /* assumes user exists */ });
test('delete user', async ({ page }) => { /* assumes user still exists */ });

Good:

test('edit user', async ({ page, request }) => {
  // Setup - create test user via API
  const user = await request.post('/api/users', {
    data: { name: 'Test User', email: 'test@example.com' }
  });
  
  // Test the actual functionality
  await page.goto(`/users/${user.id}/edit`);
  await page.fill('#name', 'Updated Name');
  await page.click('button[type="submit"]');
  
  await expect(page.locator('.success-message')).toBeVisible();
  
  // Cleanup - delete test user
  await request.delete(`/api/users/${user.id}`);
});

5. Use Meaningful Test Data

Avoid magic numbers and strings:

Bad:

await expect(response.status()).toBe(200);
await expect(page.locator('.user-name')).toHaveText('Test User 123');

Good:

const HTTP_OK = 200;
const TEST_USER = {
  name: 'John Doe',
  email: 'john@example.com'
};

await expect(response.status()).toBe(HTTP_OK);
await expect(page.locator('.user-name')).toHaveText(TEST_USER.name);

Pro tip: Use test fixtures in Playwright:

// fixtures.js
import { test as base } from '@playwright/test';

export const test = base.extend({
  testUser: async ({}, use) => {
    const user = { name: 'John Doe', email: 'john@example.com' };
    await use(user);
  },
});

6. Leverage Auto-Waiting (Don't Use Hard Sleeps)

Playwright's killer feature: automatic waiting. Most actions auto-wait for elements to be ready.

Bad (old Selenium style):

await page.click('#submit-button');
await page.waitForTimeout(5000); // ❌ Fragile and slow

Good (Playwright auto-waits):

// Playwright waits automatically for element to be:
// - Attached to DOM
// - Visible
// - Stable (not animating)
// - Enabled
// - Not covered by other elements
await page.click('#submit-button');

// For specific conditions, use assertions
await expect(page.locator('.success-message')).toBeVisible();
await expect(page.locator('.loading-spinner')).toBeHidden();

Advanced waiting strategies:

// Wait for network to be idle
await page.waitForLoadState('networkidle');

// Wait for specific API response
await page.waitForResponse(response => 
  response.url().includes('/api/users') && response.status() === 200
);

// Wait for element state
await page.locator('#submit-button').waitFor({ state: 'visible' });

7. Make Tests Self-Documenting

Your tests are documentation. Write them clearly:

Bad:

test('test1', async ({ page }) => {
  // What does this test?
  await page.goto('/login');
  await page.fill('#email', 'invalid');
  await page.click('button');
  await expect(page.locator('.error')).toBeVisible();
});

Good:

test('should display error message when email format is invalid', async ({ page }) => {
  await page.goto('/login');
  await page.fill('#email', 'invalid-email');
  await page.click('button[type="submit"]');
  
  await expect(page.locator('.error-message')).toHaveText(
    'Please enter a valid email address'
  );
});

Use test.describe for organization:

test.describe('User Authentication', () => {
  test.describe('Login Flow', () => {
    test('should successfully login with valid credentials', async ({ page }) => {
      // test code
    });
    
    test('should show error with invalid credentials', async ({ page }) => {
      // test code
    });
  });
});

8. Monitor and Analyze Test Results

Track these metrics:

Reliability Metrics:

• Pass/fail rate over time
• Flaky test frequency
• False positive rate

Performance Metrics:

• Average execution time
• Tests per commit
• Parallel execution efficiency

Business Metrics:

• Bugs caught in testing vs production
• Time to detect issues
• Cost per test

Playwright provides built-in reporting:

// playwright.config.js
export default {
  reporter: [
    ['html'],
    ['json', { outputFile: 'test-results.json' }],
    ['junit', { outputFile: 'test-results.xml' }]
  ],
};

Use dashboards to visualize trends and identify problems early.

9. Handle Flaky Tests Aggressively

Flaky tests destroy trust. When a test fails randomly:

1. Investigate immediately - Don't ignore it
2. Fix or quarantine - Either fix it or disable it
3. Use retry strategically - Playwright allows targeted retries

Playwright's retry mechanism:

// playwright.config.js
export default {
  retries: process.env.CI ? 2 : 0, // Retry only in CI
  
  projects: [
    {
      name: 'chromium',
      use: { 
        ...devices['Desktop Chrome'],
        // Take screenshot on failure
        screenshot: 'only-on-failure',
        trace: 'retain-on-failure',
      },
    },
  ],
};

Common causes of flakiness:

• Race conditions (use Playwright's auto-waiting)
• External dependencies (use API mocking)
• Test data conflicts (use unique test data)
• Timing-sensitive assertions (use proper assertions)

Use Playwright's debugging tools:

# Run tests with UI mode for debugging
npx playwright test --ui

# Run tests in headed mode
npx playwright test --headed

# Debug specific test
npx playwright test --debug

10. Invest in CI/CD Integration

Automation is worthless if tests don't run automatically.

Essential CI/CD practices:

Run tests on every commit:

# GitHub Actions example
name: Playwright Tests
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
      
      - name: Install dependencies
        run: npm ci
      
      - name: Install Playwright Browsers
        run: npx playwright install --with-deps
      
      - name: Run Playwright tests
        run: npx playwright test
      
      - uses: actions/upload-artifact@v4
        if: always()
        with:
          name: playwright-report
          path: playwright-report/
          retention-days: 30

Parallel execution with sharding:

# Run tests across multiple machines
strategy:
  matrix:
    shardIndex: [1, 2, 3, 4]
    shardTotal: [4]
steps:
  - name: Run Playwright tests
    run: npx playwright test --shard=${{ matrix.shardIndex }}/${{ matrix.shardTotal }}

Cross-browser testing:

// playwright.config.js
export default {
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'Mobile Chrome', use: { ...devices['Pixel 5'] } },
    { name: 'Mobile Safari', use: { ...devices['iPhone 12'] } },
  ],
};

Bonus: Leverage Playwright's Advanced Features

Playwright offers powerful features that improve test quality:

1. Codegen - Generate tests automatically:

npx playwright codegen https://your-app.com

2. Trace Viewer - Debug failed tests:

// playwright.config.js
use: {
  trace: 'on-first-retry', // Capture trace on first retry
}

3. API Testing - Test backend directly:

test('should create user via API', async ({ request }) => {
  const response = await request.post('/api/users', {
    data: { name: 'John', email: 'john@example.com' }
  });
  
  expect(response.ok()).toBeTruthy();
  const user = await response.json();
  expect(user.name).toBe('John');
});

4. Visual Regression Testing:

test('homepage should look correct', async ({ page }) => {
  await page.goto('/');
  await expect(page).toHaveScreenshot();
});

Common Mistakes to Avoid

❌ Automating everything

Not all tests should be automated. Manual exploratory testing still has value.

❌ Ignoring maintenance

Tests need care just like production code. Budget for it.

❌ Poor test data management

Production data in tests = security risk + unreliable results.

❌ No code reviews for tests

Test code deserves the same quality standards as production code.

❌ Treating QA as second-class citizens

Invest in training and tools for your test engineers.

❌ Not using Playwright's built-in features

Hard-coding waits and complex selectors when Playwright handles this automatically.

Summary Checklist

Use this checklist to evaluate your test automation:

• Clear automation strategy documented
• Modern tools for your tech stack (consider Playwright)
• Page Object Model implemented
• Tests are independent and isolated
• Meaningful, maintainable test data
• Leveraging auto-waiting (no hard sleeps)
• Self-documenting test names
• Metrics tracked and visualized
• Flaky tests handled immediately
• Full CI/CD integration with parallel execution
• Cross-browser testing configured
• Regular maintenance scheduled
• Team trained on best practices

Conclusion

Great test automation doesn't happen by accident. It requires discipline, proper practices, and continuous improvement. Start with these 10 practices and iterate based on what works for your team.

Modern tools like Playwright make following these best practices easier with built-in auto-waiting, powerful debugging tools, and excellent CI/CD integration out of the box.

Remember: The goal isn't 100% automation—it's the right mix of automated and manual testing that maximizes quality while minimizing cost and time.

---

Need help implementing these practices? Check out our AI Automation Tools that make following these best practices automatic.