「マインドマップから始めるソフトウェアテストAdvent Calendar 2015」 の１０日目です。
今回はChapetr4「仕様分析 ～仕様を分析しよう」を取り上げます。以前の記事でも敢えて仕様分析という言葉を使っていると解説しました。テスト分析という言葉は初級者には誤解を招きやすいと感じているし，それは今でも余り変わっていないと感じています。このため本記事においても本書に合わせて仕様分析という言葉を使います。ただし，エキスパートの方はテスト分析と置き換えていただいてもよろしいかと思います。
※ご注意：本Advent Calendar はあくまで池田の個人企画です。
■仕様分析の方法は様々である
この仕様分析ですがテスト設計と並び，未だに定番として定まった方法はないのと思っています。本書執筆当時は仕様分析という考え方がまだまだ知られていませんでしたのでしょうがないところもありますが，現在に至ってもまだまだ研究分野であると感じています。ただし，国内では様々な手法が提案されており，実用化もされています。（次回の記事にて簡単にご紹介します）
本記事はガイドとなる例として2つ紹介しています。ひとつは要件定義書がある場合，そしてもう人は要件定義書がない場合です。分析は対象ドキュメントが存在することが前提ではあるのですが，そうでなかったり情報量が不足していたり欠損していたり，業態に於いては開示されなかったりします。そのため，様々なアプローチを取る必要があります。仕様分析が難しいことの一端はこういったことも影響しており，故に仕様分析のやりかた（手法／技法）は複数知っておくと良いと思います。
■MM本における仕様分析
すでにISTQBや他のテスト分析設計手法を学んでいる方にとっては本章は違和感を生じるところでしょう。本書では「実施するテストの種類を決める」とこまでを仕様分析としているからですね。それはテスト設計なのでは？と思う方もいるかと思いますが，本書に於いてはそのような整理になっていると理解をして下さい。本書での仕様分析は「インプットとなるドキュメントの情報を整理し，今後やるべき（特に検討すべき）テストの種類をテストカテゴリを意識しながら決めていく」と言い換えることができると思います（注：池田的にでは，です）。もう少し言うと「テスト設計を実施する上での方向性が十分に定まっていること」ということです。ですので，決してテスト設計をしている訳ではないことに注意して下さい。
■仕様分析は静的テストの性格も持つ
この仕様分析は文中では明示的に書いてはいませんが，静的テストの性格を持ち合わせています。
開発者が作成したドキュメントをテスト技術者の立場や目線で読み解きながら，テストの世界に必要な情報を変換していく作業でもあります。そのためテストの立場から見たときに設計や仕様の欠陥を発見することがあります。また，欠陥ではないが曖昧であるところも見つけます。情報の欠落に気がつくこともあります。それらは開発工程で実施されるデザインレビューで見つけるのが良いのですが，そのレビューは往々にして開発者が主導し開発のためのレビューになっています。つまりテストのためのレビューではありません。このため仕様分析でテストのためのレビューで見つけるべき欠陥を発見することがある訳です。その際は作成元に連絡し，ドキュメントを修正することで品質の作り込みに貢献する必要があります。また，ドキュメントの品質が向上することで，結果としてテストの品質も向上する訳ですから，仕様分析という作業の重要性をしっかり認識する必要があります。
■おわりに
本書における仕様分析についてポイントの紹介と多少の補足をしました。
仕様分析は「単に仕様書読んでチェックするだけ」と理解されがちですが，この仕様分析をしっかりやらないとあとに続くテスト設計や実装はガタガタになります。そこを強く認識する必要があります。