トピック3.7 — テストと品質保証

一文で言うと： 医療・ケアでは、テストと品質保証は、リリース前に行うフェーズではなく、サービスが臨床的に安全で、アクセスしやすく、セキュアで、患者のケアに触れるのにふさわしいことを示すエビデンスの多くを提供する、継続的な規律です。

医療・ケアにおいてなぜ重要か#

あらゆるデジタルサービスには欠陥があります。問題は、いくつあるか、どれほど深刻か、そして患者が影響を受ける前に見つけるか、後に見つけるか、だけです。消費者向けアプリでは、見つからなかったバグはユーザーの午後を無駄にします。臨床システムでは、誤った患者のアレルギーを表示し、小児の薬の用量を誤って丸め、誰も監視していないキューに紹介を静かに落とすことがあります。テストは、そうした欠陥を早期に見つけるための組織的な取り組みであり、品質保証は、品質を運や英雄的な奮闘に依存させないための、より広い統制のシステムです。

医療ITにおけるテストが、臨床安全と切り離せないのは、このためです。DCB0129/0160のハザードログ（トピック1.6 — 臨床安全とリスクマネジメント参照）に記録されたハザードは、軽減策が機能し、その後のあらゆる変更の後も機能し続けることをテストが証明したときにのみ、本当に軽減されます。再現可能なテストの裏づけなしに、「システムは重複した処方を防ぐ」と主張する安全性ケースは、アシュアランスではなく主張です。テストは、臨床安全の論証の下にあるエビデンスの基盤です。

利害は、公平性と公的信頼にも及びます。アクセシビリティの標準に照らしてテストされたことのないサービスは、既定で障害のあるユーザーを排除します（トピック1.9 — デジタルインクルージョンとアクセシビリティ参照）。実際の患者記録のコピーだけでテストされたサービスは、NHSが依存する信頼を損なう、データ侵害のリスクを負います。そしてお金も些細ではありません。稼働中の運用で見つかった欠陥の手直しは、設計で捕捉するよりも何倍も高くつき、重大な臨床インシデントは、そのどちらよりはるかに高くつきます。不十分なテストは節約ではなく、先送りされ膨らんだ請求書であり、時には害によって支払われます。

中核概念#

テスト対品質保証。 テストは、欠陥を見つけ、振る舞いを確認するためにシステムを動かす行為です。品質保証は、品質を最後に検査して取り込むのではなく、組み込む、より広いプロセス、つまり標準、レビュー、完了の定義、関門の集合です。テストは、このビルドが機能するかを教え、QAは、ビルドがそもそも機能する傾向にある理由です。どちらも重要ですが、リーダーは前者に資金を出し、後者を怠りがちです。

テストピラミッドとシフトレフト。 健全なテスト戦略は、速く安価な多数のユニットテスト（個々の関数の確認）、より少ない統合テスト（部品が一緒に機能することの確認）、そして遅く高価な少数のエンドツーエンドのテスト（ユーザーの旅路全体の確認）を備えています。この「テストピラミッド」は、フィードバックを速く、保守を手頃に保ちます。それはシフトレフト・テスト、つまりテストをライフサイクルの早い段階に移し、リリース前の慌ただしい駆け込みで欠陥を見つけるのではなく、欠陥を安く設計で取り除くことと対になります。逆さまのピラミッド（主に手動のエンドツーエンドのテスト）は、遅く、脆く、警告サインです。

機能テストと非機能テスト。 機能テストは「システムは、するべきことをしているか」を問います。正しい計算、正しいワークフロー、正しいデータ。非機能テストは「どれだけうまく振る舞うか」を問います。性能と負荷（午前8時にトラスト全体がログインしたときも応答性を保つか）、セキュリティ（侵害されうるか）、信頼性、アクセシビリティ。医療・ケアでは、非機能の失敗がしばしば最も危険です。機能的には完璧でも、蘇生の呼び出しの間にタイムアウトするシステムは、臨床的に失敗しています。

回帰テスト。 回帰テストは、変更の後に既存のテストを再実行し、一つを修正または追加したことが、別のものを壊していないことを確認します。稼働中の臨床システムでは、これが最も重要な安全の習慣です。臨床ソフトウェアのインシデントの大半は、新機能からではなく、機能していた振る舞いを静かに壊した変更から生じます。信頼できる回帰テストのスイートは、息を止めることなく、稼働中のシステムを変更できるようにするものです。

テストの自動化と継続的インテグレーション。 テストの自動化は、ソフトウェアを使ってテストを再現可能に実行し、大きなスイートが変更のたびに数分で実行されるようにします。変更を頻繁にマージして自動的にテストする継続的インテグレーションと組み合わせることで、テストを、時折の出来事から、絶えず張られた安全網に変えます（トピック3.5 — デリバリーライフサイクル参照）。自動化は人間の判断に取って代わるものではなく、機械にはできない探索的・臨床的なテストを、人間に任せられるようにします。

受け入れテスト。 受け入れテスト、特に*ユーザー受け入れテスト（UAT）*は、実際の臨床家とユーザーが、稼働前に、自分たちの実際の文脈でシステムが機能することを確認する場です。運用受け入れテスト（OAT）は、サービスが運用、バックアップ、復旧できることを確認します。本物のエンドユーザーによるUATは、開発者のテストでは決して見つからない、ワークフローの不一致を捉えます。

テスト環境と安全なテストデータ。 デプロイ環境は、ソフトウェアが動くシステムで、通常は開発、テスト、ステージング、本番の各層です。テストには、本番に似た環境が必要ですが、実際の患者データを安易に使ってはなりません。安全な実践は、合成データ（人工的に生成されたもの）か、適切に匿名化されたデータを使い、紹介フォームのテストが、実際の市民の診断を漏らすことがないようにします。

品質の関門、完了の定義、欠陥管理。 完了の定義は、「終わった」が何を意味するか（テスト済み、アクセシブル、文書化済み、安全レビュー済み）を述べ、品質が機能ごとに交渉可能でないようにします。品質の関門は、変更が進むために通過しなければならない検問所です。欠陥のトリアージは、見つかった欠陥を、重大度と臨床上の影響で評価し、何を、いつ修正し、何を既知の問題として出荷してよいかを決める、規律あるプロセスです。

ベストプラクティス#

1. ピラミッドを築き、テストを左にシフトする。 変更のたびに実行される、速い自動のユニットテストと統合テストの広い土台に投資し、欠陥が、書かれて数分のうちに表面化するようにします。UATで数週間後に見つかるのではありません。遅いエンドツーエンドのテストは、処方、紹介、ID照合といった、少数の重要な旅路のために取っておきます。これにより、テストが安く速くなり、それこそが、チームにテストを増やさせるものです。

2. 回帰テストを、臨床安全の統制として扱う。 あらゆる変更が稼働中の臨床システムに届く前に、自動の回帰テストのスイートが、既存の、安全に関わる振る舞いが、まだ機能していることを確認しなければなりません。DCB0129/0160のハザードログから、最も高いハザードを、名前の付いた回帰テストに直接対応させ、既知のハザードを再び持ち込む変更が、自動的にビルドに失敗するようにします。これが、静かな臨床リスクを蓄積せずに、稼働中のシステムを反復できるようにする仕組みです。

3. 既定では、実際の患者データでテストしない。 テストとステージングの環境を、本番と同じ情報ガバナンスとDPIAの規律の下に置いた、合成データまたは堅牢に匿名化されたデータで用意します（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）。特定のテストが本当に本番に近いデータを必要とするなら、日常的な便宜ではなく、文書化された適法な根拠、最小化、監査を伴う、管理された例外として扱います。テストデータベースも、患者のデータベースです。

4. 非機能要件を、機能要件と同じくらい真剣にテストする。 性能と負荷のテストを、勤務交代、月曜朝のログイン、地域の停止がトラフィックを迂回させるといった、現実的なピーク時の需要に対して実行します。負荷で動きが鈍る臨床システムは、最も重要なときに失敗したからです。セキュリティテストと、Web Content Accessibility Guidelines（WCAG）に照らしたアクセシビリティのテストを、常設の、任意でないテストの種類として含めます。非機能の欠陥は、先送りしやすく、本番で発見すると高くつきます。

5. アクセシビリティのテストを自動化し、そのうえで人で検証する。 自動のWCAGチェックは、問題の意味のある割合（欠けたラベル、乏しいコントラスト、構造）を、ビルドのたびに安価に捕捉しますが、支援技術の実際のユーザーにとって最も重要なものは見逃します。自動スキャンを、スクリーンリーダー、キーボードのみの操作、拡大表示を使う人による手動のテストと組み合わせます。アクセシビリティは、公的機関の法的義務であり、排除されるユーザーが臨床家や、自分のケアを管理する患者であるときは、臨床安全の問題です。

6. 実際の臨床家とともに、現実的な条件でユーザー受け入れテストを行う。 看護師、一般診療医、事務担当者、薬剤師といった、システムを実際に使う人々と、静かな会議室ではなく、病棟やクリニックを映した場で、本物のワークフローを動かして、UATを予定します。彼らのフィードバックは、ユニットテストには見つけられない、危険なワークフローの不一致（誤った瞬間に表示される警告、誤りを誘う既定値）を捉えます。UATが、善意に詰め込まれるのではなく、きちんと行われるよう、臨床の代替要員の時間を予算化します。

7. 完了の定義と品質の関門を、明示的にして徹底する。 自分たちの文脈で「完了」が何を意味するか、つまりテストの合格、アクセシビリティ適合、セキュリティスキャンの問題なし、臨床安全レビューの完了、文書の更新に合意し、それを願いではなく関門として徹底します。書かれてはいるが、納期のプレッシャーの下で日常的に免除される完了の定義は、何もないより悪いものです。安全でない仕事を、完了したものとして洗浄するからです。関門は、静かに飛ばされないよう、可能なところでは自動化すべきです。

8. 臨床上の重大度を念頭に、欠陥をトリアージし管理する。 すべての欠陥を、技術的な重大度だけでなく、ハザードログと同じリスクのレンズを使って、臨床上の影響と可能性で評価します。見た目のバグは待てますが、誤った用量に寄与しうる欠陥は、稼働日にかかわらずリリースを止めます。見える欠陥の台帳を保ち、既知の問題を、隠されたリスクではなく、受け入れられ、軽減されたリスクとして出荷することについて、誠実であってください。

9. テストを、デリバリーのパイプラインの後ではなく、中に組み込む。 自動テスト、セキュリティスキャン、アクセシビリティチェックを、継続的インテグレーションとデリバリーのパイプラインに結びつけ、すべての変更が、進む前にテストされるようにします（トピック3.5 — デリバリーライフサイクル参照）。これにより、品質が継続的で安価になり、テスト済みの修正を素早くデプロイする能力、つまりそれ自体が安全の統制が、常に利用可能になります。手動の、プロジェクト終盤のテストのフェーズは、遅く、遅れ、時間が足りなくなったときに最初に犠牲になるものです。

チームで話し合うための問い#

1. 明日、稼働中の臨床システムで一つのことを変更したら、それがほかの何かを壊した場合に、患者より先に、私たちがそれを知ることに、どれだけ自信があるか。 この問いは、回帰テストの成熟度と、安全についての主張の誠実さを探ります。深刻な臨床ソフトウェアのインシデントの大半は、特殊な新しい失敗ではなく、回帰です。誰もが安定していると想定していた振る舞いを、静かに壊した変更で、臨床家や患者がそれにぶつかって初めて発見されます。良い議論は、最近の実際の変更を、回帰を捉えたはずのテストまでたどり、DCB0129/0160のハザードログで最も高いハザードのそれぞれが、ハザードが再び現れると失敗する自動テストによって裏づけられているかを問います。浮かび上がらせるべき緊張は、修正を速く出荷するプレッシャーと、ほかに何も壊れていないことを証明する規律の間にあり、そしてパイプラインが、その証明を自動にするのか、誰かが確認を覚えていることに任せているのかです。テストスイートの実行にどれだけかかるか、変更のたびに実行されるか、納期に間に合わせるために、誰かが失敗するテストを静かに無効にしていないかを考えてください。誠実な答えは、「臨床ハザードに結びついた回帰スイートがあり、それを信頼している」と、「自分が行った変更をテストして、うまくいくことを祈る」を区別します。答えが後者なら、見えない臨床リスクを抱えていることになります。

2. 私たちのテストデータはどこから来るのか。そして、テストが実際の患者の情報を露出させることはありうるか。 テスト環境は、データ侵害への、ありふれていながら十分に検討されない経路です。プレッシャーの下のチームは、最も手近な現実的なデータ、つまり本番のコピーに手を伸ばし、その結果の患者記録が、より保護の弱いテストシステム、ノートパソコン、サプライヤーの環境に置かれるからです。この問いは、チームに、すべてのテストとステージングの環境をそのデータ源までたどり、実際のデータの「今回だけ」のコピーが日常になっていないかに、正直に向き合うよう求めます。議論すべきトレードオフは、現実性対安全です。合成データと匿名化されたデータは、より安全ですが、実データが含む、乱雑なエッジケースを見逃すことがあり、実データは現実的ですが、ガバナンスと侵害の負債であり、本物の匿名化は見かけより難しい。組み合わせると記録が再識別されうるからです。具体的な視点には、誰がテスト環境にアクセスできるか、テストデータベースが、本番と同じように暗号化され監査されているか、サプライヤーのテスト環境が同じ基準を満たしているかが含まれます。強い答えは、情報ガバナンスの調査を待つ事故ではなく、意図的な戦略を説明します。既定では合成データ、匿名化は適切に行い、実データは、文書化され、最小化され、期限付きの例外としてのみ。

3. 稼働日と品質の基準が衝突したとき、実際に何が折れるのか。そして、誰が決めるのか。 あらゆるデリバリーは、いつか、テストが終わっておらず、欠陥が未解決で、アクセシビリティ適合が不完全なまま、ローンチの日付が迫る瞬間に直面します。その瞬間に組織がどう振る舞うかが、品質が本物の統制なのか、単に願望にとどまるのかを明らかにします。この問いは、チームに、それが最後に起きたときを思い出し、何が削られたかを正直に述べるよう求めます。見た目のバックログだったのか、それとも回帰テスト、UAT、アクセシビリティ監査だったのか。緊張は本物で、払いのけるべきではありません。日付は重要で、資金のサイクルは容赦なく、終わりのないテストもそれ自体が失敗モードになりえます。しかし、解決は、最も声の大きい人ではなく、臨床と公平性のリスクによって統治されなければなりません。キャリアのリスクなしに、品質を理由にローンチを止める権限を持つのは誰か、完了の定義が正式に免除されることがあるか、誰によってか、稼働時に出荷された既知の欠陥が、受け入れられたリスクとして記録されているのか、静かに葬られているのかを議論してください。良い答えは、明確で名前のある決定の経路、日付にかかわらず、それを下回る欠陥がリリースを止める、はっきりした線（患者への害に寄与しうるすべて）、そして「まだです、安全ではありません」と言うことが罰せられず報われる文化を示します。

4. 私たちのテストは、患者を害しうることを実際にカバーしているのか。それとも、テストしやすいことだけをカバーしていないか。 緑のビルドは、その背後のテストが、本物の臨床ハザードを動かして初めて安心できるものです。健全に見えるカバー率の数字が、些末なゲッターとセッターを確認するスイートの上に載りながら、悪化スコア、ID照合、アレルギーの表示が未テストのままであることは、不快なほどありふれています。この問いは、チームに、テストスイートを、DCB0129/0160のハザードログと最もリスクの高いユーザーの旅路に突き合わせ、ハザードごとに、「これがうまくいかなかったら、どの名前付きのテストが失敗するか」と問うよう求めます。緊張は、カバー率の指標が、リスクとの関連ではなく、量に報いるため、チームが、境界値、欠けた入力、珍しい臨床上の組み合わせといった、厄介で自動化しにくい、まさに患者が傷つく場所であるケースに向き合うのではなく、割合を追いかけたくなることです。具体的な視点には、境界とエッジのケースがテストされているか、探索的・臨床的なテスト（機械が置き換えられない判断）が自動化と並ぶ場所を持っているか、実際のインシデントを、テストが捉えるはずだったギャップまでたどった人がいるかを見直すことが含まれます。誠実な答えは、リスクで重み付けされたカバー率について語り、上位のハザードを守るテストを挙げられ、単一のパーセンテージを、アシュアランスであるかのように引用しません。

5. アクセシビリティをテストするとき、その場には実際の障害のあるユーザーと実際の臨床家がいるのか。それとも、自動スキャナーだけか。 自動のWCAGチェックは安価で、あらゆるビルドに属しますが、実際に人々を排除する障壁の一部しか検出せず、サービスは、あらゆる自動ルールに合格しながら、スクリーンリーダーやキーボードだけでは使えないままでありうるのです。この問いは、アクセシビリティとユーザー受け入れテストが、支援技術を使う実際の人々や、本物のワークフローを動かす実際の臨床家に届いているのか、それとも「アクセシビリティをテストした」が静かに「スキャナーが緑だった」を意味しているのかを問います。浮かび上がらせるべきトレードオフは、コストとロジスティクス対誠実さです。支援技術のユーザーを募り、現実的なUATのために臨床の代替要員の時間を確保することは、高価で省きやすいものですが、それを省くことが、法的義務を侵害し、誤った瞬間の警告、誤りを誘う既定値のような危険なワークフローの不一致が、稼働中の病棟に届く仕方です。誰を巻き込むか、彼らがどれだけ代表的か、テストが、静かな会議室ではなくクリニックを映した場で行われるか、彼らが見つけたものをどうするかを議論してください。強い答えは、自動チェックを、障害のあるユーザーによる手動のテストと臨床家主導のUATと組み合わせたものを、稼働前に一度チェックを入れる項目ではなく、常設で予算化された実践として説明します。

6. 変更が、私たちのシステムと誰かほかのシステムの境界を越えるとき、誰がその接合部をテストするのか。そして、壊れたらそれに気づけるか。 現代の医療・ケアサービスは、統合されたシステムの組み合わせです。電子カルテ、国のスパインサービス、病理のフィード、サードパーティのサプライヤーのモジュール。最も危険な欠陥は、しばしば、どれか一つの部品の内側ではなく、それらの間の継ぎ目にあり、インターフェースの片側での変更が、もう一方を静かに壊します。この問いは、チームに、重要な連携を描き、それぞれについて、誰がエンドツーエンドのテストを所有するか、どんな合成データが境界を越えて流れるか、サプライヤーのリリースでの破壊的変更が、患者に届く前にどう検知されるかを問うよう求めます。緊張は、共有のインターフェースに対して、どの一つのチームも全面的な責任を感じず、契約と変更諮問委員会は異なる速度で動き、組織の境界をまたぐテストは、遅く、政治的で、なりゆきに任せがちなことです。具体的な視点には、契約テストとインターフェーステスト、共有のテスト環境、サプライヤーの変更通知の扱い、そして回帰スイートが、自分たちの半分だけでなく、統合された旅路（紹介が送信され、受信され、受領確認された）を動かしているかが含まれます。誠実な答えは、それぞれの接合部に責任を負う人を挙げ、相手がカバーしていると想定するのではなく、境界をまたぐ回帰を、可能なところでは自動化して捉える仕組みを示します。

実践例：医療・ケアの事例#

ある急性期NHSトラストは、電子患者記録の中に、新しい電子観察と早期警告スコア（EWS）のモジュールを導入しており、看護師がバイタルサインを記録し、システムが悪化スコアを計算する、紙のチャートを置き換えます。臨床上のハザードは明白です。誤ったスコアは、悪化している患者がエスカレーションされないことを意味しうるのです。

チームは、最初からピラミッドを築きます。ユニットテストは、国のスコアリングルールに照らしたEWSの計算を、境界のケース（スコアがエスカレーションへ傾く正確な閾値）と厄介な入力（欠けた呼吸数、酸素投与中の患者）を含めてカバーします。統合テストは、スコアが、エスカレーションのアラートと看護タスクリストに正しく流れることを確認します。少数のエンドツーエンドのテストが、ベッドサイドでの入力から、起動されたアラートまでの旅路全体を動かします。DCB0160のハザードログの各ハザードは、名前の付いたテストに対応づけられ、スイート全体が、継続的インテグレーションのパイプラインで、変更のたびに自動的に実行されます。

テスト環境は、悪化の軌跡を含む、現実的なバイタルサインのパターンを持つ合成患者で用意され、実際の記録が本番を離れることはありません。性能テストは、勤務交代時の病棟回診全体を模擬し、ピーク負荷の下でアラートが数秒以内に発せられることを確認します。ビルドのたびに自動化され、画面拡大を使う看護師による手動での検証も行われるアクセシビリティのテストが、コントラストの低いアラートのバナーを捉えます。

パイロット病棟での、実際の看護師が模擬シナリオを動かすUATが、開発者の誰も見ていなかったワークフローの欠陥を浮かび上がらせます。確認のダイアログがスコアの後に表示されるため、職員が反射的にそれを却下しがちになるのです。チームは導線を再設計し、回帰テストを追加します。稼働時、見た目の欠陥3件は、文書化された、受け入れられた問題として出荷され、計算に触れる2件は修正され、テストに通るまでリリースを止め、安全性ケースはテストのエビデンスを直接引用します。稼働から6か月後、タスクリストへの通常の変更が、検出されなければエスカレーションのアラートを抑止したであろう回帰テストを引っかけます。パイプラインで捕捉され、デプロイ前に修正され、病棟に届くことはありませんでした。

セクター別の視点#

スタートアップ#

小さなデジタルヘルス企業は、解きほぐすべき手動のテストプロセスがなく、初日から自動テストと継続的インテグレーションを自社のDNAに組み込める利点があり、大きなトラストが羨む、速く安全な反復を実現できます。危険は、プロダクトマーケットフィットを追う間、テストを先送りする贅沢として扱い、まだどの初期顧客も求めていない、非機能と臨床安全のテストを削ることです。創業者は、DCB0129の義務が、会社の規模にかかわらず製造者に課されるため、収益前であっても、安全性の主張の裏づけとなる回帰のエビデンスは任意ではないことを忘れてはなりません。合成テストデータも、スタートアップの味方です。会社が安全に扱う統制を持つ前に、実際の患者データを扱うガバナンスの負担を避けられます。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、単独拠点のクリニックは、通常、臨床システムを作るのではなく購入するため、そのテストの仕事は構築ではなく受け入れです。サプライヤーの更新や新しい連携が、職員が頼る前に、実際のワークフローの中で安全に機能することを確認します。専任のIT能力がほとんど、あるいはまったくない場合、実務上の規律は、サプライヤーの変更のたびに、最もリスクの高い旅路（予約、処方、観察値の記録）に対して実行する、短く再現可能なチェックリストであり、理想的には、実際の記録ではなく合成患者を使った、テストや研修の環境で行います。大きなトラストと同じDCB0160の導入安全とアクセシビリティの義務が適用されますが、テストチームはないため、現実的な手は、サプライヤーのアシュアランスに頼りながら、自分たちにしかできない少数の地域での受け入れチェック、つまりこのクリニックの実際の働き方に合うかを保持することです。これすら飛ばして、変更を実際の患者で直接テストする小規模な提供者は、捕捉する手段のない安全インシデントから、一つの悪い更新の距離にあります。

大企業#

NHSトラストや大手サプライヤーは、大規模に、完全なアシュアランスの下でテストを運営します。専用のテスト環境、臨床の代替要員を伴う正式なUAT、運用受け入れテスト、セキュリティのペネトレーションテスト、稼働中の臨床システムへのリリースに関門を設ける変更諮問委員会。特徴的な課題はレガシーです。自動テストのカバー率が薄い、大きく古いシステムでは、何が壊れうるか誰も確信を持てないため、あらゆる変更が恐れられ、遅く高価な手動の回帰サイクルを生みます。戦略的な手は、最もリスクの高い領域の周りの自動テストのカバー率に、着実に投資し、恐れを自信に、遅いリリースを速く安全なものに変えることです。大企業は、統合されたシステムをまたいでテストする、調整の負担も負います。一つのサプライヤーの製品の変更が、別のサプライヤーのものを壊しうるからです。

政府#

国の機関は、Service Standard、公表されるサービス評価、公的な説明責任の最高の基準の下でテストを行い、全国的なシステムでのテストの失敗は、何百万人にも影響し、議会に達しうるものです。WCAGに照らしたアクセシビリティのテストは、公共部門の機関に対して執行される法的義務であり、国の規模での非機能テスト、つまり負荷、レジリエンス、セキュリティは、任意ではなく存続に関わるものです。課題は、多くのサプライヤーと統合されたサービスにまたがって品質保証を調整し、広がるプログラム全体で、一貫した完了の定義を保つことです。国のサービスは、エコシステムも形づくります。政府の機関が義務づけたり公表したりする、テストデータ、ツール、標準は、サプライヤーが従って構築する標準になります。

よくある失敗パターン#

• 逆さまのピラミッド。 テストが主に、遅い手動のエンドツーエンドの確認で、フィードバックは遅く、カバー率は薄く、回帰テストは時間のプレッシャーの下で飛ばされる。対策：速い自動のユニットテストと統合テストの広い土台に投資する。
• 最終フェーズとしてのテスト。 テストが、稼働前に詰め込まれる段階で、スケジュールが遅れたときに最初に削られる。対策：シフトレフトし、テストを継続的インテグレーションのパイプラインに結びつけて、継続的で安価にする。
• テスト環境の実データ。 現実性のために、実際の患者記録が、保護の弱いテストシステムにコピーされ、侵害を待つ状態を生む。対策：既定では合成・匿名化データ。実データは、ガバナンスされた例外としてのみ。
• ビルドは緑だが、自信がない。 テストは通るが些末なことをカバーし、本物の臨床ハザードは未テストのまま。対策：テストを、ハザードログと最もリスクの高い旅路に明示的に対応づける。
• 自動の形式チェックとしてのアクセシビリティ。 自動スキャンの合格が適合として扱われ、実際の支援技術のユーザーは一度も関与しない。対策：自動チェックを、障害のあるユーザーによる手動テストと組み合わせる。
• 免除される完了の定義。 「完了」は定義されているが、納期のプレッシャーの下で日常的に覆され、安全でない仕事が完了したものとして出荷される。対策：関門を自動化し、品質を理由にローンチを止める権限を誰かに与える。

成熟度モデル#

チェックリスト#

• テストピラミッドがある：広い自動のユニット/統合のカバー率、少数のエンドツーエンドのテスト、すべて継続的インテグレーションで実行される。
• DCB0129/0160のハザードログの最も高いハザードのそれぞれが、名前付きの自動の回帰テストに対応づけられている。
• 回帰スイートが実行され、あらゆる変更が稼働中の臨床システムに届く前に、合格しなければならない。
• テストとステージングの環境が、合成または匿名化されたデータを使い、実際の患者データは安易に使われない。
• 重要な臨床の旅路について、現実的なピーク時の需要に対して、性能と負荷のテストが行われている。
• セキュリティテストとWCAGのアクセシビリティテスト（自動＋支援技術のユーザーによる手動）が常設のテストの種類である。
• ユーザー受け入れテストが、現実的な条件で、実際の臨床家と、予算化された代替要員の時間を伴って行われている。
• 完了の定義と、徹底された品質の関門があり、納期のプレッシャーの下で静かに免除されない。
• 欠陥が臨床上の影響でトリアージされ、稼働時に出荷される既知の問題が、受け入れられ、軽減されたリスクとして記録されている。
• テストのエビデンスが、臨床安全性ケース報告書で直接引用されている。

主要な情報源#

• NHS England Digital — DCB0129とDCB0160の臨床リスクマネジメント標準、ハザードログと臨床安全性ケース報告書。
• NHS England — NHS Service StandardとNHS Digital Service Manual（アクセシビリティ、テスト、信頼できるサービスの運用）。
• GOV.UK Service Manual (Government Digital Service) — テスト、テストデータと環境、アクセシビリティ、継続的デリバリーのガイダンス。
• W3C Web Accessibility Initiative — Web Content Accessibility Guidelines (WCAG) 2.2とテスト技法。
• NHS England — Digital Technology Assessment Criteria (DTAC)。臨床安全、技術的アシュアランス、使いやすさ/アクセシビリティを含む。
• ISTQB (International Software Testing Qualifications Board) — テストの基礎的な用語とテストレベル。
• 2018年Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations。
• Mike Cohn — テストピラミッドの概念。Martin Fowler / Continuous Delivery (Humble & Farley) — テストの自動化とCI/CDの実践。

参考文献#

1. Software testing — Wikipedia — https://en.wikipedia.org/wiki/Software_testing
2. Quality assurance — Wikipedia — https://en.wikipedia.org/wiki/Quality_assurance
3. Unit testing — Wikipedia — https://en.wikipedia.org/wiki/Unit_testing
4. Integration testing — Wikipedia — https://en.wikipedia.org/wiki/Integration_testing
5. Shift-left testing — Wikipedia — https://en.wikipedia.org/wiki/Shift-left_testing
6. Non-functional testing — Wikipedia — https://en.wikipedia.org/wiki/Non-functional_testing
7. Regression testing — Wikipedia — https://en.wikipedia.org/wiki/Regression_testing
8. Test automation — Wikipedia — https://en.wikipedia.org/wiki/Test_automation
9. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
10. Acceptance testing — Wikipedia — https://en.wikipedia.org/wiki/Acceptance_testing
11. Web Content Accessibility Guidelines — Wikipedia — https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
12. Deployment environment — Wikipedia — https://en.wikipedia.org/wiki/Deployment_environment
13. Synthetic data — Wikipedia — https://en.wikipedia.org/wiki/Synthetic_data
14. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
15. NHS service standard and NHS digital service manual — NHS England — https://service-manual.nhs.uk/
16. Testing your service, and test data and environments — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology
17. Web Content Accessibility Guidelines (WCAG) 2.2 — W3C Web Accessibility Initiative — https://www.w3.org/WAI/standards-guidelines/wcag/
18. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-tools/digital-technology-assessment-criteria-dtac/
19. Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018 — UK Government / GOV.UK — https://www.legislation.gov.uk/uksi/2018/952/contents/made
20. Continuous Delivery — Jez Humble and David Farley — https://continuousdelivery.com/