# QA Manual Tester

> Use when creating test cases, executing manual tests, reporting bugs, or verifying software quality through hands-on testing. Trigger phrases: "manual testing", "test case", "test plan", "bug report", "test execution", "regression testing", "UAT", "user acceptance testing", "exploratory testing", "functional testing", "test scenario", "defect tracking", "test documentation", "cross-browser testing", "smoke test".

- Skill: `barastrong/qa-manual-tester` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add barastrong/qa-manual-tester`
- Raw SKILL.md: https://api.skillmd.com/api/skills/barastrong/qa-manual-tester/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: barastrong (https://skillmd.com/u/barastrong)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/barastrong/qa-manual-tester

---


# QA / Software Tester (Manual)

## Role Summary

A Manual QA Tester verifies software meets requirements and quality standards
through planned and exploratory testing. The role finds defects before users
do, communicates risk to stakeholders, and ensures the product behaves as
intended across scenarios.

## Core Responsibilities

- Write and maintain test plans, test cases, and test scenarios
- Execute manual test cases (functional, regression, exploratory)
- Report and track defects with clear reproducible steps
- Perform UAT coordination and sign-off support
- Cross-browser, cross-device, and cross-platform testing
- Risk-based testing: prioritize high-impact areas
- Review requirements and provide quality feedback early (shift left)
- Create and maintain test data
- Collaborate with developers on bug reproduction and fixes

## Standard Workflow

1. **Requirements Review** — analyze requirements, identify missing/ambiguous
   specs, raise questions.
2. **Test Planning** — scope, approach, resources, entry/exit criteria,
   risk areas.
3. **Test Design** — write test cases: positive, negative, boundary,
   edge cases.
4. **Test Environment** — set up test environment, verify test data.
5. **Execution** — execute test cases, log results (pass/fail), report bugs.
6. **Bug Tracking** — write detailed bug reports (steps to reproduce,
   expected, actual, environment, severity/priority).
7. **Regression** — retest fixed bugs, run regression suite on areas
   impacted by changes.
8. **Sign-off** — communicate quality status, remaining risks, go/no-go
   recommendation.

## Technology Stack

| Layer | Tools |
|-------|-------|
| Test Management | Jira, TestRail, Zephyr, Xray, qTest |
| Bug Tracking | Jira, Linear, Redmine, GitHub Issues |
| API Testing | Postman, Insomnia, REST Client |
| Cross-browser | BrowserStack, Sauce Labs, LambdaTest |
| Screen Recording | Loom, Snagit, ShareX |
| Test Data | Faker, Excel, DB data factories |

## Best Practices

- Test cases should be atomic, independent, and clearly written.
- Bug reports: minimum reproducible steps, clear expected vs. actual,
  environment details, severity/priority.
- Risk-based prioritization — test high-risk areas first.
- Exploratory testing for areas without clear requirements.
- Retest and regression after every fix.
- Shift left: review requirements before development starts.
- Track test coverage (what's tested, what's not).
- Boundary value analysis: test at limits (0, 1, max, max+1).

## Anti-Patterns to Avoid

- Vague bug reports ("it doesn't work") — include steps, screenshots.
- Testing only happy path — negative cases find the real bugs.
- Last-minute testing — quality is a process, not a phase.
- Copy-paste test cases without thinking — creates fake coverage.
- No communication of quality status — PMs need risk visibility.

## References

- `references/test-case-template.md` — test case writing standard
- `references/bug-report-template.md` — defect report template
- `references/testing-techniques.md` — equivalence partitioning, BVA, etc.

## Expected Output Format

1. Test plan (scope, approach, risk areas, timeline)
2. Test cases (steps, expected results, actual results, pass/fail)
3. Bug reports (steps, evidence, severity, priority)
4. Test summary report (coverage, pass/fail counts, open defects, quality recommendation)

