Purpose

Maintain the operating steps for risk-based software testing and release assurance. Testing must cover not only business functionality and security, but also the reliable operation of key compliance and control systems. Bitkaya targets TMMi (Test Maturity Model Integration) Level 2 compliance as indicated in CBCS “Provisions and Guidelines for Software Testing” (2024).

Scope

This procedure applies to test policy, test strategy, test design, dedicated test environment use, security testing and release approval evidence. Testing follows the CBCS Provisions for Software Testing (2024) and TMMi Level 2 maturity expectations, scaled to Bitkaya’s operational footprint. Automated testing tools and external QA reviews replace full-scale in-house testing departments. Focus is placed on high-risk crypto functions (wallet integrations, blockchain APIs, AML transaction filters) rather than exhaustive platform-wide testing.

Steps

#ActionDetailsEvidence
1Confirm testing owner, release scope and risk ratingVerify the testing approach is scaled to Bitkaya’s operational footprint with automated testing tools and external QA reviews replacing full-scale in-house testing departments.test plan and test case set
2Verify test cases, environment and tester capabilityWhere relevant, ensure testing verifies: correct onboarding workflow behaviour; integrity of identity verification integrations; accurate sanctions screening and list refresh behaviour; correct alert generation and routing; case-management traceability and workflow integrity; preservation of logs and audit trails; correct access restrictions and role permissions; and resilience of critical compliance-related interfaces and data flows.test plan and test case set
3Confirm focus on high-risk crypto functionsVerify focus is placed on high-risk crypto functions (wallet integrations, blockchain APIs, AML transaction filters) rather than exhaustive platform-wide testing.TMMi Level 2 compliance evidence
4Verify pre-release testing and approval of changesConfirm changes to compliance-related tools, rules, workflows, integrations, or critical system settings are tested before release, and approvals are documented.release approval or security test record
5Record test execution, defects and security checksRecord test execution, defects, security checks and release approval.execution record or defect log
6Retain evidence of assessment and defect closureRetain evidence of ongoing assessment and closure of defects.execution record or defect log
7Escalate failed tests or unapproved releasesEscalate any failed test or unapproved release.external QA review record

Evidence

  • test plan and test case set covering compliance and control system testing (onboarding workflows, identity verification integrations, sanctions screening, alert generation, case-management traceability, audit trails, access restrictions, data flow resilience)
  • execution record or defect log
  • release approval or security test record
  • TMMi Level 2 compliance evidence per CBCS Provisions for Software Testing (2024)
  • external QA review record where applicable

Relationships

Assurance

Runtime effectiveness results are maintained in Odoo and assessed through the Hermes workflow tracked in ISS-HERMES-001. This note defines design, ownership, evidence expectations and testing method; it does not contain a manually maintained operation, evidence or overall effectiveness rating.

  • Design status: implemented from approved IT and Cybersecurity Manual version 1.1

History

  • 2026-07-26: Created from REQ-IT-007.