# Test brief: SDK or client library

Product type: SDK or client library. A library shipped to other developers' codebases.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/sdk/
Printable checklist: https://howtotestaproduct.com/checklists/sdk/

Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: dependency-failure, store-rejection). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: Each release candidate carries its privacy manifest and a signature that Xcode validates, installs into sample host apps for every supported platform, builds from a clean cache, launches and completes the quick-start call.
2. integration tests (risks: regulatory-penalty, data-breach). Tool class: proxy. Usually run by: developer.
   Done when: A proxy capture of a sample host app shows the SDK sends only the data types in its privacy manifest, and nothing before the host app's consent call.
3. compliance checks (risks: regulatory-penalty, store-rejection). Tool class: test management. Usually run by: product manager.
   Done when: The privacy manifest and the sample disclosure text list every data type the SDK collects and every recipient, signed off by legal, and the binary is signed.
4. security scanning (risks: data-breach). Tool class: dependency scanner. Usually run by: security specialist.
   Done when: The dependency report for the release lists no known-malicious or high-severity package, every transitive dependency is pinned in the lockfile, and maintainer changes are reviewed.
5. device and browser compatibility (risks: store-rejection, dependency-failure). Tool class: device cloud. Usually run by: QA engineer.
   Done when: The SDK builds and runs in sample host apps on the oldest and newest supported OS, language and package manager versions, and each iOS sample host app build passes App Store Connect validation with the SDK's privacy manifest.
6. unit tests (risks: dependency-failure). Tool class: unit framework. Usually run by: developer.
   Done when: In the test report, every server-sent config and response field in the fixed sample set passes with a null, wrong-type and missing value and no crash.
7. contract tests (risks: dependency-failure). Tool class: contract tool. Usually run by: developer.
   Done when: Before any server config change goes live, staging responses match the schema that every supported SDK version expects.
8. regression suite (risks: dependency-failure). Tool class: test management. Usually run by: QA engineer.
   Done when: The public API surface diff and the crash cases rerun on every release, and a removed or changed public method without a major version bump blocks the release.
9. resilience and failure testing (risks: dependency-failure). Tool class: chaos tool. Usually run by: developer.
   Done when: With the SDK backend returning errors, timeouts or malformed config, the sample host app keeps running and its own features work.

Acceptance criteria wording:
A release of the SDK is accepted when it installs into sample host apps for every supported platform, builds from a clean cache and completes the quick-start call, and a network capture shows only the data types in its privacy manifest, with nothing sent before the consent call. The dependency report lists no known-malicious or high-severity package, and the sample host app keeps running when the SDK backend returns errors or malformed config.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.