■応用情報
なぜか応用情報を申し込んでしまったので放置せずに何とかしようと思います。
毎回過去問を始めると思う全然わかってねーなー感・・ここをどう乗り越えたものか。
過去に買った本を読みまくったり、Tictokみたり様々な方法で無いやる気を奮い立たせようとして
一日が終わりました。
ねますやー
謎テスター、IVEC レベル5に合格したので弱点を振り返る
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 のテスト工程であ
るテスト要求分析からテスト評価まで、すべてのテスト活動を掌握し統制します。担当するテストレベ
ルに含まれる各工程の管理、および完遂の責務を負います。テスト工程におけるテスト開発技術、テスト
管理技術を習熟し、状況に最善の活動を指示および実施することが求められます。
達成したというより入口に立ったくらいのスタンスではないでしょうか。
2022年は振り替えるまでもない
アドカレを途中で放り出しておいてあれですが
今年のことを書き留めて置こうと思います。
今年はなにもしない1年でした。
応用情報は受けませんでした。
IVECは4と5を受けて4は合格、5が結果待ちです。
JCSQEは秋に中級を受けました。
セミナー的なものはJaSST東北を聞いただけかもしれません。
おぼろげながらクオリティフォワードの使い方？売りの何かも聞いた気もします。
あとはJSTQBの何か。
テスコンにも申し込みましたが、私はテスコンを活かせるほど成熟はしていなかったです。
仕事はとてもおだやかでした。
コロナは流行ったり流行らなかったりですが
行動制限はまるでない1年でした。
夏ごろがひどいことになっていて今（12月）もひどいことになってます。
恐らくこれからもこんな感じなのでしょう。
今年は何もないはずなのにどんどん心が追い詰められていく年でした。
今まで推進力にしていたかもしれない何かがゼロになりました。
私は本当に知識が必要だったのではなく
何かしてないと価値がないという怖さから何かをしていたのかもしれません。
アドカレを書いたのは向かい合うべきことに向かい合って今後に活かせれば、というのと、自分の問題点を明文化できればよいという考えからだったのですが
まず振り返るのも心の余裕が必要だったなあと今は痛感しています。
しばらくは自分に呪いをかけずにゆっくりしようと思います。
せめて「前向き」と言われることで辛くならなくなるくらいまで。
ダメなところを書き出すのは簡単だから何かできることを書こう
この記事は「大丈夫です。一人でアドベントカレンダーを書く精神はもっと深いところから来ました」7日目の記事です。
だんだんテスコンの皮を借りた私の対人恐怖症日記となりつつあるアドカレですが皆様お元気でしょうか。（？）
自分についてダメなところをあげるのは簡単なので（？）これはよくできたなという事でも書こうと思います。
ざっと思いつく範囲で
・申し込んだ
・辞退しなかった
…これだけですかね（えー－－
辞退しなかった訳も何日か前に書いた理由で台無しになっている気もしますが結局外に見える結果がすべてなのです。
成果物については内容はスカスカですが起承転結的なものは無理やり通したかな、、（無理やり？
多分、私の強みは、
・投げやりでも最初の一歩を踏み出せること（そのあと10000000000倍後悔する）
・惰性でギャーギャー言いながら続けることができること
・めちゃくちゃでも文にできること
この辺なのだと思います。
逆に弱いところは知識の応用、理路整然とさせること、作ったもののブラッシュアップなどだと思います。
なので対人恐怖症を克服すればあのやばい成果物をなんとかできたのではないでしょうか。なんて。。
要点：
始められることだけがよいところだった
人に相談しなさすぎにもほどがある
この記事は「大丈夫です。一人でアドベントカレンダーを書く精神はもっと深いところから来ました」6日目の記事です。
私は今回のテスコン参加にあたり、迷ったときに誰にも相談しませんでした。
まず、参加していることを周囲の誰かに言っていないです。
（ブログでコメントを頂いたことはとてもありがたかったです。励まされました；；）
そんなこんなでおかしいと思った箇所がどんどんおかしくなるという泥沼合戦にはまっていきました。
⓶なぜ誰にも相談しなかったのか
2日前に書いた「知られたくなかった」に繋がる内容です。
まあ誰にも言っていないというのが1番ですが、私がそこまで周りを巻き込めたかというと多分「いいえ」になってしまうかもです。
実生活においてはテスト設計コンテスト自体を知っている人がいないかもしれません。
広めろよ！との突っ込みが聞こえてきそうです。ただ、私が知らないだけで知っている人もいるのかもしれません（？？？）
テストにおける色々な何かって知名度のレイヤーがあって、JSTQBやIVECは（私も最初知りませんでしたが）割と名前が知られていて
その次にJaSSTくらい、それ以外になると相当知っている人が少なくなるイメージです。
じゃあ私が先陣を切って広めるくらいの気概で行けば、と寄せては返す細波のように自分を責めたりもします。
自分が相談する環境を作り出せなかった、ということかもしれません。
では実生活以外でネットでもだれかに相談すればよかったのでは？となるのですが
多分2年前くらいの自分だったら人に相談していた気がしないでもないです。
これは良くないことだと思うのですが、私は人と話さないと、どんどんコミュニケーションにかかる労力が高くなっていきます。
今年はもろにこのパターンでした。
ぼかして書きましたが、誰かに相談できるほど気持ちのハードルが下がりませんでした。。
⓶これは相談しなければいけなかったのではないかポイント
相談しなければいけなかったポイントを考えてみます。
・要求分析 is 何がよく分からなかった
他のチームと私の最大の違いは「要求分析の成果物ができていたか否か」なのではないかと思います。
私は要求の源泉を得るところを、プロダクト使用側ではなく、プロダクトを作るほう「だけ」を見てしまっていました。
それに対してかなり自分でも「？？？」と思っていたので、そこで苦しんでいるときに誰かに相談しなければいけなかったのでは？と思います。
・観点の出し方がやばかった
これは本当にやばすぎてなにも言えなくて～冬～状態でした。
あまり網羅的にならなかったというか、力不足すぎて本当に何も言えないというか・・
やばい状態をそのまま不時着させるというとんでもない終わり方をさせたのですが
やばい観点の走りができた時点で（スカスカになるにしても）どのような粒度にしたら人にわかりやすくなるのかを誰かに相談しなければいけなかったのではないかと思います。
そして相談していたら非機能全部捨てるのやめてみては？といわれたのでは・・
つまり手遅れになる前に段階的に第三者のチェックが必要だったのではないか、と思っています。
（自分がレビュアーとしての視点が未熟だから猶更）
要点：
・コミュ障が重症すぎて超えられなかった（でも必要なら超えていくべきだった）
・手遅れになる前に自分以外の視点を入れればよかった
私のテスト観点はちょっと異常（系に偏っている）
この記事は「大丈夫です。一人でアドベントカレンダーを書く精神はもっと深いところから来ました」5日目の記事です。
私は普段チェッカーをしていて、でたまにテストを作る・・というようなお仕事をしています。
そのような背景の特性上、ユーザの使用法に基づいたテストの仕方より、構造上でバグがでそうな所を探しに行きがちなところがあります。
テスコンに参加し、総評と懇親会を聞いて自分がその特性が相当強く、「使ってて困るよね」視点がかなり弱いことに気づけました。
私はバグが出たとしても、それがユーザにどのような不利益をもたらすかの想定が甘いです。
では何故そうなるのか？の原因を自分の思考の仕方から探っていこうと思います。
①テスト実行のときの思考の癖が出ている
テストを作るときに、テスト実行の思考である「この脇道に逸れた操作をするとどうなるのだろう？」というところをベースに思考を広げがちなところがあります。
例えば組み合わせを作るにしても、「この組み合わせはよくありがちだな」を作るよりは意外性を追い求めてしまうような傾向が強い。
テスト実行者としての成功体験で「その発想はなかった」というものがあります。（だいたいテストは作っている人の想定外をあたりにいくことが多いので…）
その成功体験に思考も影響されているのではないか、と思うのです。
⓶プロダクトの企画段階から参加しないことがが多いのでユーザの思考に没入できていない
普段のお仕事で自分が関わりだすのは大体プロダクトのコンセプトが決まって開発がコードを書き始めるくらいのときです（ほんとかな）
平たく言うと途中から入ることが多いので、途中からプロダクトの背景などを頭に叩き込んで何がだめでなにが良いかを考えながらテストしたりテストを作ったりします。
そのような感じなので、ユーザ視点？の考え方が少し付け焼刃なのかな、と思います。
ユーザの使い方を機能適合性くらいでしか考えられていないのかもしれません。
今回のテスコンのお題は自分の仕事で使いうる内容だったにも関わらず使い方の想定が甘かったので結構うへあーとなりました。
なんというか、ユーザのことを考える前に悪い意味で1枚膜ができている気がします。
確認する視点が作っている側に向いていて、作っている側をさらに飛び越した考え方ができていないというか。
かなり脱線しました。
要点：
思考の枠をとっぱらって使う人がプロダクトに何を求めているのかを考えられるようになりたい人生でした
辞退しなかった理由
この記事は「大丈夫です。一人でアドベントカレンダーを書く精神はもっと深いところから来ました」4日目の記事です。
私はかなり未完成に近い成果物を提出して終わったのですが
予選も決勝も辞退しなかった理由を書き残しておきます。
予選は多分運営の方のメールのおかげで辞退しなかったのだと思います。
あとは、テスコンの説明会動画の「とにかく出して」のところが脳内でリフレインしたので・・
決勝は「何かを始めた後にそれをやめるのが苦手だから」辞退しなかったのだと思います。
辞退しなくて良かったか？というと、前向きな自分を全面に出せば「良かった」です。
さらに前向きな話を続けていけば、未完成にしろめちゃくちゃにしろ、出してみてフィードバックを得られるということは出さないときより間違いなく経験を積んでいます。
ここまでは建前で、実際のところ、もう少しきちんと成果物を作れるようになってから出せればよかった。と思っています。
ひどい成果物で失望させたなあと何度考えたか分かりません。
たぶん、自分の中のどこかに「少しはできるだろう」という過信がありました。
その自分の過信と実際に全くできなかった落差、全くできない自分を客観的に知ること（と、それを公に知られること）が辛かったです。
でもその辛さにぶち当たることより辞退という波風を立てることのほうが辛かった自分は本当に意気地なしです。
ちなみに上記は予選～決勝までに思ったことで
予選まではまず通ると思っていなかったのと、それを前提にして作るのは失礼だから一応万が一に進むときのことを考えておこう、と思って続いたときを意識しながら未完成品を作っていました。
ここまで書いてきた通り、「失望されるから」「失礼だから」など、私は他人にどう思われるかに根深く縛られているのです。
■要点
波風を立てるのが怖すぎてそのまま突っ走っていた
