IVEC レベル5に合格した
合格しました。
※試験直後の感想記事
tunamagro58795.hateblo.jp
今までのレベルと同様、試験結果のレーダーチャートを見ながら
総評も参考にしつつ振り返ってみます。
赤枠が私です。青は合格者平均。
※2023/1/20現在、IVEC公式を見れば総評が載っています
私の弱点ワースト3は
・テスト要求を獲得する
・テスト要求を分析する
・テスト活動を分析する
です。
グラフの0度の方向が設問1で右回りに5問が知識問題、あとの3問が実務問題です。
各項目ふりかえり振り返り
2.テスト要求分析成果物を作成する
3.アーキテクチャスタイルの要求を分析する
4.テストアーキテクチャ設計成果物を検証する
5.前回の改善項目の達成率を評価する
知識問題のため設問1参照。
6.テスト要求を獲得する
実務問題の設問1のことと推測します。
実務問題は実施するテストについての状況・設定・環境・チーム構成etcが2，3ページに渡り記載されており、その状況から回答する、という感じです。
これを私が解けた自信はないです。グラフもいい感じに低いです。
テスコンの振り返りでも思ったのですが私はユーザの使用に基づく想定が甘いのではないかと。。
逆に構造に基づいたり過去不具合に基づく考えの方は考え付くのでこの結果なのではないかと思いました。
問題のことはもう忘れそうなので今のうちに書いておくと
既存システムへ別システムを組み合わせる的な問題で、比較的よくある状況なのではないかと思いました。
この場合、自分がまず考えることは
「組み合わせることによって今まで想定していなかった範囲へ動作が広がる時、作る側がそれを想定しているか」です。これは自身の経験から来ています。
あとは、想定される不具合がどれだけ不都合なのかが優先度に結び付くのですが
この想定が自分は甘いかもしれません。
データ破壊、使用が続行できないなどが想定される不具合なら、確認の優先度が高いと判断できます。
ですが、もう少し曖昧な「これが使えないとユーザ不便じゃないか？」の想定が多分私はまだまだです。
この辺りが優先度の考え方についての正答率を下げたと思います。
これについての対策は…まず自分がユーザ使用を考えることが不得手であることを念頭におくことです。
なので自分が「こう使うだろう」という推測をするときは抜けがある想定で自分だけで判断をしない、とかですかね。
自分で書いていてなんという甘い対策なのかと…
7.テスト全体の構造を設計する
実務問題の設問2と推測。
与えられた状況からどんなリグレッションテストをすればよいか？という内容だったかと思います。
毎回全部のテストを繰り返していられないとしたら、何をテストすればよいか？
それを考えるにはテスト全体の構造を理解していないといけません！（それっぽく言ってみます）
今考えると自分はまた非機能を忘れた気がします（また、というのはテスコンで丸ごと対象から外したため）
非機能自体が明確に作るものの目的に定められていないとき、非機能テストはリグレッションするのでしょうか？
こう書いているうちにそういえば非機能リグレッションしてた、と過去の仕事を思い出しました。とほほ
全体が見えなければテストを省くこと＝歯抜けテストになるのです。
8.テスト活動を分析する
実務問題の設問3かな・・
既に起きてしまった不具合があり、それを取り巻く状況を読んで、どうすればよかったかなーと
これからの対策を考えよう。みたいな内容でした。
IVECレベル3、4の不具合分析の文章がめちゃくちゃ長くなった版…と言いたいところですが
原因がテスト設計だけじゃなくチームそれぞれの活動に渡ってたので状況分析が必要です。
これも絶妙に実際にありがちな内容でした。それぞれ分担して仕事しているときどこが確認すればよかったのか、みたいな。。
・確認しなければいけないことは知っていたが、自チームが担当ではないと思っていた
・チームで定めた確認粒度では確認するべき内容ではないと思っていた
・誰も確認することに気づいていなかった
などなど、いろいろな原因が考えられますが、その原因をこれからどうやって取っ払っていくか
ということを考えるのが難しかったです。私はうまく日本語を書けた自信がないです。
大まかには「確認することに気づいていなかった」と「自チームが担当ではないと思っていた」に対する対策を書きました。
自分の総評：
今こうやって振り返ると、それなりに考えさせられる問題だったのかと思います。
試験が終わった後に私は「IVECに合格して何ができることが証明できるのか、合格しても何が証明できないのか分からない」と書きました。
今は少し明言できます。
この試験に合格して証明できる「何ができる」は、基本的用語の理解と、状況に対する言語化です。
基本的用語の理解について。
出題される用語はIVECの資料だけではなくJSTQBに範囲を広げていく必要があります。
（JSTQBだけでもだめで、両方の資料を複合で読んだ方が分かる）
おそらく用語の意味が分かっていないと解けない問題があるので、この試験に合格することは
テストタイプ（種類？）、探索的テスト、品質目標、品質特性などのゲシュタルト崩壊しがちな用語群を
ある程度分かっている証明になると思います。（そうしないと知識問題が全滅するので）
状況に対する言語化について。
私はIVECのこの要素を「文章読解なのではないか‥」と考えていました。
今にして思えばこれが状況を分析することと、それを言葉にすることなのだと思います。
レベル1はテスト実行そのものなので例外として、2～5はほとんどこの分析が必要でした。
ですので、この試験に合格することは、ある程度の状況分析とそれに対する対応を言葉にできる、ということの証明になると思います。
この試験に合格しても証明できない「何か」は、実際のテスト設計ができることです。
フォーマットや状況に沿ったテスト設計がIVECでは出題されます。
これもある程度できる証明になるといえばなりますが、実際のテスト設計とはもっと状況が複雑で
分析する対象も多いです。
なので、この試験に合格しても、それができる証明にはならないと思います。
試験の目的は達成したか？
シラバス・テキスト - 一般社団法人IT検証産業協会 一般社団法人IT検証産業協会ホームページ
上記IVECのサイトの「ハイレベル (V.2.0)」より引用
IEEE829-2008 で定義されているテストレベル*注の中からどれか一つを、Test.SSF のテスト工程であ
るテスト要求分析からテスト評価まで、すべてのテスト活動を掌握し統制します。担当するテストレベ
ルに含まれる各工程の管理、および完遂の責務を負います。テスト工程におけるテスト開発技術、テスト
管理技術を習熟し、状況に最善の活動を指示および実施することが求められます。
達成したというより入口に立ったくらいのスタンスではないでしょうか。
