IVEC テスタークラス シラバス読解 Part1

はじめに

先日、IVECのテスタークラスの受験を申し込みました。
JSTQB FLは持っていますが、IVECはJSTQBより実務寄りの知識を問われるテストというのは受験者から聞いており、どんなテストかを体験してみたいという思いから、受験を決めた次第です。
試験まで大体1ヶ月なので、シラバスを中心に学習していきたいが、折角なのでシラバスの内容を読解し、内容を整理していく形とします。
以降、シラバスの内容を引用して進めていく
引用: https://www.ivia.or.jp/item43/item38

汎用テスト知識・スキル

テスト実行計画

テスト対象の知識の習得

学習の目的

マニュアル、機能仕様書、テスト仕様書、テスト計画書などからテスト対象の仕様や操作方法、テストの実行範囲を確認する。

テスト対象の情報を得るための情報には以下のようなものが挙げられる。

• 製品マニュアル
• 機能仕様書
• テスト仕様書
• 旧バージョンのテスト対象、プロトタイプなど動作可能な参考情報
• テスト計画書
  上記から得られる情報として、テスト対象の全体概要、機能、画面デザイン、画面遷移、操作手順などが挙げられる。テスト中に不明点が発生した場合など速やかに確認することができるよう、どのような情報がどこに記載されているかを把握する。

仕様を把握する上でのインプット一覧で、特にプロジェクト参画当初に一通り目を通す資料で、いずれも顧客から展開されるインプットの典型例だなという認識である。
また、上記とは別に市場で販売されている製品であれば、YouTubeで操作マニュアルの動画を展開している企業もあるので、情報収集の手段は多様になってきている。

旧バージョンが存在する場合、そのバージョンのテスト仕様書を入手し、テスト対象との差分を把握
する

旧バージョンで起きていた不具合、旧バージョンの仕様、テスト対象となる新バージョンで追加された機能を把握する。特に旧バージョンの開発ドキュメントからは実績のある既存仕様が確認できる。
新旧バージョンのテスト仕様の差分を理解し、重点評価を行うべき箇所を把握する。

過去のバージョンの仕様やテスト結果、検出した不具合、新バージョンで実装される機能一覧など、過去仕様及び新仕様との差分から得られる情報も重要な情報源である。
各種仕様書において、バージョン管理のルール化を厳密に行っている企業であれば、差分が容易に判断がつく。そういう体制が整っていない場合、案件のキックオフで既存仕様の変更箇所や新規機能の実装領域をヒアリングが必要になってくる。

競合製品が存在する場合は、仕様の調査・分析を実施する

競合製品とテスト対象の差分の機能など、予備情報を得ることができる。また競合製品の性能や使い勝手などテスト対象と比較することで、テスト対象の製品価値を高めるためのベンチマーク情報として活用することができる。

市場で販売されている競合製品は、自社製品の性能を相対的に比較できる情報となる。
実際に製品を触り、自社製品との機能差分や使い勝手の良さなどを自社製品へのフィードバックすることで、テスト対象の価値を高めることができる。
また、民間調査会社が提供するアンケートや品質検査結果なども貴重な情報源となる。
自動車業界だとIQSが有益なベンチマークであり、自動車メーカー各社もこの結果を基に他社と性能比較し、自社製品の改善に繋げていく流れができている。

テスト実行計画の立案

学習の目的

テストの目標を設定する

テスト実行範囲、テストの目的によってテストケースの優先度が変わる場合、またテストサイクルやフェーズでテストの目標が設定される。テストの目標により、テスト実行内容とゴールが明確になり、テスト実行担当者にテストの目標を理解してもらうことでチーム活動がまとまり易くなる。
主な内容は以下の通りである。

• テスト実行範囲
• 実行するテストケースの選択
• 選択したテストケースの優先順位付け
• 検出する不具合の目標件数
  テストケースの選択は、テスト計画書やテスト詳細設計書を参照し、作成済のテストケースから、テスト実行範囲に該当するテストケースを選択する。
  なお、テスト実行管理者は、テストの目的、テストサイクル、フェーズなどの要素を考慮してテストケースの優先順位付けを決定する。

テスト実行範囲・優先順位・不具合検出は割と典型的な目標設定の認識である。
特に探索的テストを実行する際は、何件実行したかより、何件不具合を出したかの方が人によってはやる気になるかもしれないし、多様な視点を持ってテストへ臨めるかもしれない。
2つ目の実行するテストケースの選択は、テストケース作成済みだが、開発の実装が追いついていない場合に実装している範囲を選択するみたいな考えの認識である。

テスト実行スケジュールを作成する

テストスケジュールの作成は、テストサイクル、フェーズ、テストタイプなどの目的を考慮して決定する。またテストの担当分担は、テスト終了期限などのマイルストーン、テスト実行に必要な作業項目と各作業項目に必要な工数、要員を考慮して決定する。実行中にスケジュール変更が頻繁に起こる
プロジェクトでは柔軟に対応できるスケジュールを作成することが必要である。

テスト計画者は開発全体スケジュールや顧客へのヒアリングを基に、テスト実行の日程感を検討する。
その上で、シラバスで定義している内容について考慮してスケジューリングしましょうということ。

テストの組織図を作成する

テストの組織図は、テストチームの体制だけでなく開発チームの体制やプロジェクトの責任者などのステークホルダーを明確にする。またテストに関する情報の連携、進捗の確認、各種問い合わせ先、ステークホルダーの役割と責任所在の明確化、緊急時の連絡先を明確にする目的がある。
テスト実行中は、日次の進捗報告や不明点の確認など、テストチーム以外とも連絡を取ることがある。
ステークホルダーの名前や連絡先（電話番号、メールアドレス、連絡手段となるコミュニケーションツールの担当者 ID など）を明記することで、速やかに対応することができる。

テストの組織図はテスト計画書に書いているのはよく見る。
開発側から見れば、テストの進捗担当や誰がテスト担当の窓口かは把握しておきたいはずなので、双方の連絡手段は記載必須である。
併せて、テスト範囲についてもテストチームが担保するテストレベルを明確にすることで、後からテスト担当領域の所在を巡るトラブルが起きないように、ステークホルダーへテストチームが開示すべき情報は開示しておくこと。

おわりに

シラバスの内容的に区切りの付け方が難しいので、以降の内容については随時投稿していきます。