投稿者: hmgrbean

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