# CI Test Atlas

The Test Atlas connects a curated test catalog to execution results and captured device screens. Use it to understand what a test is intended to prove, what ran on a particular candidate and what still needs review.

## Read the candidate first

The [2026-09-24 CI run](https://github.com/BitHighlander/keepkey-firmware/actions/runs/35982066194) includes a `test-report` artifact containing an 81-page PDF, manifest, PDF hash and merged JUnit results.

- Firmware: `efdeb678bc33c616cf8048fb5773548f0da96fa7`.
- Python test client: `b745562be6a13cc83b2a547d7ef86637f4556dbb`.
- PDF SHA-256: `d1b28f69cd541bba9190dcbfbb665bbd3b66f858d5dcefa6c635e96de54d5b4c`.
- Curated PDF catalog: **392 tests — 249 passed, 140 skipped, 3 pending**.
- Merged input census: **1,361 test cases — 1,183 passed, 178 skipped, no failures or errors** in that input set.

These populations differ. Do not add them together or use them as a permanent company-wide test count. This is a development candidate, not a signed-release acceptance receipt. GitHub artifact downloads may require authentication and may expire.

The [older 7.14.1 PDF](/img/vault/keepkey-firmware-test-report.pdf) is a historical report dated May 23, 2026; it is not the latest report.

## How to use it as a manual

1. Match the firmware, host and artifact identity to the build you are evaluating.
2. Find the relevant section and read the test's purpose and expected behavior.
3. Distinguish a passed test from skipped, pending or withheld coverage.
4. Inspect the captured screens. Sampled frames illustrate a test; only explicitly complete, ordered sequences can support a claim about the entire flow.
5. Follow the named test and JUnit result for exact inputs and assertions. A refusal can legitimately have no screen capture.
6. Record any remaining hardware, rendering or release-provenance checks separately.

## Limitations and known report corrections

Emulator evidence does not establish physical device resistance to fault injection, side channels or supply-chain attacks. Human review must judge whether the words on the captured screen are understandable and accurate.

This report also contains presentation and narrative issues: long OLED-needed annotations clip, some frames are samples, and historical explanatory text can disagree with current evidence. In particular, the appendix's immutable-bootloader claim conflicts with KeepKey's bootloader-update process. Read test statuses independently of historical prose.

The [Atlas authoring guide](https://github.com/keepkey/keepkey-firmware/blob/649e154005170eaf1138b4f669f731f415fce29b/docs/testing/ATLAS-GUIDE.md) describes catalog entries and full-sequence requirements. [python-keepkey](/docs/firmware/python-keepkey) is the test client.

## Try firmware without a device

KeepKey's [public emulator walkthrough](https://www.keepkey.com/zcash) demonstrates loading firmware into KeepKey Desktop with an Orchard test wallet. Use a compatible candidate and disposable test wallet. Never import a real recovery phrase into an emulator. The walkthrough does not establish coverage of every firmware feature.

Continue to [release status](/docs/firmware/release-status) or [device display examples](/docs/firmware/device-display).