ソフト開発監査チェックリスト（１４）テスト管理技術（前半）
ソフト開発監査のチェックリストのチェック項目を順に紹介していきます
ソフト開発監査は、ソフトの開発委託先の能力を判定するためにグータラ親父が勝手に命名した監査の方法です。ソフト開発監査の概要や監査時の事前の準備や監査当日の作業内容については、他の記事で紹介しています。また、ソフト開発監査で使う監査チェクリストの使用時のポイントについても、別の記事で紹介していますので、そちらをご覧ください。
この前後の記事では、以下の４つの種類のソフト監査チェックリストの個々の項目について、順番に紹介していきます。
- 開発プロセスのチェックリスト
- 開発技術の１つ目の要件管理のチェックリスト
- 開発技術の２つ目のテストのチェックリスト
- 開発技術の３つ目の設計と実装のチェクリスト
この記事では、前の記事で紹介した開発プロセスのチェックリストに続いて、開発技術の１つ目の要件管理のチェックリストについて各々のチェック項目を紹介します。なお、要件管理のチェックリストを使う時のポイントについては ソフト監査実務・監査当日その９：テスト技術のチェックのポイント の記事で紹介していますので、そちらも一緒に読んで頂くと判り易いと思います。
ソフト開発技術の３つの要素の２つ目はテストの確認です
この記事では、ソフト開発技術について２つめのテストのチェックリストについて紹介していきます。ソフト開発技術では、開発の入り口の要件管理が一番大切で２番目に大切なのがテストです。何を作るかの要件管理がちゃんと出来ていても、その要件通りにちゃんとソフトが作られていないと良いソフトにはなりません。
要件どおりのソフトが作られているかを確認する直接的な方法がテストです。テストでは要件どおりの機能が作りこまれているか、という機能要件の確認と合わせて、性能や応答性や信頼性や堅牢性などの非機能要件についても、要求仕様どおりにできている事を確認する必要があります。そのようなテストの工程がしっかりと出来ているかをソフト開発監査で確認します。
ソフト開発監査がグータラ親父が勝手に作った仕組みなので、他のチェックリストと同じようにこのチェックリストも何かの規約とか標準があるわけではありません。単にグータラ親父はこんなのを勝手に作って使っていたというだけです。それでもまあ、開発委託先のテストに関する開発技量の判断の参考には使えると思います。ここに載せておきますので、このリストも参考に見ながら記事をご覧くださ
テストチェックリスト
（クリックするとpdf が開きます）
テストのチェックリストも１行が１つのチェック項目となっていて、横方向には６つの欄があります、６つの欄の使い方は開発プロセスのチェックリストと同じですので、各々の欄の使い方については、前の記事の ソフト監査実務・チェックリストその１：開発プロセス（要件管理）をご覧ください。
テストのチェックリストは以下の２つの大項目に分類してあり、それぞれの分類の頭文字を持ったID番号が付けてあります。
- テスト管理（TM-） ：テスト作業の計画や管理についての確認
- テスト内容（TC-) ：テストの具体的な内容についての確認
それでは、さっそく紹介していきましょう。テストのチェックリストも見ながら記事を読んでいただくと判り易くなると思います。
テスト管理に関するチェック項目では計画と実績のトレースと不具合管理を確認します
テスト管理は主にテストの計画と実績のトレースとテスト成果としての検出した不具合の取り扱いについての作業を確認していきます。しかしその前に、テストの名前と定義の確認をしておきます。テストの名前やその定義は開発組織によって結構バラツキがあります。グータラ親父の会社では、開発部門が複数あったのですが、部門が違うと同じ結合テストという名称でもその定義に違いがありました。一つの会社の中でもこうなのですから、会社が違ったりさらには国が違うと、テストの名前とその定義が自社と違っている事のほうが多いです。
ですので、テスト管理に関するチェック項目の前半は、テストの名前や定義や目的の確認が多くを占めています。 チェック項目の後半では、テストの計画や一部はテストの質について確認項目も入ってきます。 それでは、順番に項目を紹介していきましょう。
【項目番号：TM-01】
まずは、委託先の会社でどんな名前のテストを行っているのか、テストの名前を確認します。一般的な単体テスト、結合テスト、システスト、妥当性確認 というテストの名前を使っているのか、もっと別のテストの名前を使っているのか、まずはその会社で使っているテストの名前を確認します。次に、それぞれの名前のテストの定義を、できるだけ具体的に教えてもらいます。何を確認する事を目的としたテストなのか、誰が実施するテストなのか、テストの責任部門はどこなのか、等を聞き取る事でテストの定義を確認していきます。
【項目番号：TM-02】
TM-01で委託先の会社の使っているテストの名前と定義を確認できたので、次はそれらのテストを一般的なテストの目的との対応付けを整理します。テストの目的は少し見方を変えるとテストの種類分けでもあるので、グータラ親父はテストカテゴリという単語を使っています。例えば、機能を確認するテストなら機能テストというテストカテゴリ、性能を確認するなら性能テストというテストカテゴリ、というようにテストを目的ごとに種類分けしたものを、テストカテゴリと呼んでいます。
そして、グータラ親父は Glenford Myers 氏が 1979年に書いた The Art of Software Testing にある15種類のテストカテゴリに Long run test というカテゴリを1つ足した 16種類のテストカテゴリを使っています。この 16種類のテストカテゴリに属するテストを、委託先の会社の使っているテストの名称と対応付けて整理すると、どんな目的のテストをどの名前のテストで実施しているかが判ってきます。
【項目番号：TM-03】
ソフトの品質を保証するのは、最終的にはテストしかありません。ですので、必要十分な量と質のテストが実行されているかどうかの確認は、とても大切です。色々な名称のテストがありますが、ソフトの品質を保証するテストとしては、やはりテスト計画の最後のほうに位置するシステムテストや妥当性確認テストが重要です。
ですので、システムテストと妥当性確認テストの２つに絞って、テストの量を確認します。テストの量といっても、何で表すのか特に決まりは無いのですが、一番判り易いのはテストの設計や実施に必要な担当者の作業工数（人日）やテスト項目の件数です。それらの値をソフトの規模で割り算してテスト密度に変換してから、自社の類似の製品と比べる事で委託先で実施しているテストの量が不足していないかどうかを判断する一つの情報が得られます。