バージョンは3.1.1.J03を参照しています。リンクはこちら
「テスト分析」と言うと、テストアーキテクチャー設計のあたりを思い浮かべる。
テストタイプや、テストレベルをまず最初に考えてみて、それらがきちんとハマるかスケジュールに充ててみる。
テストタイプの中には、例えば機能性を確認するテストだとすると、品質特性の中から何を強めに確認していけば良いのか、みたいなところへ掘り下げて、そこから必要となるテストケースのボリュームをざっくり見積もる、みたいなイメージ。
私のイメージが合っているかどうか、確認していきたい。
テストアナリストが取るべきタスクは、以下の通りとのこと。
JSTQB Advanced Level – テストアナリスト – 1.2 テスト分析
- テストベースを分析する。
- テストベースのさまざまな種類の欠陥を識別する。
- テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる。
- テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。
- リスクベースドテストに付随するタスクを実行する
今更だけど、テストベースってなんだろう。私のイメージではテスト対象物、テストスコープというイメージを持っているが、それイコールテストベースということになるだろうか。
試しに、Chat GPTに聞いてみたのがこちら。
テストベースとは、ソフトウェアテストのための基盤となる情報や資料のことを指します。テストベースは、ソフトウェアの要件仕様書、設計文書、ビジネスルール、ユーザーストーリーなど、テストを実施するための情報源です。テストベースはテスト計画やテストケースの作成に使用され、ソフトウェアが要求を満たしているかどうかを確認するための基準となります。
Chat GPT に聞いてみた：テストベースってなんですか
AIに頼っていないで、自分で調べてみよう。
以下、JSTQB Foundation Level シラバス（バージョン2018 J03)
テスト分析
テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析
する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定
する。
テスト分析の主な活動は以下の通りである。JSTQB Foundation Level 2018 J03 – テスト分析
- テストレベルごとに適切なテストベースを分析する。
o 要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。
o 設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフロー、モデル図（UML や ER 図など）、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。
o コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。
o リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。- テストベースとテストアイテムを評価して、以下のようなさまざまな種類の欠陥を識別する。
o 曖昧
o 欠落
o 不整合
o 不正確
o 矛盾
o 冗長なステートメント
私が持つイメージと少し違っていた。
私のイメージ：開発成果物
本当のテストベース：開発成果物、設計資料
あまり、言葉の定義でごにょごにょするのは好きではないので、いったん上記のイメージで読み進めてみたいと思う。
さて、テスト分析ということで、まず最初はテストベースを分析する、とのこと。
この「分析」という言葉にいったいどれほどの意味が含まれているのだろう。
テストベースなるものをインプットにして、テストアナリストは、いったい何を分析するのだろう。
私の目の前に、テストベースなるものがあったら、いったい何に使いたいと思うだろうか。
思いつくものを書いてみたい。
- 必要となるテストタイプを考える：テストタイプを考える際、私はベースとしてISO/IEC 25010で考えることが多い。それを元に、機能テスト/非機能テストで分けてみて、それぞれのテストを広げていく。テストタイプを元に、社内システムなのか、一般の人が使うのか、関連する社内システムの種類、それらのシステムを連携する場合に発生するトランザクションデータの種類、通信の種類、時間あたりのデータ量、セキュリティ要求レベルなどの関連情報をマインドマップで広げていく。それらの背景にあるのは、獲得したい品質目標があるはずで、そのためにどんな観点でテストをしていけば良いかを考える。その基になるのが、テストベースということになるのだろう。
- テスト実行の見積もりを考える：上記の品質目標を基に、テスト設計、テスト実行工数を考える。その際にベースとなるのが、設計資料だと思う。そこにはテストスコープが暗黙的に含まれているはずだから、それを見極め、時には優先度や機能の重要度などを考え、テストをどの程度まで時間をかけるべきか、かけられるか、などが思い当たる。
- テストに関するコミュニケーションルートを考える：ぱっと思いつくのが、テストを組み立てる際の問い合わせ先、テスト設計時の要件ヒアリング、テスト実行時の不具合報告フロー、進捗報告フローと頻度、テスト終了時の完了報告など。それぞれで使うフォーマットなどがあれば、それも検討する必要がありそう。
- テストに必要な調達を考える：テストに必要となる機材の獲得や、テスト環境構築、テストデータの作成、期待結果の取得に向けたプランニングなど。QAをされている方なら容易に想像できそうだが、テストの準備は予想以上に難解で、時間がかかることが多い。テスト実行の開始予定日になっても準備が終わらないということのないように、念入りに、慎重に準備計画を組み立てていく。この時、テスト実行をより具体的にイメージするために、設計ドキュメントを見る気がする。期待結果をどのように獲得すれば良いか考える必要があるから。
なんかものすごく脱線してしまったような気がする。私のイメージでバーっと書いてしまった。
シラバスに戻ろう。
テスト分析では、テストアナリストがこの範囲に対して、次のことを行う、とのこと。
- テストベースを分析する
- テストベースのさまざまな種類の欠陥を識別する
- テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる
- テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する
- リスクベースドテストに付随するタスクを実行する（詳細は第2章とのこと
テストベースを分析する、については大体のものを上述してしまった。
テストベースのさまざまな種類の欠陥を識別する、とはいったいどういうことだろうか。
さまざまな種類、とは。欠陥、とは。
私はウェブアプリのテストを長く経験しているので、例えば、Amazonのショッピングサイトをイメージしてみよう。
さまざまな種類には、どんなものが挙げられるだろうか。
たとえば商品検索で、意図したキーワード検索ができない、という欠陥を挙げてみる。
この場合、キーワード検索に関する、ロジックの問題なのか、検索クエリを投げる時の通信に関するものなのか、はたまたデータベースのなにかが問題になっているのか、など、どんな欠陥が潜在しているかを考える、ということなのかな、と。
もしくは、テストベースには設計で作られたドキュメントも含まれているということを考えてみると、ドキュメント上の記載ミスみたいなものもあるかもしれない。
ドキュメントはきちんと校正を通っているか、レビュー済みであるかを確認する必要がありそう。
次に行こう。
テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる、とは。
テスト条件とは、Amazonのショッピングサイトでは、ログインするIDとか、検索キーワードのことだろう。
フィーチャーは、「ログイン機能」や、「検索キーワード」ということかな。
だとすると、優先度を割り当てるというのは、私の理解では、例えばリリースされる機能群のうち、「ログイン機能」の品質を先に確認できないと、それ以降の機能、例えば購入履歴の確認や、購入フローなど、多くの機能が使えないことになってしまう。
なので、多くのテストブロックを作らないように、先にやってしまいたい時に優先度の設定をする場合がある。テストアナリストは、その「テスト実行の順番」をテスト分析の中で決めるのではないだろうか。
次へ行こう。
テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する、と。
Amazonのショッピングサイトをイメージして考えてみる。
ログイン機能で使われるログインIDを、有効・無効なものを含めて何パターンか用意する、ということだろうか。
ログインIDで使える文字とか、関連しそうな気がする。
ログインIDで使ったテスト条件を使い、そのまま購入フローへと遷移する場合など、その時に購入履歴を閲覧する時には、すでに購入しているものをいくつかDBに入れておかないといけないだろう。
その時に、どんな条件で入れておくか、みたいなものを一緒にまとめておく必要がありそう。
次へ、と思ったがリスクベースドテストに付随するタスクは第2章で語られるということなので、ここでは割愛しようと思う。だいぶ長くなってしまったし。