要求からテストまでのトレーサビリティ

トレーサビリティとは何か - 要求・設計・実装・テストをつなぐ考え方

トレーサビリティとは、ひとつの要求が設計・実装・テストのどこに反映されたかをたどれる状態です。どのように検証されたかまで、確認できることが条件になります。要求番号から設計書、ソースコード、テストケースまで、対応関係を確認できる必要があります。

要求と設計、テストの対応関係については、別記事で扱いました（「V字モデルで学ぶテスト工程と品質保証」参照）。トレーサビリティは、この対応関係を記録として残したものです。記録を残すことで、いつでも追跡できる形に発展させたと考えると理解しやすくなります。

要求は、仕様変更や派生機種の追加、不具合修正のたびに変化します。そのたびに、要求と成果物の対応は少しずつずれていきます。対応関係をそのつど記録しておかないと、後から全体を把握することは難しくなります。気づいたときには、どこまで対応が取れているか分からない状態になっています。

追跡できないと何が起きるか

トレーサビリティが確保されていない開発現場では、次のような問題が起きます。

• 仕様変更が発生した際に影響範囲が分からず、修正漏れやテスト漏れが発生します。
• どの要求に対してテストを実施済みか把握できず、テストの網羅性を証明できません。
• 市場で不具合が発生したとき、原因となった要求や設計を特定できません。
• 後任担当者や監査担当者に対し、なぜその実装を選んだのかを説明できません。

これらの問題は、開発規模が大きくなるほど、また開発期間が長くなるほど深刻になります。量産後も長期間保守が続く組み込み機器では、特に顕著です。数年後に担当した技術者が判断根拠をたどれず、同じ不具合を再発させる例も見られます。原因究明の手順についても、同じことがいえます（「不具合起票の方法と修正フロー」参照）。要求までさかのぼれるトレーサビリティがあってはじめて、その手順は機能します。

テストの網羅性を示せない問題も見過ごせません。テストを実施したという事実だけでは、必要な要求を検証した証拠になりません。どの要求にどのテストが対応するかを示せてはじめて、網羅性を主張できます。

追跡できない状態を放置すると、修正のコストも膨らんでいきます。仕様変更のたびに、影響範囲を人手で全体確認する作業が発生するためです。確認作業そのものが、開発スケジュールを圧迫する要因になります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

規格が求めるトレーサビリティ - IEC 61508とIEC 62304

機能安全に関する国際規格に、IEC 61508があります。電気・電子・プログラマブル電子安全関連系を対象とする規格です。そのうちソフトウェア要求事項を扱う第3部の附属書には、重要な記載があります。要求から設計・テストへ向かう前方向のトレーサビリティが、達成すべき目標として明記されています。実装から要求へさかのぼる後方向のトレーサビリティも、同じく明記されています。

安全度水準（SIL）が高くなるほど、求められる範囲は広がります。安全要求と検証テストの対応関係を、監査できる形で残すことが必要になります。安全機能を持たない一般的な組み込み機器でも、この考え方は参考になります。規格が求める水準を知ることで、自社の管理レベルを見直す基準になるためです。

医療機器ソフトウェアを対象とするIEC 62304も、参考になる規格です。この規格は、ソフトウェアのライフサイクルプロセス全体を規定しています。ソフトウェア要求事項を定めたうえで、その要求に対応するテストを実施します。実施結果を記録することも、開発プロセスの一部として求められています。安全上のリスクが高い区分に分類されたソフトウェアほど、管理が厳格になります。要求とテストの対応関係を、より厳格に管理する必要があります。

両規格に共通するのは、トレーサビリティを個人の記憶に任せない考え方です。資料の整理整頓に任せるのではなく、監査可能な記録として残します。品質保証の観点からも、証跡は重要です（「開発に求められる品質と信頼性」参照）。対応関係を、証跡として残す仕組みが欠かせません。

トレーサビリティマトリクスの作り方と使い方

トレーサビリティマトリクスとは、要求とテストケースの対応関係を一覧化した表です。行に要求番号、列に設計書やテストケースの番号を並べます。対応するセルには、実施状況や結果を記録します。

• 要求仕様書の各項目に、一意の要求IDを付与します。
• 要求IDごとに、対応する設計書やソースコードの該当箇所を記録します。
• 作成したテストケースに、要求IDをひも付けます（「ソフトウェアテストの設計、実施」参照）。
• テスト実施後、結果と実施日、担当者をマトリクスに記録します。

たとえば温度異常を検知して警告を出す要求があるとします。要求IDを一件付与し、対応する設計書の章番号を記録します。実装したソースファイル名と、検証したテストケース番号もあわせて一行にまとめます。行を横に見るだけで、対応関係の抜けに気づけるようになります。

マトリクスは、要求からテストへの方向だけでなく、テストから要求へ逆にたどれることも重要です。この双方向の対応関係を、双方向トレーサビリティと呼びます。実施したテストケースを見ても、どの要求を検証しているのか分からない状態は問題です。テストが冗長になったり、検証されていない要求が見落とされたりします。

マトリクスの精度を高めるには、テストケースの作成段階から要求IDを意識することが有効です。テストケースのレビューの場でも、要求IDの記載を確認します。対応する要求IDが記載されているかを、確認項目のひとつに加える方法です。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

組み込み開発ならではの難しさ

組み込みソフト開発では、トレーサビリティの維持が特に難しくなる事情があります。ハードウェア仕様の変更が、ソフトウェアの要求そのものに波及することが少なくありません。手戻りの多くも、同じ原因によるものです（「開発の全体像と手戻りを防ぐ設計」参照）。ハード変更の情報が要求段階まで届いていないことが、その原因になります。

量産後に派生機種を展開する製品では、ソースコードが機種ごとに枝分かれします。共通部分を変更した際に、影響範囲を追いきれないことがあります。一部の機種だけ、要求への修正やテストが漏れる事態も起こります。変更を加えた際は、回帰テストの考え方が役立ちます（「エンバグを防ぐ回帰テスト」参照）。回帰テストの範囲を、要求単位で判断する必要があります。

検証環境や治具の制約も、対応関係を崩す要因になります。実機やハードウェアの治具が揃うまで、実施できないテストがあるためです。要求の追加や変更から時間が空くほど、対応関係の記録は担当者の記憶に頼りがちになります。

テスト結果の管理方法にも課題があります。テストケースはExcelファイルで管理し、実施記録は紙の帳票に残す運用が今も多く見られます。ファイルや帳票が担当者ごとに散在すると、対応を確認しづらくなります。要求とテスト結果の対応関係も、あわせて見えにくくなっていきます。

運用を続けるコツ - 完璧を目指さず、粒度を揃え、自動化できる部分を切り分ける

• 最初から完璧なマトリクスを目指さず、重要な要求から段階的に整備します。
• 要求やテストケースの粒度をチームで揃え、対応表が細かすぎたり粗すぎたりしないようにします。
• 対応関係の記録や更新のうち、自動化できる部分と人手で判断すべき部分を切り分けます。

粒度がチームで揃っていないと、マトリクスの行数が担当者ごとに大きく変わってしまいます。後から見た人が、対応関係を正しく解釈できなくなる原因になります。最初にIDの命名規則と粒度の目安を決めておくと、後々の混乱を防げます。

テストの実行結果とエビデンスが自動で記録され、レポートとして出力される環境があります。そうした環境を整えれば、対応関係を人手で転記する作業が減ります。実行のたびに結果と証跡が残る仕組みがあれば、維持コストは大きく下がります。限られた人手を、対応関係の設計そのものに振り向けやすくなります。

• テスト支援システムの商品情報はこちら
• PDFで詳しく見る

まとめ

トレーサビリティとは、要求が設計・実装・テストのどこに反映されたかを追跡できる状態です。どう検証されたかも、あわせてたどれることが条件になります。追跡できないと、影響範囲の見落としや、説明責任を果たせない事態につながります。IEC 61508やIEC 62304も対応関係の記録を求めています。マトリクスを段階的に整備し、自動化できる部分から着手することが、無理なく続ける近道です。