見出し画像

JSTQBFLの申込倍率が高すぎるし、あまつさえ申し込み後も受けられないとかシビアすぎるこの氷の世界でIVECはその代わり足り得るのかの考察（12/15未明時点）→JSTQBのプレスリリースにより氷の世界が溶けそう

しーちき

※JSTQBによるCBT試験に対応するよのリリース発表前に記載した記事です。

この記事は「書きたかった一人アドベントカレンダー、リキッドルームに」15日目の記事です。

JSTQB FLに申し込もうと思ったら申し込み開始日なのに申し込み終わっていた、とか、申し込み済んだのに受けられなかったなどの話をよく聞きます。
前者も辛いですが後者はかなり心が折れるのではないかと思います。

この記事ではそんな心折れた時にIVECはJSTQBの代わりになるのか？を考えてみようと思います。

私は会社側や採用側の視点を持ち合わせてはいないので「就職や査定に役に立つか」の観点では語れません。
いちテストオペレーターとして何の根拠もなく想像で書きますので、冬の夜長のお茶請け程度に読み流してください。

JSTQB FLを勉強すると何がうれしいのか？

端的に言って「テストに関連する知識がある程度体系的に学べる」だと思います。
裏返すと、FLを取得するということはその「体系的な知識を最低限学んだよー」ということになるのでしょう。

IVECを勉強するとJSTQB FLと同じように体系的に学べる？

上手く言えないのですがある意味YESである意味NOです。いくらかNO寄りです。
IVECは知識試験ではなく実務試験なので、プロセスやドキュメントや技法、レビューなど、JSTQB FLの出題範囲にあるような知識を幅広く体系的に学べるわけでは無いです。（ただしIVECにはIVECのシラバスがあり、その中では各プロセスごとにある程度、詳細な説明があります。若干立場が偏っているのが気になりますが一例としては誤差です）

IVECのレベル1は実行、レベル2は実行管理、レベル3～4は設計、とプロセスが区切られています。
なので、「テストプロセス全体を理解したい」より「各プロセスの具体例がどのような感じか」を理解するのに向いているかもしれません。

私はついこの間までレベル3（テスト設計の入り口）の勉強をしていたのですが、JSTQBと用語の定義が異なっているので「場所場所によって言葉の使い方が違う」といった考えを念頭に置かないと混乱すると思いました。

JSTQB FLを学んで何がしたいのかによってIVECが代わりになるかが違うような気がする

『知識を体系的に学びたい』だと完全な代わりにはならない気がします。
ただ、テストプロセスの具体例を学びたい！との目的でIVECを勉強するのはありだとは思います。
その際は「この言葉の定義が世の中では変わることもあるよ！」を念頭に置いておくといいです（とくにJSTQBを学ぶ前）
IVECのテスト設計の説明は用語が独特であること以外は比較的分かりやすいと思います。

JSTQB、IVEC、そして実際の仕事。
どれにおいても「テストプロセスはどのような流れになっているの？」は学んでおいて損はないので、テストプロセスを理解しよう大会の足掛かりとして『IVECってどんな感じなのだろう』を学んでみるのもよいのではないでしょうか。

まとめ

どのみちテストプロセスは勉強したほうがいい

・・・

妄想コラム：なんでテストプロセスを学ぶことに損はないか？
もともとテストを作る工程は暗黙知の集合みたいな状態になってしまっていて、プロセスを分けて系統立てて考えるということができていない、そのプロセスのふにゃふにゃさからやばいテストが爆誕し、ヤバいテストを経たやばいプロダクトが誕生してしまう日もありました（、、？
（プロダクト品質はプロセス品質に依存する。すくぼっくのどこかに確か図があったと思います（適当ですみません））
プロセスを体系立てて考えると（プロダクトと見立てた）テストの品質があがり、品質があがったやばくないテストでテストする→やばい不具合を出さないプロダクトができる、なので、プロセスをなんとかするのはプロダクトの品質に繋がるのです。
なのでテストプロセスを学び、テスト作る工程を段階的に分けて考えられるといいかと。

プロセスを分けて考えるとは？
・プロセスが分かれていない例：
テスト作るぞー（＾o＾）→テスト実装

・プロセスが分かれている例：
こんな風にテストするぞー（計画）→計画をもとに分析するぞー→分析をもとに設計（略）→設計をもっと具体化するぞー（実装）

テストプロセス分けて考えるとなんでテストの品質あがるの？
いきなりどーんと詳細に作ると、大きなところを細かい網で考えることになり、考慮抜けが発生しやすい。
大きな目的や機能から順々に細かくしていくと、その都度都度で考え漏れてないかな？と確認できるので、いきなりどーんよりは抜けが少なくなる。

また、細かく作ったところで謎の不具合に気づき、細かく作ったところを全部直すと直し漏れが出たりすることもあるし何よりも大変。
大きく考えた範囲で謎の不具合に気づけば、その大きく考えた範囲内で直せばいいので、細かく作ったところを全部直すよりは手間が少ない。漏れも少ない。うれしい。たのしい。

※ここまで個人の妄想です。

2021/12/15 22:00追記
この謎記事を書いた日、午後にJSTQBから以下のプレスリリースが発表されました。

本当に良かった！いつになるかはさておき、会場足りないよ問題や受けるタイミング合わないよ問題が緩和されるなら本当にいいことだと思います。
JSTQBさんがんばってください。