成果物の試験(テスト)を面倒にしているのは”やり方”が悪いから ～重要なのは後ろを振り返らない事～

本記事は、株式会社ギックスの運営していた分析情報サイト graffe/グラーフ より移設されました（2019/7/1）

効率的な試験をしてますか？ 数でごまかしていませんか？

システム開発やデータ分析結果などでは、できた”成果物”が求められた要求に対し正しいかをする確認するための”試験”が付き物です。これはモノづくりの重要な工程ではありますが、地味なくせにやることが多く、全く華々しい作業ではないため、毛嫌いされることが多い作業です。だからこそ効率的にやる事が重要なのですが、経験からすると非常に無駄で非効率な事に時間を取り、自分で自分の首を絞めている現場が多かった気がします。今回は細かい試験工程の話ではなく、効率的に試験を行うための”視点”について説明します。

目的を失った無駄な試験

システム開発の現場では、システム規模の指標としてプログラムのステップ数(行数)を指標としている文化が残っているところもあり、そのステップ数から試験項目数の概算数、または目標数を出す場合があります。確かにある程度の規模になると、作業者のレベルも様々ではあるため、「プログラムステップ数＝試験項目数」という指標はあながち間違ってはないと思いますが、ただ「試験項目数に満足して試験の本位」を忘れている気がします。
例えば、同じ処理を行う複数のデータで試験していませんか？ 各営業所の売上を求めるようなデータ分析があった時、違う営業所でも同じ属性の場合、結果として同じ処理を繰り返すのにもかかわらず、「10営業所中の3営業所が大丈夫ならOK」みたいなサンプリング的な試験をしていませんか？ (勿論、この試験は試験の最終段階では問題ありませんが) また、複数の作業者が同じ試験をしていることはありませんか？

”インプット”と”アウトプット”を明確にしろ

プロジェクトとして複数人でシステム開発やデータ分析をする場合、各作業者に担当を割り振ることが多いです。これが試験の単位となるため明確にする必要があります。
担当となる機能・作業範囲を明確にするためには2つの単位に分けることから始まります。これがインプットとアウトプットです。インプットには、入力元となるデータベースのテーブルやファイル、そして要件として制約事項や動作条件などが含まれます。また、アウトプットには出力先のテーブルやファイル、そして要件が実現できているかなどが入ります。
各作業の担当者は、インプットとアウトプットが依頼された物になっているかを試験する必要があり、作業を振り分ける人は、このインプットとアウトプットを明確、相互の担当・機能間で矛盾なく伝える必要があります。

重要なのはポイントを抑える事

上記で担当者の試験範囲を明確に決めることで担当外の試験を行う無駄は無くなりました。次に担当範囲内での無駄な試験を考えます。
これはシステム開発の試験の「ホワイトボックス試験」をベースに考えれば良いのですが、全てを意識する必要はありません。重要なのはアウトプットを出すために、どの処理をどの手順で行っているかを考えて試験を組み立てれば良いのです。
例えば以下のようなデータ集計処理を行っていたとします。

1. 売上履歴データから先月分のデータを抽出
2. 売上履歴データに商品マスタを結合
3. 結合結果から商品マスタの商品カテゴリごとに集計

そして、上記をアウトプットが正しいことを証明するためには以下の試験を行います。

1. 売上履歴データの抽出範囲が正しい事
2. 売上履歴データに商品マスタの結合条件が正しい事
3. 結合結果から商品マスタの商品カテゴリごとに集計されている事

この時、”抽出範囲が正しい事”を証明するためには、どのような試験が必要でしょうか？ 抽出件数が正しいことも重要ですが、「しきい値」が正しいかも重要です。条件が”先月分”なのですから、先月の月初と月末のデータがある事、そして、先々月末と今月初めのデータがないことを確認します。そのため、それ以外の日付のデータ有無を確認しても無駄な試験となります。

”依存関係”と”処理の纏まり”を意識して試験順番を考えろ

試験をしていると必ず付きまとうのが”出戻り”です。途中でバグ(障害)が見つかった、試験項目に誤りがあったなどの理由でもう一度試験をやり直すことは日常茶飯事です。だからと言って許容されることでななく、”出戻り”の規模によってはプロジェクトのスケジュールに影響しますし、何より作業者が精神的に疲弊します。そのため、”出戻り”を最小にするために”依存関係”と”処理の纏まり”を意識して試験順番を考える必要があります。
先ほどのデータ集計処理を例にすると、1番のデータ抽出処理は、後続の2番、3番のデータ結合、集計の処理に依存します。この依存関係を無視して、最初に2番の試験から始めたらどうでしょうか？ データ結合や集計は大丈夫だったとしても、元のデータ抽出条件が間違っていれば依存関係にある後続の処理が正しいことは証明できません。そのため、もう一度、2番の試験からやり直しとなるケースが考えられます。依存関係がある場合は先の試験をクリアしてから、後続の試験を行う必要があります。
”処理の纏まり”を意識する事については、同じような試験を纏めることで作業者の手が慣れてくること、また、インプットとなる試験データを使いまわせるメリットがあります。なるべく同じ手順、試験データの試験は纏めておきましょう。
このように試験の”範囲”→”ポイント”→”順番”の順で試験項目を組み立てることで、試験は無駄なく効率的に行え、作業者の負担を減らすことができます。試験の”やり方”を変えて、”試験項目数”ではなく、”試験の質”を重視した試験に変えてみませんか？