タグ: JSTQB

バージョンは3.1.1.J03を参照しています。リンクはこちら

「テスト分析」と言うと、テストアーキテクチャー設計のあたりを思い浮かべる。
テストタイプや、テストレベルをまず最初に考えてみて、それらがきちんとハマるかスケジュールに充ててみる。
テストタイプの中には、例えば機能性を確認するテストだとすると、品質特性の中から何を強めに確認していけば良いのか、みたいなところへ掘り下げて、そこから必要となるテストケースのボリュームをざっくり見積もる、みたいなイメージ。
私のイメージが合っているかどうか、確認していきたい。

テストアナリストが取るべきタスクは、以下の通りとのこと。

• テストベースを分析する。
• テストベースのさまざまな種類の欠陥を識別する。
• テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる。
• テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。
• リスクベースドテストに付随するタスクを実行する

JSTQB Advanced Level – テストアナリスト – 1.2 テスト分析

今更だけど、テストベースってなんだろう。私のイメージではテスト対象物、テストスコープというイメージを持っているが、それイコールテストベースということになるだろうか。

試しに、Chat GPTに聞いてみたのがこちら。

テストベースとは、ソフトウェアテストのための基盤となる情報や資料のことを指します。テストベースは、ソフトウェアの要件仕様書、設計文書、ビジネスルール、ユーザーストーリーなど、テストを実施するための情報源です。テストベースはテスト計画やテストケースの作成に使用され、ソフトウェアが要求を満たしているかどうかを確認するための基準となります。

Chat GPT に聞いてみた：テストベースってなんですか

AIに頼っていないで、自分で調べてみよう。
以下、JSTQB Foundation Level シラバス（バージョン2018 J03)

テスト分析
テスト分析では、テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析
する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定
する。
テスト分析の主な活動は以下の通りである。

• テストレベルごとに適切なテストベースを分析する。
  o 要件仕様。ビジネス要件、機能要件、システム要件、ユーザーストーリー、エピック、ユースケースの他、コンポーネントやシステムに期待される機能および非機能の動作を指定する類似の作業成果物などがある。
  o 設計および実装情報。システムやソフトウェアに関するアーキテクチャー図もしくはドキュメント、設計仕様、コールフロー、モデル図（UML や ER 図など）、インターフェース仕様、コンポーネントもしくはシステムの構造を指定する類似の作業成果物などがある。
  o コンポーネントまたはシステム実装そのもの。コード、データベースのメタデータやクエリー、インターフェースなどがある。
  o リスク分析レポート。コンポーネントやシステムの機能、非機能、構造の各側面を考慮する。
• テストベースとテストアイテムを評価して、以下のようなさまざまな種類の欠陥を識別する。
  o 曖昧
  o 欠落
  o 不整合
  o 不正確
  o 矛盾
  o 冗長なステートメント

JSTQB Foundation Level 2018 J03 – テスト分析

私が持つイメージと少し違っていた。
私のイメージ：開発成果物
本当のテストベース：開発成果物、設計資料

あまり、言葉の定義でごにょごにょするのは好きではないので、いったん上記のイメージで読み進めてみたいと思う。

さて、テスト分析ということで、まず最初はテストベースを分析する、とのこと。
この「分析」という言葉にいったいどれほどの意味が含まれているのだろう。
テストベースなるものをインプットにして、テストアナリストは、いったい何を分析するのだろう。
私の目の前に、テストベースなるものがあったら、いったい何に使いたいと思うだろうか。
思いつくものを書いてみたい。

• 必要となるテストタイプを考える：テストタイプを考える際、私はベースとしてISO/IEC 25010で考えることが多い。それを元に、機能テスト/非機能テストで分けてみて、それぞれのテストを広げていく。テストタイプを元に、社内システムなのか、一般の人が使うのか、関連する社内システムの種類、それらのシステムを連携する場合に発生するトランザクションデータの種類、通信の種類、時間あたりのデータ量、セキュリティ要求レベルなどの関連情報をマインドマップで広げていく。それらの背景にあるのは、獲得したい品質目標があるはずで、そのためにどんな観点でテストをしていけば良いかを考える。その基になるのが、テストベースということになるのだろう。
• テスト実行の見積もりを考える：上記の品質目標を基に、テスト設計、テスト実行工数を考える。その際にベースとなるのが、設計資料だと思う。そこにはテストスコープが暗黙的に含まれているはずだから、それを見極め、時には優先度や機能の重要度などを考え、テストをどの程度まで時間をかけるべきか、かけられるか、などが思い当たる。
• テストに関するコミュニケーションルートを考える：ぱっと思いつくのが、テストを組み立てる際の問い合わせ先、テスト設計時の要件ヒアリング、テスト実行時の不具合報告フロー、進捗報告フローと頻度、テスト終了時の完了報告など。それぞれで使うフォーマットなどがあれば、それも検討する必要がありそう。
• テストに必要な調達を考える：テストに必要となる機材の獲得や、テスト環境構築、テストデータの作成、期待結果の取得に向けたプランニングなど。QAをされている方なら容易に想像できそうだが、テストの準備は予想以上に難解で、時間がかかることが多い。テスト実行の開始予定日になっても準備が終わらないということのないように、念入りに、慎重に準備計画を組み立てていく。この時、テスト実行をより具体的にイメージするために、設計ドキュメントを見る気がする。期待結果をどのように獲得すれば良いか考える必要があるから。

なんかものすごく脱線してしまったような気がする。私のイメージでバーっと書いてしまった。
シラバスに戻ろう。

テスト分析では、テストアナリストがこの範囲に対して、次のことを行う、とのこと。

• テストベースを分析する
• テストベースのさまざまな種類の欠陥を識別する
• テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる
• テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する
• リスクベースドテストに付随するタスクを実行する（詳細は第2章とのこと

テストベースを分析する、については大体のものを上述してしまった。
テストベースのさまざまな種類の欠陥を識別する、とはいったいどういうことだろうか。
さまざまな種類、とは。欠陥、とは。
私はウェブアプリのテストを長く経験しているので、例えば、Amazonのショッピングサイトをイメージしてみよう。
さまざまな種類には、どんなものが挙げられるだろうか。
たとえば商品検索で、意図したキーワード検索ができない、という欠陥を挙げてみる。
この場合、キーワード検索に関する、ロジックの問題なのか、検索クエリを投げる時の通信に関するものなのか、はたまたデータベースのなにかが問題になっているのか、など、どんな欠陥が潜在しているかを考える、ということなのかな、と。
もしくは、テストベースには設計で作られたドキュメントも含まれているということを考えてみると、ドキュメント上の記載ミスみたいなものもあるかもしれない。
ドキュメントはきちんと校正を通っているか、レビュー済みであるかを確認する必要がありそう。

次に行こう。

テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる、とは。
テスト条件とは、Amazonのショッピングサイトでは、ログインするIDとか、検索キーワードのことだろう。
フィーチャーは、「ログイン機能」や、「検索キーワード」ということかな。
だとすると、優先度を割り当てるというのは、私の理解では、例えばリリースされる機能群のうち、「ログイン機能」の品質を先に確認できないと、それ以降の機能、例えば購入履歴の確認や、購入フローなど、多くの機能が使えないことになってしまう。
なので、多くのテストブロックを作らないように、先にやってしまいたい時に優先度の設定をする場合がある。テストアナリストは、その「テスト実行の順番」をテスト分析の中で決めるのではないだろうか。

次へ行こう。
テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する、と。
Amazonのショッピングサイトをイメージして考えてみる。
ログイン機能で使われるログインIDを、有効・無効なものを含めて何パターンか用意する、ということだろうか。
ログインIDで使える文字とか、関連しそうな気がする。
ログインIDで使ったテスト条件を使い、そのまま購入フローへと遷移する場合など、その時に購入履歴を閲覧する時には、すでに購入しているものをいくつかDBに入れておかないといけないだろう。
その時に、どんな条件で入れておくか、みたいなものを一緒にまとめておく必要がありそう。

次へ、と思ったがリスクベースドテストに付随するタスクは第2章で語られるということなので、ここでは割愛しようと思う。だいぶ長くなってしまったし。

バージョンは3.1.1.J03を参照しています。リンクはこちら

早速第一章となる、テストプロセスにおけるテストアナリストのタスクを読み進めようと思っている。
読む前からぼんやりと、テストアナリストって言うけどさ、そもそも何をアナリシスすんのよ、と思ったりしていて、どうも寄り道だらけのブログになってしまいそうな展開である。

私の勤務先では、テスト計画書のようなものがあり、日々改訂をおこなっているものの、もっぱら以下のようにアジェンダを定めている。

• テストアプローチ
  • 品質目標
  • 自動化テストのポリシー
  • 基準となるシステムパフォーマンスのレベル
  • 過去の本番障害からの学び
  • リソース
  • スケジュール
  • 報告
• テストストラテジー
  • テスト網羅性のポリシー
  • 機能テストの定義
  • 非機能テストの定義
  • テスト準備
    • テストケース作成
    • 使用するツール
    • テストデータ準備

こうやって書いてみると、アプローチと戦略がごちゃ混ぜになっているような気がする。
まぁ、やりたいことをとりあえず載せた感じだから、ひとまずこのままで走っているけれど。
この、JSTQB Advanced Level テストアナリストのシラバスを読み込むことで、なんらか寄与できるものがあるといいなぁと思う。

テストプロセスのおさらい

シラバスには、以下太字になっている箇所に対し、テストアナリストが焦点を当てるべきだと述べている。なるほどね。ここが狙いなのね。

• テスト計画
• テストのモニタリング、およびコントロール
• テスト分析
• テスト設計
• テスト実装
• テスト実行
• テスト完了

ぱっと思いついたのは、テスト計画が含まれていないこと。
だけどそれはテストマネージャーの領域だから、含まれてないんだろうな。
そうやって役割を分掌してるんですね。

ソフトウェア開発ライフサイクルにおけるテスト

早速テスト戦略という言葉が出てきた。いいね。ちょうど知りたかったところ。

テストアナリストが関与するタイミングはSDLCごとに異なり、関与の程度、必要な時間、利用可能な情報、および期待も同様に異なる。

JSTQB Advanced Level テストアナリスト – 1.2 ソフトウェア開発ライフサイクルにおけるテスト

SDLCとは。Software Development Life Cycleのこと。
ウォーターフォールなのか、アジャイルなのか、はたまたハイブリッドなのか、みたいなものを理解している。
テストアナリストとして、SDLCの形は数多あるけれど、提供する先と、提供する内容は以下の通りとのこと。また引用させてもらう。

提供先	提供する情報
要求エンジニアリングおよびマネジメント	要件レビューのフィードバック
プロジェクトマネジメント	スケジュールに対する入力
構成管理および変更管理	ビルド検証テストの結果、バージョンコントロールの情報
ソフトウェア開発	検出された欠陥の通知
ソフトウェアメンテナンス	欠陥レポート、欠陥除去効率、確認テスト
テクニカルサポート	正確に文書化した回避策および既知の問題
テクニカルドキュメント作成（例えば、データベース設計仕様、テスト環境ドキュメント）	これらのドキュメントへの入力とドキュメントのテクニカルレビュー

JSTQB Advanced Level テストアナリスト – 1.2 ソフトウェア開発ライフサイクルにおけるテスト

残念ながら、私の頭には、それぞれの言葉が、すっと入ってこない。そのまま理解するには難しいので、私なりに解釈してみたい。

• 要求エンジニアリングおよびマネジメント：これは要件定義と考えた。要件定義の段階で、開発の要件をレビューし、その結果をフィードバックする。この際、フィードバックのレベルによって、要件の出来上がり具合いが見えてくる。例えば、「こんなこともちゃん書いてないのかよー」みたいな程度のフィードバックであれば、まだ全然煮詰まっていませんねー、みたいな。
  または、テスト条件のインプットになるような情報が足りてない場合、要件を定義したメンバーが対象システムに疎い、みたいなリスクも考えられる。そういう情報って属人的になりがちで、要件を定義するメンバーが持つ知識をきちんと周りに共有しておかないと、その人しかわからなくなってしまう、みたいなことになってしまうので注意が必要。なかなかできないのは分かる。うちもできてない。
• プロジェクトマネジメント：これはあれか、提供する情報が「スケジュールに対する入力」ってことだから、テスト準備、テスト実行それぞれの詳細なスケジュールに関する情報を渡すって私は理解した。テスト準備のほうは、テスト環境の準備や、ケース、データ、ツールなどが挙げられるので、その粒度で必要な工数？を分析し、渡す必要があるんだろうなぁ。
  一方、テスト実行についてもスケジュール？と思った。それはテストマネージャーがやる仕事では？と。もしくは、テストマネージャーが精緻なテスト実行スケジュールを作り上げるために、必要な情報を渡してあげる、ということかな。この理解でいくと、私の勤務先ではテストマネージャーがざっくりとしたテスト実行スケジュールを引いて（たまにトップダウンで開発側のPMから降りてくることもある）、それを、よりシステムに精通したメンバーが具体的な工数を計算したりしている。
• 構成管理および変更管理：ビルド検証テストの結果、バージョンコントロールの情報とは。
  おそらく、私の仕事先でいうと「ビルド検証テスト」はスモークテストって位置付けの仕事になる気がする。対象となる環境に、対象となるビルドがリリースされた時に行うテストのこと。環境にきちんとリリースされたか。その時にテストしたビルドのバージョンはどれ、とか。バージョンにより、ビルドに含まれた不具合の修正などが細かく管理されていたりするので、環境、ビルドのバージョン、スモークテストとしてテストした内容をきちんと報告するのは重要。だけどこれはテストアナリストがやる仕事なのか。うちではテストマネージャーがやる印象が強い。
• ソフトウェア開発：検出された欠陥の通知。これはつまりバグレポートということになるのだろう。当たり前すぎて、理解したものを説明する余地などなく。
• ソフトウェアメンテナンス：欠陥レポート、欠陥除去効率、確認テストとのこと。いっこ上の、欠陥の通知に使うレポートということだろうか。
  そもそもソフトウェアメンテナンスってどういうことだろう。うちの会社で言うところの、CI、Continous Improvement と称した小規模開発のことを想像した。1スプリントで開発できるような、ごく小さい改善が5個くらい集まった、一つのリリース。その中で発見されたバグレポートということだろうか。欠陥除去効率とは。英語ではなんて書いてあるんだろ。と思って調べたら「defect removal efficiency」とのこと。不具合を修正した効率、効率って何の割合だろうか。（修正した不具合数）/（発見された不具合数）ということか。
  さて、この欠陥除去効率は、この数値を見ることでどんなメリットがあるのだろうか。
  100％に近くなるほど、発見された不具合を修正しましたぜ、ということになる。
  私の勤務先の場合、発見→本当に不具合かどうか篩にかける→本当の不具合と認定→修正→確認、クローズという流れになっており、最初の、篩にかけた後の「本当の不具合」を分母にした場合、
  （なんか、議論が横道に逸れている気がするがこのまま続けてみる）
  100％に近くなるほど、発見された不具合を次期リリースに延ばすことなく、全て取り切りましたよ、ということになる。これは開発チームのキャパシティが、予想された不具合を修正するだけのものを確保していたということにつながるし、品質に対する意識が高い組織ということも言えるだろう。
  ここまで書いてちょっと気になったのは、機微な不具合に対しても修正しましたよ！が意識として正しいのかどうか。見逃す、と言うと語弊を生むけど、あまりにも機微すぎるものは工数がもったいないから直しません、という方針は、組織として健全とも言える気がする。
  そのあたりを鑑み、情報として、テストアナリストからプロジェクトチームに提供するということだったら、自然な気がする。
  確認テストは割愛。CIでやるべきテストスコープに基づいたテスト、みたいなイメージを持ったので。
• テクニカルドキュメント作成：私の勤務先では、テスト計画やテストケース、テストデータ集、テスト環境図みたいなテスト関連ドキュメントは作るけれど、シラバスにあるようなデータベース設計仕様みたいなものは開発チームが作るイメージを持っている。
  テスト結果を取得するためにSQLでデータをセレクトする場合、データベースのテーブル構成を分かりやすくドキュメント化しておきましたー、みたいな話は聞くしそれはテストドキュメントとして有効だろうけど、そうか、一般的にはデータベース設計仕様（ちなみに英語ではdatabase design specificationsだった）の作成もテストアナリストの仕事という括りなのか。勉強になった。

だいぶ多くの文字を書いてしまった。
JSTQBで検索して来られた方には読みづらい文章になっているかもしれない。たかがイチ現場の、イチ技術者の戯言に過ぎないので。

さて、シラバスを先に進めてみると、開発のSDLCに合わせたテストプロセスのことが記載されている。ここは具体的に描かれているため、違和感なく理解することができそう。JSTQB Foundation Levelを持っていれば、そちら側とも言葉が統一されているので、理解も早いだろう。

システムテスト環境の実装は、システム設計時に開始する場合があるものの、その大部分は、コーディングおよびコンポーネントテストと同時に開始するのが常であり、システムテストの実行開始数日前まではシステムテスト実装への取り組みが続いてしまうことが多い。

JSTQB Advanced level テストアナリスト 1.2 ソフトウェア開発ライフサイクルにおけるテスト

ここ、めっちゃ分かるわー、と頷きながら読んでしまった。
ほんとそうなんすよね。プロジェクト計画書と同時期にテスト計画書を作り、テスト環境に関する概要を描いたりするのだが、実際に手をつけるのはテスト開始日から逆に線を引き、○日前だからそろそろやるか、みたいなイメージを持っている。
他の現場でもそうなんだ、という安心感と共に、正論としてはちゃんとしたスケジュールに則って環境を準備しましょうよ、というのは忘れないようにしたい。

使用するSDLCに関係なく、テストアナリストは関与への期待度とタイミングを理解する必要がある。テストアナリストは、事前に定義されたロールモデルに固執することなく、特定のSDLCへの活動と関与のタイミングを調整することにより、ソフトウェア品質へ効果的に貢献する。

JSTQB Advanced level テストアナリスト 1.2 ソフトウェア開発ライフサイクルにおけるテスト

この、柔軟にやってってね、というのはJSTQB、ないしISTQBからのメッセージと受け取った。実際にも私の勤務先では、テストマネージャーがテストアナリストを兼ねると上述したが、期待される役割としてはテストケースのレビューから、テスト実行の見積もりまで、多種多様である。
そういうところにはテストのスペシャリティが求められるし、自分としても自社のプロジェクト文化と一般的なテストのナレッジを学び続けなければいけないと思っている。どちらか片方だけではなく。