GitHub review for QA teams: pricing, alternatives and setup

A pull request compares a head branch with a base branch and gathers everything needed to decide whether to merge: the diff, review comments and approvals, and status checks. Checks are reported against the head commit by GitHub Actions or by any external CI through the API, so every new push starts a fresh set of checks for the new commit. That is why a green pull request can turn yellow after a one-line fix, and why approvals can be dismissed automatically when new commits change the diff. Merging can create a merge commit, squash everything into one commit or rebase, as the repository allows.

Protection rules on a branch such as main can require a pull request, a number of approvals, review from code owners, and named status checks that must pass. Strict mode, the default, also requires the branch to be up to date with the base, so the checks have run against the code that will actually be merged. Required checks are matched by name, which is why GitHub advises unique job names across workflows. By default, rules do not bind repository administrators unless you choose to include them. Protected branches are available for public repositories on every plan, and for private repositories on Pro, Team and Enterprise.

Workflows are YAML files under .github/workflows, triggered by repository events such as pull_request, push, merge_group, a schedule or a manual dispatch. Each job runs on a fresh GitHub-hosted virtual machine, Linux, Windows or macOS, or on a self-hosted runner you operate. For private repositories, hosted minutes beyond the plan’s monthly allowance are billed per minute at a rate that depends on the runner, while public repositories on standard runners and all self-hosted runners incur no Actions charge. Artefacts such as reports and screenshots share a storage allowance with Packages.

Every plan includes unlimited public and private repositories. What changes between Free, Team and Enterprise is governance: protected branches, required reviewers and code owners in private repositories from Team, and SAML single sign-on, Enterprise Managed Users, audit log streaming and a larger Actions allowance on Enterprise Cloud. GitHub Enterprise Server is the self-hosted edition. Security scanning for private repositories is sold separately as Secret Protection and Code Security, which require Team or Enterprise, and Copilot has its own plans.

Set the rule on main to require a pull request, at least one approval, dismissal of stale approvals, review from code owners, and the tests check, with the branch up to date before merging. Then write a CODEOWNERS file that gives QA ownership of the test directories, the test configuration and the workflows that run them. Because the last matching pattern wins, put broad rules first and specific ones after. Decide deliberately whether administrators are bound by the rules; by default they are not, which is often how failing tests reach main. On Team and Enterprise, rulesets can apply the same rules across many repositories at once.

An issue form makes the fields a tester needs mandatory instead of hoped for. Ask for the build or version, the environment, the browser or device, numbered steps, expected and actual results, and logs, and let the form apply labels so triage queries work. Keep the form short enough that people use it: every required field is friction for someone reporting from outside the team. Issue forms are still in public preview, so check the syntax reference when a field type behaves unexpectedly, and keep a blank issue option for things that are not bugs.

A red cross on a check tells a reviewer that something failed, not what. Three mechanisms close the gap. A job summary written to GITHUB_STEP_SUMMARY puts counts, failing test names and links on the run page in Markdown. Workflow commands such as ::error with a file and line put an annotation on the changed line in the pull request diff, which is where a developer is already looking. And uploaded artefacts keep the HTML report, traces and screenshots for download. Most test runners can output JUnit XML, and community actions on the Marketplace turn it into check annotations, but review a third-party action’s code and pin it to a commit before granting it access to your repository.

The GitHub CLI shortens the loop between a failing check and a fix. gh pr checks with --watch follows the checks on the current branch’s pull request until they finish, and --required limits it to the checks that gate merging. gh run view with --log-failed prints only the logs of failed steps, which is usually all you need. gh run rerun with --failed reruns just the failed jobs and their dependencies, and gh run download fetches artefacts such as reports by name. Rerunning should be a diagnostic, not a habit: a test that passes on rerun is flaky, and it belongs in a tracked issue rather than in the team’s muscle memory.

A test framework, its browser binaries, the Docker images it runs in and the actions in its workflows all go stale. A dependabot.yml file schedules version update pull requests for each ecosystem, and groups combine related packages, such as everything named after Playwright, into one pull request, so an upgrade arrives as one change with one test run rather than five. Because those pull requests pass through the same branch protection and required checks, an upgrade that breaks the suite is caught before merge. Include the github-actions ecosystem: action versions drift as quickly as packages do.