Stop 11 · CI/CD & DevOps for QATopics · 2/8

Integrating Tests Into Jenkins / GitHub Actions

Part of the QA Testing Roadmap

In short

A test suite that only runs when you remember to run it is a hobby. Hook it into Jenkins or GitHub Actions and it guards every pull request, even while you sleep.

Configuring your automated test suite to run automatically as part of a CI/CD pipeline — triggering on every commit or pull request, providing fast feedback before code merges.

The purple blob watches bags roll through a baggage scanner on a moving belt.

Think of it like this

The metro baggage scanner

At a metro station, nobody decides which bags to check. Every bag goes through the scanner on the belt, automatically. A CI workflow does the same: every pull request rides through your tests before it's allowed in.

Watch it happen

A pull request meets your tests

Developer
GitHub
Runner

open PR #128

1/6A developer opens a pull request with a new checkout feature.

The big ideas

What you need to know

Workflow file

GitHub Actions reads YAML files in .github/workflows. Jenkins reads a Jenkinsfile. Both live in the repo next to the code.

Triggers

Decide when tests run: on every pull request, on push to main, on a schedule, or by hand.

Runners and agents

Tests run on a fresh machine each time, so nothing from yesterday's run can hide a problem.

Secrets stay secret

Store test passwords and tokens in the CI's secrets settings, never inside the YAML or test code.

See it in code

Walk through the code

yaml
1name: e2e2on:3  pull_request:4  push:5    branches: [main]6jobs:7  test:8    runs-on: ubuntu-latest9    steps:10      - uses: actions/checkout@v411      - uses: actions/setup-node@v412        with:13          node-version: 2214      - run: npm ci15      - run: npx playwright install --with-deps16      - run: npx playwright test

1/4Triggers: run on every pull request and on pushes to the main branch.

Save this as .github/workflows/e2e.yml. Every pull request and every push to main now runs your Playwright suite.

Save yourself the pain

Common mistakes

Oops

Tests pass locally but fail in CI, so you assume CI is broken.

Do this instead

CI is a clean machine. Look for missing env variables, hardcoded localhost URLs or data that only exists on your laptop.

Oops

Committing a test account password inside the workflow file.

Do this instead

Add it under repository secrets and read it as an environment variable in the job.

Your mission

Your first green tick

~40 min

Quick check

Your tests pass on your laptop but fail on the CI runner with 'connection refused'. What's the most likely cause?

Go deeper

  1. 1Set up a basic Jenkins job or GitHub Actions workflow that runs your Phase 7 automation suite.
  2. 2Learn to configure the pipeline to fail the build when tests fail.
  3. 3Practice viewing test results directly within the CI/CD tool's interface.

More topics at this stop

Stuck on this topic? Ask an Insider

Get 1:1 guidance from people who've walked this exact path — on the InsideEdge app.

Download
InsideEdge