Lesson 1 of 86 min read
What GitHub Actions is and why QA owns it
GitHub Actions is the CI tool built into GitHub. A YAML file in your repository tells GitHub: 'when this happens, start a clean machine and run these commands'. For a tester, that means your automated tests run on every pull request without anyone remembering to run them — and a red cross on the PR stops a broken change from being merged. This lesson gives you the mental model and vocabulary before you write any YAML.
Key takeaways
- 1Workflow: one YAML file inside .github/workflows/ (for example tests.yml). A repository can have many workflows — PR checks, nightly regression, manual smoke run.
- 2Event (trigger): what starts the workflow — push, pull_request, schedule (cron), workflow_dispatch (manual 'Run workflow' button), release and more.
- 3Job: a group of steps that runs on one runner. Jobs run in parallel by default; needs: makes one wait for another.
- 4Step: one shell command (run:) or one reusable action (uses:), such as actions/checkout@v4 to download your code.
- 5Runner: the fresh virtual machine (ubuntu-latest, windows-latest, macos-latest) GitHub creates for each job and destroys after. Nothing from your laptop exists there.
- 6Public repositories get free standard runner minutes; private repositories get a monthly free quota, then minutes are billed — one more reason to keep test runs efficient.
Where things live in a test repository
my-test-project/ ├── .github/ │ └── workflows/ │ ├── pr-checks.yml <- runs on every pull request │ ├── nightly-regression.yml <- runs at 02:00 every night │ └── manual-smoke.yml <- 'Run workflow' button with env choice ├── tests/ │ ├── api/ │ └── ui/ ├── package.json └── playwright.config.ts What happens when a developer opens a PR: 1. GitHub sees event: pull_request 2. Finds every workflow listening for pull_request 3. Starts a clean ubuntu-latest runner per job 4. Steps: checkout -> install -> run tests -> upload report 5. PR shows ✔ tests passed or ✘ tests failed (Details) 6. Branch protection blocks 'Merge' while a required check is red
Go deeper
Expert notes beyond the basics
- 01
How a run actually executes
When an event fires, GitHub reads every workflow file on the relevant commit, keeps those whose on: section matches, and queues each job. Each job gets its own fresh runner, so two jobs never share files unless you pass them through artifacts or cache. Steps in one job run in order on the same machine and share the working directory. Understanding this explains most surprises: 'my second job can't find node_modules' (it's a different machine) or 'my env var disappeared' (it was set in a different job).
- 02
GitHub-hosted vs self-hosted runners
GitHub-hosted runners (ubuntu-latest, windows-latest, macos-latest) are managed, clean and preinstalled with common tools like Node, Java, Python and Chrome. Self-hosted runners are machines your company registers — used when tests must reach an internal network, need special hardware such as real mobile devices, or to control cost. Self-hosted runners are not automatically clean between runs, so test data and leftover processes can leak between jobs; mention this trade-off in interviews.
- 03
Actions marketplace — use with care
uses: actions/checkout@v4 runs code written by someone else with access to your repository. Prefer official actions (actions/*) and well-known vendors, pin versions (a major tag like @v4, or a full commit SHA in security-sensitive repos), and review what third-party actions do. Common QA actions: actions/checkout, actions/setup-node, setup-java, setup-python, actions/upload-artifact, actions/download-artifact, actions/cache.
- 04
GitHub Actions vs Jenkins in one paragraph
Jenkins is self-hosted, configured with a Groovy Jenkinsfile and plugins, and very common in large enterprises and service companies. GitHub Actions is hosted, YAML-based and integrated into pull requests with no server to maintain. Concepts map directly: Jenkins stage/step ≈ Actions job/step, agent ≈ runner, credentials ≈ secrets, archiveArtifacts ≈ upload-artifact. If you know one, say you can read the other within a day — and show it.
Common mistakes to avoid
- - Saving the workflow outside .github/workflows/ or with a .txt extension.
- - Expecting files created in one job to exist in another job.
- - Running the whole regression suite on every push and burning paid minutes.
- - Using random marketplace actions without pinning a version.
- - Treating CI as a DevOps-only topic instead of owning the test jobs.
Try it yourself
Your team runs automated tests manually from a laptop before each release. Write a short proposal (5 bullet points) for moving them into GitHub Actions: which workflows you'd create, what triggers each uses, and what changes for developers.
Write your answer on paper or in a sheet first, then compare.
Interview questions
How to answer like a confident QA engineer
- Q1
What is GitHub Actions and how have you used it in testing?
Model answer
GitHub Actions is GitHub's built-in CI/CD service. Workflows are YAML files in .github/workflows that run jobs on GitHub-hosted runners when events happen, such as a push, a pull request, a schedule or a manual trigger. In my project, a PR workflow installs dependencies and runs our smoke tests — API checks plus critical Playwright UI flows — in about ten minutes, uploads the HTML report as an artifact, and is a required status check, so a failing test blocks the merge. A separate scheduled workflow runs the full regression nightly and a manual workflow lets us run smoke tests against staging or production on demand.
- Q2
What is the difference between a workflow, a job and a step?
Model answer
A workflow is the whole YAML file triggered by events. It contains one or more jobs; each job runs on its own runner and jobs run in parallel unless linked with needs. A job contains ordered steps; each step is either a shell command with run or a reusable action with uses, and steps in the same job share the machine and files.
- Q3
What is a runner?
Model answer
The machine that executes a job. GitHub-hosted runners are fresh virtual machines created per job and destroyed afterwards, with common tools preinstalled. Self-hosted runners are machines your organisation manages, used for private network access, special hardware or cost control, but they need cleaning between runs.
- Q4
Why should automated tests run on pull requests rather than only after merge?
Model answer
Testing the PR catches problems before they reach main, while the change is small and the author still has context. It keeps main always releasable, and with required status checks a failing test blocks the merge instead of everyone discovering the break later.
Knowledge check
+5 points
Where must a GitHub Actions workflow file be placed for GitHub to find it?