テストの意図を自然言語で伝えるためのオレオレTestDesignDoc

この記事は、次の記事で紹介されている TestDesignDoc にインスパイヤーされて、
自分だったらどんな大項目を書くだろうかと、思いに耽る記事です。
note.com

オリジナルのTestDesignDocとは全く関係のない第三者による妄想記事ですので、批判やコメントはすべてわたくしにお願いします。

はじめに

他のテスト担当者や、開発チームのメンバーにレビューを依頼するときに、
テストの実装結果であるテストスイートをそのまま渡されるとレビュワーは困ります。

(例)レビュワーの頭の中
「このケースは、あの仕様を確認するために作られたのかな」
「このケースは、こんなバグを見つけたいのかな」
「考慮すべき条件や状態に漏れがないかな」

渡されたテストスイートを見て理解できれば良いのですが、テストが実行可能な状態まで落とし込まれた成果物に対してレビューをするのは大変です。
それらの情報をほどよく抽象化して表現する必要が出てきます。
それを表現するための一つの手法がTestDesignDocだと思います。

TestDesignDocの構成

引用するのも忍びないので、直接ご覧になってください。
TestDesignDoc：テスト分析・テスト設計に関する新たな試み｜Knowledge Work Developers blog

オレオレTestDesignDocの構成

テストの目的

なぜそのテストをしなければならないのか、そのテストをやらないとどんな影響を与えるのか、どんなバグを検出したいのかを書きます。

テストベース

素直にオリジナルのTestDesignDocと同じ大項目なので、説明不要ですが、要件、設計書、仕様書、画面仕様書、過去のテスト設計成果物、Question&Answerのやりとりの結果など、テストを作る上で参照するものを書きます。

アプローチ

必ずしも仕様ベースのテストとは限らず、探索的なアプローチを取るかもしれないので、どのような手段でテスト目的を実現するのかをざっくり書きます。手段には様々な視点が考えられそうですが、人が操作したり確認するのか、ツールに任せるのかについても考慮すべき内容かもしれません。

テスト条件・カバレッジ・テストオラクル・テストチャーター

混迷を生みそうな大項目です。 ChatGPTさんにとある仕様を考えてもらったので、この仕様をもとに書き方を考えてみます。

本システムでは、ユーザーがログインするための方法として以下の3つが提供されています。

- ID・パスワードによるログイン
- Microsoftアカウントを使ったログイン
- Googleアカウントを使ったログイン
また、ログインしたユーザーには以下の2種類の権限が設定されており、権限に応じて遷移先が変わります。

- 「管理者」の場合、「管理画面」に遷移する
- 「一般ユーザー」の場合、「利用者画面」に遷移する
さらに、「ログイン状態を保持する」オプションが提供されており、これを利用することでブラウザが閉じられても最大30日間ログイン状態が保持されます。

ログイン権限に応じた遷移先の出しわけの確認
- 条件
  - ログイン方法
- テストオラクル
  - XXX仕様書のリンク(内容によっては直接書いても良いかもしれないです)
各ログイン方法・オプション有無でのログイン保持期間を確認
- 条件
  - ログイン方法
  - 「ログイン状態を保持する」チェックボックス
- カバレッジ
  - 組み合わせ全網羅(想定しているテスト対象が良くないですね)
- テストオラクル
  - XXX仕様書のリンク