IVEC Level2 試験の傾向と対策を予想します 1

この記事の趣旨

2021/5/30 にIT検証技術者の認定資格であるIVEC(Level 2)を受けます。ところが、IVECに関する情報は殆ど世にないため、私のような初受験者は試験で何が出題されるのかを知ることができません。
ですので、IVECを一度も受験したことがない今のうちに、IVEC Level2の傾向と対策を予想して記載しようと思います。
この記事はIVEC受験前に書いており、事実に一切基づかないデタラメであることにご留意ください。

IVEC Level 2の傾向予想

まずシラバスからの引用です。Level 2では下記の内容が求められています。

エントリーレベル レベル2
テスト実行の工程全体を通して、テスト実行とテスト実行の管理ができる技術者を目標としています。 これらには、レベル1の「スキル」「知識」に加え、「テスト実行の管理(「リソース」「工程」「目標」「要 員」「リスク」「テスト実行の品質」)などと、実務に必要なコミュニケーションの能力やソフトウェアテ ストの用語理解も含みます。

これらは一言で「空気を読む力」といえるでしょう。言わずもがなテスト実行管理者には必須の能力となります。
近年の出題傾向を踏まえ、試験内容は以下のようになるかと考えられます。
・テスト実行スケジュー ルの策定
・テスト環境準備
・テスト実行担当者の管理
・不具合の管理
・テスト実行報告書の作成
・プロジェクトリストの抽出
・探索的テストの管理
・テスト実行の振り返り
本稿では上記の項目について「テスト実行スケジュー ルの策定」「テスト環境準備」「テスト実行担当者の管理」にスポットを当て、シラバスを独自解釈し、解説していきます。

テスト実行スケジュールの策定

関連のある項目:テストの目標を設定する,テスト実行スケジュールを作成する,テスト実行の要員計画を作成する,テスト実行の見積り(試算)を実施する

まずテスト実行管理者はテスト実行計画を策定します。実行計画は２つのフェーズに分けて考えると整理しやすいと思います。

テスト目標の設定
テストの目的やテストサイクルやテストフェーズなどの情報を元にテスト実行エリア※1、実行するテストケース、優先順位、予想される不具合件数を設定します。
実際の試験では単純な条件のみ提示され、簡単な問題となると予想しています。
例えば、不具合修正の影響範囲をテストするリグレッションテスト計画を立てるような問題です。
修正された不具合リストを元にリグレッションテストのテストケースのスコープを設定し、ブロック要因となる機能に対して優先順位をつけます。
ブロック要因となる機能の識別には、機能名から重要さを予測するような行間力の高さを普段から発揮しているかが求められます。
※1 意味不明

テスト実行計画の策定
上記で設定された目標を元に、タスク、工数、マイルストーン、アサインするメンバーを決定し具体化していきます。
下記のような要素を考慮に入れながら、ガントチャートに割り付けていきます。
・テスト環境の準備、テスト実行、不具合報告といったタスク識別
・識別したタスク毎のメンバーの生産性
・サブシステム毎のマイルストーン
・タスクやテストの依存関係

実際の試験ではガントチャートを書きます。
タスク毎に得意なメンバ、不得意なメンバがいるので、単純に生産性で掛け算をして最もテスト実行期間が最短となる組み合わせを選ぶと不正解になります。

ここで求められることは、サブシステム毎に受け渡し日やテスト目標日が違うこと、テスト環境が作成されないとテスト実行ができないといったタスクの依存関係、生産性が最も高い派遣テスターの契約が5月いっぱいで切れてしまうこと、といった制約に気づくことです。
机上の空論で導き出せる最短の実行計画である必要はなく、「テスト実行計画を立てる上での制約条件にどれだけ気がつけるか」が勝負の分かれ目になります。
これらの制約条件には、コンテキストスイッチ、不具合数、テストケースの品質などは考慮されません。テスト実行管理者として正しく空気を読めば関係がないことに気がつくはずです。

テスト環境準備

関連のある項目:テスト実行計画に基づき作業用環境の準備をする,テスト実行計画に基づきテスト環境の準備をする,テスト実行計画に基づきテスト対象の準備をする,テスト環境の設置や設定をする(必要に応じてテスト環境を熟知している)技術者のアサインを実施する,テスト実行に必要なリソースの動作実績の確認をする

IVECにおけるテスト環境とはテスト実行環境以外にも働くオフィスの環境やコミュニケーションルール、用語集などが含まれるようです。
理由は謎です。

イマイチ問題の予想がつかないですが、2020年度試験の総評を見てみると、オフィス環境とテスト環境の違いを把握しているかどうかが大事だったとのことでした。
実際の試験では、テスト環境構築の専門知識を持つ技術者にどのようなタスクをアサインメントするかといった点が問われる気がします。テストツール、テストインフラの調達、構築などです。自動化ツールのライセンス数計算や予算見積りも問われるかもしれません。
ポイントはテストケースや各資料を保存するサーバ構築やメールアカウントの取得にこれらの技術者をアサインしないことです。

歯切れ悪くてほんとに申し訳ないですがこんな感じです。情報があれば教えて下さい。

行間を読めば以下のような内容も試験内容として現れる可能性があります。
・テストレベル間のテストの受け渡しを行う
・テスト環境の受け入れ条件の策定
・不具合報告の内容からテスト環境を保守する期間の見積り
・テスト環境のリスク分析
などが考えられます。

テスト実行担当者の管理

関連のある項目:常にテスト実行のスピードを意識して、テスト実行の進捗状況を把握する,テストリソース(機材、要員)の管理,日次の状況を入力し、進捗状況を報告す,スケジュール管理:テスト実行のスケジュールの管理点を理解する,要員管理:要員のスキル・作業状況の管理点を理解する

the 実行管理者という感じがしますね。テスト実行者共に威張り倒してやりましょう。
この問題には2パターンあります。
1.OpenOfficeの予実管理表を見ながら、テスト実行を再アサインメントする
2.OpenOfficeの予実管理表と日報を見ながら、テスト実行結果におけるリスクを指摘したり、対策を立案する

OpenOfficeの予実管理表を見ながら、テスト実行を再アサインメントする
1ヶ月あるテスト実行期間のうち、2週間が終了して進捗に遅れはありませんが、テスト担当者によって予実に差がある状態からスタートします。ベリファイテストや個人の生産性を考慮しながらアサインメントし直すことが求められます。
以下のルールを守るといい感じの回答になると予想されます
1.ベリファイテストは本人が実施。どんな場合でもテストが実行可能になった時点で最優先で実施する
2.テスト担当者の実績を元に再度生産性を見積もる
3.テスト対象のサブシステム重要度に起因する優先度のみならず、テスト環境の制約を考慮して優先度を組み替える
4.残業

OpenOfficeの予実管理表と日報を見ながら、テスト実行結果におけるリスクを指摘したり、対策を立案する
何人かのテスト実行担当者の日報を眺めながら、典型的なテスト実行結果におけるリスクを指摘してあげます。以下に例を示します。
1.検出した不具合の数が少なすぎる=>偽陰性リスク※1
2.Q&Aが多すぎて遅れてる=>スキルやドキュメントの調達が足りない ※2
3.不具合が多すぎて遅れてる=>不具合が重複してたり、ブロックとなる不具合を識別できていない ※3
4.テスト環境が渋滞を起こしてテストが進まない=>テスト環境の制約を考慮してテスト実行のスケジュールを調整するよう要請する※4
5.開発者の単体テストのお手伝いしている=>テスト実行管理者を通すように開発者にお願いする※5

※1,2 テストケースの品質については考慮しません
※3 テスト対象の品質については考慮しません
※4 テスト実行担当者がうまいことやるべき問題です
※5 開発者がテスト実行管理者のお客様だった場合、その限りではありません

今日のところはここまでとしたいです。元気があれば残りの項目についても予想していきたいと思います。