05.先人に学ぶ（体系編）

世の中のテスターと呼ばれる職種、それもテストの企画や計画に関わる人達は何を考えテストを組み立てているんだろうか？不思議に思って本（雑誌）を読んだのですが、テストの全体像ってこうなってるのか、こうやってテストケースを抽出するんだ、なんて発見があって面白かったです。

読んだ本

ソフトウェア・テストPRESS（技術評論社）

テスト計画とは何ぞ？

とあるシステムの画面のテストを考える場合、入力の全パターンを列挙して片っ端から実行すれば完璧じゃん！って思いませんか？甘い甘い。チェックボックスが並んだ画面で全パターンを列挙すると 15 個（2^15）で 32,768 のパターン、30 個（2^30）で 1,073,741,824 のパターン、57 個（2^57）で地球が誕生してからの 46 億年の秒数と同じパターン数 に達します。つまり１秒間に１回の間隔でテストを実行した場合、46 億年かかるという事です。

さすがにそんなに大量のチェックボックスを並べた画面は作った事ありませんが、フロントエンドって小さなパーツの集合体で画面を構成しますよね。多機能な画面でそれぞれのパーツの入力パターンやステータスを全部列挙したら、相当な数になるはずです。何も考えずに全パターン列挙のテストを実行したら終わる頃には地球は滅亡しているかもしれません。

ではテストの専門家がどうやって 46 億年かけずにテストするかというと、目的を持ち、戦略（手段）・段取り（スケジュール）・成果物（資産としての報告）を定め計画を立てていくそうです。

目的の例

  • 設計で意図した通りの実装・動作であることを重要視する
  • 故障や欠陥の発見を重要視する
  • 特定の基準に照らして製品の品質を認定する

戦略の例

  • 単体・結合テストなど「機能テスト」を実施
  • 負荷テスト・ストレステストなど「非機能テスト」を実施し品質を上げる
  • バグの出やすい境界値など「エラー推測」を行い集中的にテストする
  • 因子・水準から最小の組み合わせを抽出する「直交表」を用いる
  • 条件と結果のマトリクスから組み合わせを抽出する「デシジョンテーブル」を用いる
  • テストから呼び出した処理経路の網羅率を「カバレッジ」で示しテストの十分性を検証する

段取りの例

  • 簡易な結合テストを実施、最もバグの多かったモジュールを集中的にテストする策を練る
  • テストしないものやテストの終了要件を定める事で、無駄な工数の発生を避ける

ここまで見ただけでも、全パターン列挙すれば？なんて浅はかな考えとは全然違いますね。46 億年かけて 100 %の完全性を求めるのではなく、現実的な日数で目的のパーセンテージを MAX まで引き上げる事がお仕事なんですね。

フロントエンドにも通じる部分

その１）単体テストとは何か

単体テスト（ユニットテスト）とは、テスト全体の中で最初のステップかつ最大のボリュームを占めるものだそうです。そしてこのテストに求められるものは「プログラマ自身で自分が作ったものが正しく動くと証明する事」です。どのくらいテストすればいいのかという点については、主観で進めるのではなく客観的に十分性をチェックする事がポイントで、具体的にはカバレッジの測定によってソースコードの網羅率を上げる事と、レビューによって仕様の網羅がきちんとなされているかチェックする事です。

ユニットテストの本来の範囲を超えてしまうとあれもこれもテストしたくなってしまいます。焦点を当てているサービスやコンポーネントの挙動に注目しましょう。

その２）品質についての考え方

本の中では、製品の無欠さを追求する「製品品質」と、開発期間やバグ残存数のバランスを取りつつ妥当性を追求する「サービス品質」という考え方が紹介されていました。電気ストーブという製品で例えるなら 製品品質とは、子どもに蹴られても壊れない耐久性・スイッチを連続カチカチしても誤作動しない正確性 を保証し サービス品質とは、スイッチONで電源が入りスイッチOFFで切れる事 の保証です。

システムに当てはめれば、お金や個人情報を取り扱うような場合は前者、業務効率化など利便性を高めるためのサービスは後者が当てはまるのではないでしょうか。私の関わるプロダクトは後者のほうです。とすると、テストに最低限求めるものは「正常パターンのテストが一通り揃っている事」です。

その３）パレートの法則

全体のうち 80% はそれを構成する要素の 20% が生み出している（パレートの法則）という言葉があります。この言葉は経済学のものですが、テストの世界でもバグのうち 80% は特定の 20% の部分が生み出しているとして、バグの多いモジュールや複雑度の高いコードベースを集中的にテストする事もあるそうです。

私が「データバインディングとコンポーネント連携にバグが多い」と日常の運用で感じたように、その部分がかなり高いパーセンテージを叩き出しているかもしれません。だとすると、そこを必ず確認する方法を考えれば効率的にバグが発見できそうです。