第119回：　テスト仕様書

≡ はじめに

「ASTERセミナー標準テキスト」の175ページについてです。

前回は、「構成管理」について書きました。今回は、「テスト仕様書」についてです。

「テスト仕様書」は前回の構成管理で出てきましたが、テスト活動の管理対象であるテストウェアの中心となる成果物です。テストウェアにはテスト仕様書の他にもテスト計画書やテストレポートや不具合報告書など、様々なものがあります。詳しくは、前回の真ん中あたりに引用した「テスト関連ドキュメント」のスライドを参照してください。

前回、「構成管理といっても目的によってやり方を加減しよう」という話を書きましたが、今回のテスト仕様書も考え方は全く同じです。テスト仕様書の用途によって何をどこまで書くべきかが決まります。加減の仕方について詳しく書くと長くなりますので、このnoteでは基礎的な話を書きます。
（わざわざ断らなくても、この連載は基礎的な話しか書いていませんね😅）

≡ テスト仕様書の構成

キャッチイメージをご覧いただくとわかるのですが、テスト仕様書（test specification）は、
　　「テスト設計仕様（test design specification）」
　　「テストケース仕様（test case specification）」
　　「テスト手順（test procedure specification）」
の３部構成となっています。

わざわざ英語名を併記したのは、ISO 標準(ISO/IEC/IEEE 29119-3)を参照するときの便宜のためです。ISO 標準ですが、一度は読まれることをお勧めします。（ISOの規格書は、自分で買うにも会社で買うとしても、購入のハードルが高いと思いますが、３、４、２、１、５の順番で買うと良いと思います。
SQuBOK Review 2020によると「ISO/IEC/IEEE 29119-2、-3、-4 の改定作業が始まりました。また、アジャイル 開発での 29119 規格の適用 ISO/IEC CD TR 29119-6、AI システムのテスト ISO/IEC CD TR 29119-11 の 2 件の TR(技術報告書)が開発中です。」とのことですので、改定後が購入のチャンスかな。
買うのがあれならIVIAの解説書を読むと良いかもしれません←私はIVIAさんの方は読んでいません。概要でしたら書籍もありますね（こちらもWebサイトに登録したら無料で読めるのかな。私は登録していないので未確認ですが書籍は買って読みました）。

話を戻します。

テスト仕様書の３部構成は、キャッチイメージに書いてある通り、それぞれ、テスト分析結果をまとめた「テスト設計仕様」と、テスト設計結果をまとめた「テストケース仕様」と、テスト実装結果をまとめた「テスト手順」という対応になります。

以下、それぞれについて、説明します。

■ テスト設計仕様

上述の通り、テスト分析結果をまとめたものが「テスト設計仕様」です。
したがって1番大事な項目は「テスト条件」（網羅すべき実態や属性）です。テスト条件とは簡単に言えば、（テスト分析によって識別した）「何をテストするか」です。テスト分析について詳しくは、以前のnote（前編、後編）を参照ください。ASTERのYouTubeチャンネルの「テスト分析の回」もお勧めです！

キャッチイメージの「テスト設計仕様」部分を拡大します。

テキストを拡大して、よく見ますと、「テスト条件」以外の項目も挙がっています。「詳細なテストアプローチ」はテスト計画書に書いたテストアプローチ（＝　テスト戦略をプロダクトに合わせて具体化したもの）を詳しく書いたものです。「高位レベルテストケース」はテスト技法適用後に見つかるものですから、私は書きませんが、「テスト条件」だけでテストしたいことのイメージが湧かないときには、具体化の意味で書いてみると良いでしょう。

いったい何を書いたら良いかわからなくなってしまった人がいるかもしれません。

「テスト分析」と言っても色々なやり方があります。どの方法が良い悪いということではありませんから、「テスト設計仕様」には、自分達のテスト分析結果をできるだけ思考過程を含めて追えるように記載していただき、テスト後の振り返りで改善していけばOKです。

私のHAYST法では、「テスト条件」の代わりに「6W2Hツリー」を書き、「詳細なテストアプローチ」の代わりに「FV表」を書いています。

ゆもつよメソッドには、ゆもつよメソッドのテストの分析方法がありますので、残すドキュメントも違います。

■ テストケース仕様

こちらは、大切なので、テキストの次のページ（176ページ）を引用します。

上の表については、「テストケース仕様」に記載すべき情報のリストと思ってください。

「テストカバレッジアイテム」については、聞きなれない方がいらっしゃるかもしれません。テストカバレッジアイテムには、見つけたテスト条件を「どこまで深く網羅するか」を書いてください。例えば、「状態遷移というテスト条件について、1スイッチという状態遷移パス網羅のモデルで100%テストする」という具合です。

現場では、次の「テスト手順」と合わせて表にすることも多いものです。
「テスト手順」は、ドキュメントではなくコード（テスト自動スクリプト）の場合もあります。その時には、テスト仕様書にテスト自動化のコードを記載（コピペ）するのではなく、自動スクリプトとは別にテストケース一覧表を作成し、自動スクリプトとのトレーサビリティを取るとレビューしやすいです。

また、原因結果グラフ、デシジョンテーブル、状態遷移グラフ、ラルフチャートとFL表、ユースケース図・表、、、等々、使用するテスト技法ごとにフォーマットを変えるのもありです。

わざわざこんなことを書いているのは、組織で決めた「テストケース一覧表」のフォーマットに縛られて、テスト技法のアウトプットの図や表を埋め込むのに四苦八苦されている現場をよく見るからです。（ゆもつよメソッドは表が大きくなっていく方式なので、このような問題は起こりにくいと思います）

「テストケース一覧表」のフォーマットに縛られないでください。自分でもっと良い方法を編み出しましょう。

要は、自分達のテスト設計結果をできるだけ思考過程を含めて追えるように記載することに知恵を絞ってください。
（テスト設計については、以前のnoteを参照ください。ASTERのYouTubeチャンネルの「テスト設計の回」もお勧めです！

■ テスト手順

こちらは、テストを実行する時に使うものです。上述した通り、私はテストケース一覧表と一緒にしています。

一緒にする理由は、一緒にしないとトレーサビリティを取るのが大変というネガティブな理由もあるのですが、それ以上にテストを実行する人に「テストケース仕様」に記載される「テスト目的」（今なにを確認したいのか）について*必ず*理解した上でテストの実行をしてほしいからです。たとえ、トレーサビリティが取れていたとしてもドキュメントが分冊になり、別の箇所を参照するとなりますと、それは面倒なものです。
面倒なことはしなくなりますので、テスト目的を気にせずに手順だけ機械のように実行する人になってしまいます。そうなってしまうと、テストの質がガクンと落ちます。

さて、テキストにはないのですが、テスト手順を書くときの注意点について補足します。こちらは、ASTERのセミナー資料の補足説明です。

特に「②曖昧表現」については、注意してください。

「テスト手順」はテストを実行する人が理解し、誤解が起こらないように書くのが基本です。もしもそのテスト手順書を何度も使いまわしそうで、実行者を特定できないのでしたら、細かく書く方が良いです。一方で、分かっていることまで何度も繰り返し、細かく書くと読み飛ばされますので、逆効果になります。
特に、実施事項よりも「そのテストの意図」と「何を（どこを）見るか」について、テストを実行する人に伝わるようにしっかり書いてください。
しつこいようですが、曖昧な書き方はだめです。「きちんと表示されること」、「問題が無いこと」、「すばやく」、「一桁の数字を入力」などの人によって解釈が異なる曖昧な記載はN Gです。確認箇所を明確にし、数値については具体的な値を書いてください。
それから他国の人がテストをする場合も気をつける必要があります。例えば、日本語で「3以上」は3を含みますが、中国語で「3以上」は3を含みません。

以前、高橋寿一さんから聞いた話として、

テスト分析では、形容詞⇒数値で表現する。
わからないことは「わからない」と書いておくこと。

とツイートしたことがあります。
たとえば、テスト条件（≒ テスト観点）を見つけるときに、

最初のうち：　検索結果は早く表示する（形容詞）
推敲するうちに：　検索結果は5秒以内に表示する（数値）
最終テスト条件：　検索結果は、データベースに20万件のデータが存在する状態で5秒以内に表示する（動作環境やシステムの状態といった条件も明記）

というように、「曖昧な表現を具体的なテストする値へ改めて確定する」いうことです。

ただし、ここで、「だったら最初からユーザーから具体的な要求値を引き出してよ」と考える人がいますが、それは間違いです。

確か、中小路 久美代 さん（今は、公立はこだて未来大学の教授かな）から聴いたように記憶しているのですが「要求はオノマトペで獲得するのが良い」とのことです。
これは、例えば、「ビュンとスクロールしてほしい」とユーザーが言ったら、まずはオノマトペである、「ビュン」をそのまま要求事項として受け取ることの大切さを言っています。

そして、この「ビュンとスクロールしてほしい」という要求を仕様化するときに、「慣性スクロール」を使うと決める方が望ましいのです。そして、仕様の検証テストをする時に“具体的なスクロールの行数や時間を決めて測定”し、要求の妥当性確認テストをする時に“「ビュンとスクロールしているか」を確認”すると良いのです。

ちょっと話が脇道（ディープ）に逸れましたね。😅

≡ 終わりに

今回は、「テスト仕様書」について書きました。

初めて書く人向けに標準的な方法について説明しましたが、普通はずっと使っていて受け継がれているテンプレートに合わせて作る場合が多いと思います。

組織に受け継がれているテンプレートを使って「テスト仕様」を書くことは良いことです。ただし、テスト後の振り返り（テストプロセスで言えば「テスト完了」）の時にテンプレートについても「使いやすく、また、抜け漏れなどの問題がなかったか」の観点でレビューを行い、次のテストに向けて改善してください。
一度の改善では満足のいくテンプレートにはならないかもしれませんが、何度も改善を加えることで使いやすく役に立つテンプレートになります。

さて、次回ですが、テキストの流れでは「リスクベースドテスト」となるのですが、そのテーマは「わたしは、リスクベースドテストが嫌いです」で書いていますので、ご興味のある方はそちらをお読みください。この連載の次回は「欠陥マネジメント」について書きます。次回で５章はおしまいです。