はじめて学ぶソフトウェアのテスト技法を読んだ

2020/12/28

はじめて学ぶソフトウェアのテスト技法を読んだのでメモしておきます。

どんな本❓

タイトル通りソフトウェアテストの技法について重点的に書かれた本です。ソフトウェアはすべてを入出力の組み合わせに対してテストをすることが不可能であることはよく知られています。だからこそ、さまざまな技法を駆使し限られたリソースの中でソフトウェアに潜むリスクを洗い出すことが重要になります。

本書は、ブラックボックステストとホワイトボックステスト、同値テストや境界値テストなどの基本的な事柄から、直交表を使うようなちょっとしたテクニックまでが例題付きで紹介されています。また、スクリプトテストと探索的テストの比較等もされておりわかりやすいです。

技法が役立つのはテストだけじゃない🙋

本書ではデシジョンテーブルや状態遷移図などさまざまな技法が紹介されてます。これらはもちろんソフトウェアテストにおいて大変役立つものだけど、たとえばソフトウェア設計時にも役立つものばかりだなということ感じました（というよりももともと要件定義や設計の技法か…）。

理想としては（とくにテスト専任の人がいる現場では）、これらの資料はすべてソフトウェアの設計段階でそろえておくのがもちろんもっとも効率的なのでしょうね…ともかく、当たり前ではありますけどテストは要件定義や設計に強く影響を受けることを改めて認識しました。

スクリプトテスト📖

本書ではテストの進め方としてスクリプトテストと探索的テストの2つの方法があるとしています。

スクリプトテストは要件を順番通りに検証する考え方にもとづいています。つまり、テストを設計し、テストケースを文書化し、テストケースを実行するという流れです。

探索的テストでは順番通りのやり方の代わりに、製品について学習し、テストを設計し、テストを実行するという作業を 同時並行 で進めます。

テストを行う現場の多くは基本的にスクリプトテストを採用しているのではと思います（少なくとも名目上は）。自分もテスト設計をしたことあるのですが、こういった文章（テスト設計に限らずですが…）を作るのってあんまり好きではないんですよね。現場に依るとは思いますが、「承認」のハードルが高いあまりに結局更新されず意味のない文章になっていたりすることあります。

じゃあスクリプトテストを辞めるのかというと良い部分はたくさんあるわけで、そうではなくて、更新がより容易になるような仕組みがあると良いですよね。本書でも次のように引用されています。

肝心なのは、可能な限り最善の計画を作ることではなく、可能な限り最善の結果を得ることである。同様に、個々の計画書は動かせない文書ではなく、進化し続ける文書と見なすべきである。計画のプロセスと同様、計画書も自由に動かせなければならない。動かせない計画書は、流動的状況下の適応型組織にとって、何の価値も持たない。

じゃ具体的にどうするのと言われると困るけど（本書にもそこまで突っ込んだ内容はない）…。そういった意味では管理職の方にもぜひ読んでいただきたい本ですね（丸投げ）！！！

いつテストをやめるか🙆

これもソフトウェアテストの命題ですよね。

本書でもカバレッジや欠陥検出率などいくつかの指標となるものが取り上げられています。ただ、最終的にどうするかはプロジェクト次第なのかなと。本書ではテスト担当者としては結局のところ次が大切だと書いています。

テスト担当者としての私たちの役目は、製品を出荷するリスクについて経営陣に情報を与えることだという点です。組織内のマーケティングや販売部門は、製品を出荷する利点について、経営陣に情報を与える役目を果たす必要があります。

ただし、こういった説明ってすごく難しいと個人的には思うんですよね。管理職側からしたら「リスクがない」という言葉が一番欲しいだろうわけで………。そういった意味では管理職の方にもぜひ読んでいただきたい本ですね（丸投げ）！！！

さいごに

この本1つだけ問題があって誤植と思しき箇所がかなりあるんですよね。幸いにもまとめられている方がいらっしゃたので参考になると思います。

「テスト」と銘打っている本ではありますがソフトウェア開発に携わるすべてのひとにオススメできると思います。

たまおさ

釣りとか登山とか好きです。(@tamaki_osamu)