Skip to content
hindbrain
Start a project
PL
hindbrain

EXPLORE HINDBRAIN

Start a project
PL

Playbook

Testing playbook for systems and applications

The procedure Hindbrain uses to test backend, web, desktop and mobile apps, and security. Tick off items, print the documents and see what your project is missing.

Book a free call about testing

When to use this playbook

Before launch

A new product or a large feature goes to production. We fix critical and high findings before the start.

After taking over an app

You receive a system from another vendor. We check what really works before you build on it.

Once a year

The app is live. We repeat the full review because dependencies, permissions and configuration age.

How long it takes

A security audit of a typical B2B app takes 4 to 5 working days. The whole path depends on the number of branches: [NEED: time range of the full test path for web, desktop and mobile apps].

What you get

  • A findings report: description, evidence, business impact, CVSS 3.1 rating and step-by-step fix
  • An acceptance test protocol signed by both sides
  • A retest after fixes, in the same report
  • A list of what was checked with no reservations
  • A recommendation: ship or not

Test path map

Seven stages in order. Frontend testing branches into web, desktop and mobile, then joins again in integration and security testing.

Flow graph: Preparation, Backend tests, Frontend tests with Web, Desktop app and Mobile app branches, Integration and security, Acceptance with client, Report and retest, Go-live decision.
The test path from preparation to the go-live decision.

  1. Preparation

    Scope, consent to test, access, test accounts and staging. We do not start without them.

  2. Backend tests

    API, data, permissions, performance and backups.

  3. Frontend tests

    Web, desktop and mobile separately, depending on what you build.

  4. Integration and security

    Tests against OWASP ASVS level 2: automated scans, then manual verification of every result.

  5. Acceptance tests

    You walk through the scenarios on staging. The result goes into the protocol.

  6. Report and retest

    Findings report, fixes, a second test.

  7. Go-live decision

    Rule: a product does not ship with an open critical finding. You make the decision.

Dependency graph: what must exist to start

Every stage has an input. If one is missing, the stage waits. Check the Owner column: that is how much sits on your side.

Dependency graph: access, test accounts, staging, consent to test, API documentation, mobile builds and certificates linked to the stages they block.
Which input unlocks which stage.
RequirementBlocks stagesOwner
AccessRepository, hosting panel, admin panels, app store accounts.All stagesClient
Test accountsOne account per user role, with data they are allowed to see.Backend tests, Frontend tests, Acceptance testsClient
Staging with test dataAn environment separate from production. Never production with customer data.All stagesClient
Consent to testWritten consent with a time window, scope and an emergency contact.Integration and securityTogether
API documentationAn OpenAPI spec or an endpoint description with sample requests.Backend testsClient
Mobile buildsInstallable files for iOS and Android, ideally through TestFlight and a test channel.Frontend testsClient
Certificates and signingApp signing certificates, provisioning profiles, signing keys.Frontend testsClient

Detailed branches

For each branch we define scope, tools, and entry and exit criteria. We enter a branch only when its entry criteria are met.

Branch diagram: Backend, Web, Desktop and Mobile, each with a scope list and entry and exit criteria.
Four test branches and their scope.

Backend

Scope

  • API: contract, error codes, limits
  • Data: consistency, migrations, validation
  • Permissions: roles, data isolation between companies
  • Performance: load at typical traffic
  • Backups: they exist and can be restored

Tools

  • Bruno or Postman
  • k6
  • OWASP ZAP or Burp
  • Backup restore test on staging

Entry criteria

  • Staging runs with test data
  • API documentation or an endpoint list
  • Test accounts for every role

Exit criteria

  • All endpoints checked
  • No open critical findings
  • Backup restore tested and timed

Web

Scope

  • Browsers: current Chrome, Firefox, Safari, Edge
  • Accessibility to WCAG 2.2 AA
  • Responsiveness from phone to large screen
  • Error states: offline, empty list, expired session

Tools

  • Playwright
  • axe
  • Lighthouse
  • Screen reader and keyboard navigation

Entry criteria

  • Backend tested
  • Staging with the current build
  • List of key user paths

Exit criteria

  • Key paths pass in every browser in scope
  • No critical accessibility errors
  • Error states show a clear message

Desktop app

Scope

  • Install and uninstall
  • Updates: automatic and manual
  • System permissions: files, network, notifications
  • Offline work and return to online

Tools

  • Virtual machines with Windows and macOS
  • System tools to inspect files and network traffic
  • [NEED: desktop app stack, e.g. Electron, Tauri or native]

Entry criteria

  • Installer signed with a certificate
  • Access to the update channel
  • List of supported OS versions

Exit criteria

  • Install and update work on every supported version
  • The app asks only for needed permissions
  • Offline work does not lose data

Mobile app

Scope

  • iOS and Android on real devices
  • Permissions: camera, location, notifications
  • Memory, battery and weak network
  • App Store and Google Play requirements
  • Security to OWASP MASVS

Tools

  • TestFlight and the Google Play internal test channel
  • Xcode and Android Studio
  • OWASP MASTG
  • MobSF

Entry criteria

  • Test build on both platforms
  • Store accounts and certificates
  • Backend tested

Exit criteria

  • Key paths work on the devices in scope
  • Sensitive data sits in keychain or keystore
  • Store requirements checked before submission

Roles: who is responsible for what

A RACI matrix for every stage. Deliver means preparing the input. Decide means owning the outcome. Test means running the tests. Sign means confirming the stage is done.

Role split across the seven stages.
StageDeliversDecidesTestsSigns
PreparationClientTogetherHindbrainClient
Backend testsClientHindbrainHindbrainHindbrain
Frontend testsClientHindbrainHindbrainHindbrain
Integration and securityClientHindbrainHindbrainHindbrain
Acceptance testsTogetherClientClientClient
Report and retestHindbrainClientHindbrainTogether
Go-live decisionHindbrainClientTogetherClient

Interactive checklist

Tick items off during the project. State is saved only in this browser. Each item has an owner: Client, Hindbrain or Together. You can print the full list as a separate document.

Progress0 / 42

0
Open the checklist as a document

Documents to download

Five templates. Print the page or choose "Save as PDF". Fill in the underlined fields by hand or in an editor.

Consent to test (rules of engagement)

Written client consent for security testing. We do not start without it.

Parties

  • Client: ____
  • Contractor: Hindbrain
  • Decision maker on the client side: ____

Scope

  • Domains and addresses: ____
  • APIs and mobile apps: ____
  • Test environment (never production with customer data): ____
  • Out of scope: ____

Rules

  • Testing window: from ____ to ____
  • Allowed: scanning, manual tests on a test account
  • Not allowed: DoS attacks, social engineering without separate consent
  • Emergency contact (name, phone): ____

Signatures

  • Client, date: ____
  • Hindbrain, date: ____

Test plan

What is tested, when and by whom, and when a stage counts as done.

Goal and scope

  • Application and version: ____
  • Branches: backend, web, desktop, mobile (mark the chosen ones)
  • Security standard: OWASP ASVS level 2

Schedule

  • Start: ____
  • Backend tests: ____
  • Frontend tests: ____
  • Security tests: ____
  • Acceptance tests: ____
  • Retest: ____

Entry and exit criteria

  • Entry: access, test accounts, staging, consent to test
  • Exit: no open critical or high findings

Risks and assumptions

  • Risks: ____
  • Assumptions: ____

Acceptance test protocol

Confirmation that the client checked the agreed scenarios and accepted the result.

Details

  • Application and version: ____
  • Environment: ____
  • Test date: ____
  • Testers: ____

Scenarios

  • Scenario, expected result, outcome (passed / failed), notes
  • Scenario 1: ____
  • Scenario 2: ____
  • Scenario 3: ____

Decision

  • Accepted without remarks
  • Accepted with remarks to fix by: ____
  • Rejected, reason: ____

Signatures

  • Client, date: ____
  • Hindbrain, date: ____

Findings report template

Audit report structure: an executive summary and a description of each finding.

Executive summary

  • Three sentences: what was checked, overall rating, the main risk
  • Number of findings per level: ____

CVSS 3.1 levels

  • Critical: 9.0 to 10.0
  • High: 7.0 to 8.9
  • Medium: 4.0 to 6.9
  • Low: 0.1 to 3.9
  • Informational: 0.0

Finding description

  • ID and title: ____
  • Level and CVSS score: ____
  • Description and evidence: ____
  • Business impact: ____
  • Step-by-step fix: ____
  • Owner and deadline: ____
  • Status after retest: fixed / open

Checked with no reservations

  • List of areas where no problems were found: ____

Access list to hand over

What the client provides before testing starts. Share passwords through a password manager, not by e-mail.

Code and infrastructure

  • Repository (read): ____
  • Hosting or cloud panel (read-only role): ____
  • DNS: ____

Test environment

  • Staging address: ____
  • Test accounts for every role: ____
  • API documentation: ____

Mobile and desktop apps

  • Access to TestFlight and the Google Play test channel: ____
  • Signing certificates and profiles: ____
  • Installers and update channel: ____

Contact

  • Technical contact on the client side: ____
  • Emergency contact: ____