How to brief a tester: one brief per role

A playbook's section 9 holds the brief for one product type. Across the 46 published test plans, the 406 mandatory tests go to 6 different roles, so one brief sent to one person leaves part of the plan without an owner. This guide splits the brief by role.

Who runs the mandatory tests

Counted over all 406 mandatory items:

• QA engineer: 181 items. Release smoke tests on 44 of 46 plans, end-to-end functional tests on 43 of 43, payment and money-flow testing on 17 of 17.
• Developer: 78 items. Integration tests on 22 of 23, resilience and failure testing on 20 of 20, unit tests on 18 of 18.
• Security specialist: 74 items. Security scanning on 42 of 42, penetration testing on 30 of 39.
• Product manager: 47 items. Compliance checks on 45 of 46.
• Accessibility specialist: 17 items, all accessibility testing.
• External lab: 9 items, all penetration testing.

Procedure

1. Download the checklist for your type and sort it by the "who" column. Write one brief per role, and keep each item's order number so the briefs still add up to section 4.
2. For every item, paste the risk id with its link and the done condition word for word. The accounting and invoicing SaaS checklist shows the format: order, test type, risk ids, done condition, tool class, who.
3. Create the test data before you send the brief. 56 of the 406 mandatory done conditions name a test person, account or card, such as the "test customer" in the mobile banking app or the "test company" in the accounting and invoicing SaaS. Name each one in the brief with its login or sandbox details.
4. Brief the product manager on compliance as a sign-off, not a test run. 34 of the 46 compliance done conditions require a signature, a reviewer or an auditor, as on the pharmacy delivery app, where a pharmacist-in-charge signs. Name the signer in the brief.
5. Brief the security specialist with a finding threshold. 29 of the 42 security scanning done conditions require no open high or high-severity finding, which needs a severity scale agreed in advance.
6. Give the penetration tester a second test account. 30 of the 39 penetration testing done conditions test access across two accounts, such as one user reaching another user's or organisation's data, as on the online marketplace and ecommerce store, against the data breach risk.
7. State the start: release smoke tests are order 1 on all 46 plans, so the QA brief begins with them and every other brief waits for their pass.
8. Ask each role to report back pass or fail against each done condition as written, the build tested, and the proof. The founders page lists what to accept as proof.

Example briefs to compare

The identity and access management service splits its 10 mandatory tests across 5 roles, including an accessibility specialist. The kids app sends 6 of its 8 to a QA engineer, 1 compliance check to a product manager and 1 scan to a security specialist. The electronic health record system sends 3 of its 7 to developers. The number of briefs follows the roles in section 4, not a fixed template.