ソフト開発監査の監査当日（９）テスト技術のチェックのポイント
テスト技術はテストの量と質と管理に注意して監査をします
この記事では前の記事に続いてソフト開発監査の４つのチェックリストのうち３つ目の、テストのチェックリストについて、チェックリストを使って監査を行う時のポイントを紹介します。開発プロセスのチェックリストと同じように、各々のチェック項目については ソフト監査実務・チェックリストその１４：開発技術・テスト（テスト管理・前半） の記事で紹介していますので、具体的な項目に興味のある方は先にそちらの記事をご覧ください。
以下にチェックリストの例を載せてありますので、こちらも見ながら記事をご覧ください。
テストチェックリスト
（クリックするとpdf が開きます）
テストのチェックリストはテストの量と質とテスト管理を順に確認します
ソフト監査チェックリストの３つめはテストに関する確認項目を集めたテストのチェックリストです。テストはソフトの品質を保証するために最も重要な作業です。開発委託先が品質の良いソフトを提供してくれるかどうかは、開発委託先のテストの内容に大きく影響されます。ですのでテストの量とテストの質さらにテスト管理の状況を確認する事で、相手先の組織のテストに関する技量の善し悪しを推し量ります。
ところで、テストの技量って何をどうやったら確認できるのでしょうか？ 一言にテストと言ってもソフト開発と同じ様に色々な技術領域があっていろんな見方があるので、一概に善し悪しを判断できるものでもありません。とはいえ、テスト技量の善し悪しは確かに存在するので、テスト技量が悪い会社には開発を委託したくはありません。
また、ソフト開発監査では半日から１日という短い時間で開発委託先が充分なテスト技量を持っているかどうかを判断する必要があります。場合によっては、当社が要求するレベルまでテスト技量を向上さてもらうための指導が必要な事もあります。そこで少しばかり正確性に欠ける点はありますが、グータラ親父はテストについて ①テストの管理 と ②テストの内容 の２つの視点で確認を行い、その確認作業の中で相手先の会社のテスト技量を判断していました。
まずはテストの名前と定義から相手の会社のテストの体系を知る
ところで、グータラ親父はソフト開発監査でテストの確認をする前に毎回必ず行っている事があります。それは、開発委託先の会社が実施しているテストの名前とその定義の確認です。なぜそんな事をするのでしょうか？
実は、単体テストとか結合テストという一般的な技術用語を使ったとしても、会社によってその定義にかなり差があるからです。そのために、最初に定義を確認しておかないと議論が噛み合わなくなる事が起こり得ます。例えば単体テストを例にとると、コード作成者がデバッガを使って全ての実行コードや分岐コードのパステストをする事を単体テストとしている会社もあれば、モジュールや関数の単体機能の動作確認を単体テストとしている会社もあります。
ところで皆さんの会社ではどんな名前のテストがありますか？ ソフトのテストの名前というと、一般的には単体テスト、結合テスト、システムテスト 等があります。英語にすると unit test, integration test , system test といった所でしょうか。これはテストを開発の段階（フェーズ）に分けて呼ぶ時の名前です。テストをその目的で分けた、機能テスト、性能テスト、異常回復性テスト、高負荷テスト などのテストの名前も聞いたことがあると思います。さらには、フルテスト、部分テスト、回帰テストというテスト名前もありますね。世の中の全ての会社が同じテストの名前を使っている訳でもないのが現実です。
ソフトのテストの名前について、全世界で共通の明確な定義があると良いのですが、残念ながらその様な定義がないのが現状です。 そのため、テストの話を始める前に、まずその会社で実施しているテストの名前とその定義を確認しておかないと、議論がかみ合わなくなってしまう事もあります。ですので、グータラ親父はまず最初にテストの名前と定義の確認をしていました。
テストチェックリストでの確認時の注意点
相手先の組織が使っているテストの名前とその定義が確認できたら、いよいよチェックリストを使って①テストの管理 と ②テストの内容について確認をしていきます。
①のテストの管理は、プロセスチェックリストの項目と重なる部分もあるのですが、もう少し具体的な内容の確認になります。主にテストの質を確認するために、16種類のテストカテゴリを提示して、どのカテゴリのテストをどの程度実施しているのかとか、各々のカテゴリのテストをどの組織で実施しているのかとか、テストの管理に使っているメトリクス（管理の指標）は何があるのか、等を確認していきます。
このテストカテゴリは、グータラ親父がテストの考え方を整理する時にバイブル的に使っていた、The Art Of Software Testing という本に載っているテストを目的別に分類した物です。 テストカテゴリについては別の記事で少し詳しく紹介していますので、興味のある方はそちらの記事もご覧下さい。
このテストカテゴリは、本来はテスト設計の時に使うものなのですが、テストカテゴリを使って監査先のテストの計画や実施の状況を確認する事で、監査先の組織のテストに関する考えを具体的に把握する事ができ、テスト管理の状況の善し悪しを推測する時の手助けになりました。 まあ、簡単に言えば機能確認以外にどんな目的のテストをどんな組織で実施していて、テストの進捗やバグの管理をどんな手段で実施しているのか、等を注意して確認しきいました。
②のテストの内容では、組み込み系でのソフトウエアの潜在バグとしてよく発生する、メモリや資源のリークや２重解放、フラッシュROMのアクセスに関するテスト等について、テストの内容まで少し踏み込んだ項目を確認していきます。それらの個々の項目の確認を行いながら、監査対象の組織の開発リーダやテストリーダが個々の問題点について重要性をどこまで認識しているか、その対策方法をどこまで知識として知っているか、その知識を開発プロジェクトにどの様に活用しているか、という点に気を付けて、相手先のテスト技量を推定していきます
テスト技術の次は設計と実装の技術の確認です
以上がテスト偽技術について監査をする時に、グータラ親父が注意していた点です。ソフト開発監査の作業はソフト監査チェックリストに従って１つ１つ具体的なルールと実際の作業を確認してくのですが、その確認作業を進める時に、どんな観点に注意していたかをまとめるています。皆さんがソフト開発委託先を評価する時の参考になれば、幸いです。
それでは次の記事では、ソフト開発監査で設計と実装の技術についての監査を行う時の注意点を紹介します。