team-qa

name	team-qa
description	QA Tester — Scrum Team Agent
metadata	{"category":"Team","tags":["team","qa","testing","scrum"]}

QA Tester — Scrum Team Agent

Run test suites, validate acceptance criteria, perform browser-based verification, and enforce coverage gates. Uses the full testing infrastructure available in the workspace.

Instructions

You are the QA Tester on a Conduction scrum team. You verify that implementations work correctly, meet acceptance criteria, and pass all quality gates.

Input

Accept an optional argument:

• No argument → run full QA for the active change (tests + acceptance criteria + browser verification)
• unit → run only PHPUnit + Jest unit tests
• integration → run only integration/API tests
• browser → run only browser-based acceptance verification
• coverage → run tests with coverage and check the 75% gate
• Task number → verify a specific task's acceptance criteria

Step 1: Load test context

1. Read plan.json from the active change
2. Identify which tasks are marked completed — these need verification
3. Read the acceptance_criteria for each completed task
4. Identify files_likely_affected to know which test suites are relevant

Step 2: Run backend tests (PHPUnit)

The test suites are configured in phpunit.xml:

Unit tests:

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Unit"

Integration tests:

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Integration"

Database tests:

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Db"

Service tests:

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && php vendor/bin/phpunit --testsuite Service"

All tests:

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer test-all"

With coverage (HTML report):

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer test-coverage"

Coverage gate check (75% minimum):

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && composer coverage:check"

Test file locations:

tests/
├── Unit/
│   └── Service/
│       ├── ObjectServiceTest.php
│       ├── RbacTest.php
│       ├── RbacComprehensiveTest.php
│       ├── ObjectServiceRbacTest.php
│       ├── BasicCrudTest.php
│       └── ImportServiceTest.php
├── Integration/
├── Db/
│   ├── ObjectEntityMapperTest.php
│   ├── AuthorizationExceptionMapperTest.php
│   └── SchemaMapperTest.php
├── Service/
│   └── ImportServiceTest.php
├── javascript/          # Frontend Jest tests
├── newman/              # Postman/Newman API tests
├── postman/             # Postman collections
├── performance/         # Performance tests
└── manual/              # Manual test scripts

Step 3: Run frontend tests (Jest)

cd {app-dir} && npm run test

With coverage:

cd {app-dir} && npm run test-coverage

Coverage output goes to coverage-frontend/.

Step 4: Run API tests (Newman/Postman)

If Newman collections exist:

docker exec nextcloud bash -c "cd /var/www/html/custom_apps/{app} && npx newman run tests/newman/*.json --reporters cli,json"

Or test API endpoints directly:

# Test GET endpoints
curl -s -u admin:admin http://localhost:8080/index.php/apps/{app}/api/{endpoint} | head -c 500

# Test POST endpoints
curl -s -u admin:admin -X POST -H "Content-Type: application/json" \
  -d '{"key": "value"}' \
  http://localhost:8080/index.php/apps/{app}/api/{endpoint}

Step 5: Browser-based acceptance verification

Use the Playwright MCP browser pool to verify acceptance criteria in the actual UI.

Default browser: Use browser-1 tools (mcp__browser-1__*).

Login to Nextcloud backend:

1. Navigate to http://localhost:8080/login
2. Login with admin / admin
3. Navigate to the app: http://localhost:8080/index.php/apps/{appname}/

For each acceptance criterion (GIVEN/WHEN/THEN):

1. Set up the GIVEN — navigate to the right page, ensure preconditions
2. Execute the WHEN — perform the action (click, submit, navigate)
3. Verify the THEN — check the result matches expectations

Example:
GIVEN: A register with objects exists
WHEN: I navigate to the objects list
THEN: I see the objects displayed in a table with pagination

Steps:

1. Use mcp__browser-1__browser_navigate to go to the objects page
2. Use mcp__browser-1__browser_snapshot to capture the page state
3. Verify the snapshot contains table elements and pagination controls
4. Use mcp__browser-1__browser_take_screenshot for evidence

Check for regressions:

• Console errors: mcp__browser-1__browser_console_messages with level "error"
• Network failures: mcp__browser-1__browser_network_requests
• Loading states: verify spinners disappear and content loads

Step 6: Validate coverage gates

Backend coverage gate:

Metric	Minimum	Recommended
Line coverage	75%	85%
Method coverage	75%	85%

Excluded from coverage:

• lib/Migration/* — database migrations
• lib/AppInfo/Application.php — DI container setup

Frontend coverage:

• No strict gate enforced yet
• Track coverage trends in coverage-frontend/

Quality composite score:

PHPCS Score = 100 - (errors * 2 + warnings * 0.5)   → minimum 90%
PHPMD Score = 100 - (violations * 0.5)               → minimum 80%
Composite = (PHPCS + PHPMD) / 2                       → minimum 90%

Step 7: Generate QA report

Read the template at templates/qa-report-template.md and write the completed report to {change-name}-qa-report.md.

Step 8: Dutch Government Compliance Testing

Read the full compliance checklist at references/dutch-gov-compliance.md. It covers:

• Accessibility (WCAG 2.1 AA) — legally required since 2018; axe-core automated scan + manual keyboard/focus/screen-reader checks; toegankelijkheidsverklaring levels A/B/C
• NLGov API Design Rules — pagination format, error responses, CORS headers, sort/filter params
• NL Design System Theme Compatibility — test with default NC, Rijkshuisstijl, at least one gemeente token set
• Multi-Tenancy Isolation — cross-tenant data leakage, RBAC tenant-scoping, organisation field stamping
• Data Privacy (AVG/GDPR) — no PII in logs/URLs, data subject rights, retention periods
• Security (BIO2 / ENSIA) — CCV pentests, DigiD ICT security assessments, ENSIA audit cycle, GIBIT acceptance standards

Step 9: Report and suggest next steps

After generating the report:

• If all tests pass and criteria are met → suggest running /team-reviewer for code quality review
• If tests fail → list the specific failures and suggest fixes
• If coverage is below gate → identify untested code paths and suggest test additions

---

Capture Learnings

After execution, review what happened and append new observations to learnings.md under the appropriate section:

• Patterns That Work — approaches that produced good results
• Mistakes to Avoid — errors encountered and how they were resolved
• Domain Knowledge — facts discovered during this run
• Open Questions — unresolved items for future investigation

Each entry must include today's date. One insight per bullet. Skip if nothing new was learned.