ぜにのQAブログ

どこかの企業でQAエンジニアとして働いてる人のブログです

MBTIにちょっと救われた話

QAやテストとあまり関係ないですが、今年の中で知ってよかったこととしてMBTIについて書いていきたいと思います。

 

専門的な知識について間違ったことを書かないでほしいと思う方もいらっしゃると思いますが、この記事については完全な個人的感想になっておりますのでご容赦ください。

 

もくじ

 

MBTIとは？

MBTIとはユングのタイプ論をもとにした、世界45カ国以上で活用されている
国際規格に基づいた性格検査です。

【公式】MBTIとは より引用

 

一般的には下記の性格診断テストに答えた結果のことを指すことが多いと思います。

www.16personalities.com

 

どういった項目についての結果が出るかというと、下記の4項目についてです。

  • 「外向的（E）」か「内向的（I）」
  • 「感覚型（S）」か「直感型（N）」
  • 「論理型（T）」か「感情型（F）」
  • 「知覚型（P）」か「判断型（J）」

16Personalitiesについては、これらの項目においてそれぞれどれに当てはまるのかを判定されているものと認識しています。

 

自分のMBTIとそれを知ったことによって起きたこと

自分も↑の性格診断に回答した結果、「INFP-T（仲介者）」でした！

 

www.16personalities.com

 

INFPの特徴としてよく見るのは、「自己愛が強い」「理想主義者」「繊細」で、我ながら少し扱いにくい人だなと思います。

ちなみに「INFP」で検索するとサジェストの上位に「クズ」「やばい」が表示されます...ショック

MBTIを知ったことによって起こったこと

端的にいうと、他の特性を持つ人の言動が以前と比べて気にならなくなりました。

逆にこれまでは、他人が発している言葉の内容に加えて表情や声色などから「本当はどう思っているのか」を読もうとして、自分の中だけで結論づけて落ち込むことまでありました。

また、ストレートなものの伝えられ方をすると、攻撃されている...？と捉えることもありました。

 

そうしたことを気にしてしまうのは物心ついた時からの癖だから直せないと思っていたのですが、

MBTIについて調べていく中で、自分と同じ感覚の人もいるし、全く違う考え方の人も同じくらいいること、また、他人のストレートな言い方や行動は決して攻撃的な意味ではないということがわかり、他人の言動などが気にならなくなりました。

自分と違う考え方の人もいることはもちろんわかっていたのですが、ここでは各パーソナリティの特性に目を通したことによって「実感した」「納得した」が近いですね。

 

その他調べたこと

性格って先天性？後天性？

学生時代から今日にかけて、何度か16Personalitiesは受けたことがありました。

一番最初に診断した時は「ISFJ（擁護者）」、その次は「ISFP（冒険者）」、そして最新は「INFP（仲介者）」と結果が変わっていきました。

なんだか少しずつ性格が変化して行っているように見えるのですが、性格って後天的に変わっていくものなのでしょうか？

 

調べたところによると、先天的な性格（気質/キャラクター）が核としてあり、外側に環境など後天的な物事によって変動する人格（パーソナリティ）があるそうです。

参考：

【図解】パーソナリティとキャラクターの違いを心理学的に解説 | パーソナルステップ

 

「16Personalities 」とあるように、上で受けた診断は人格について診断しているので、受けるタイミングによって結果も変動するのだと捉えました。

 

心理機能診断

もう一つ、16Personalitiesとは別にMBTIを詳しく知るための「心理機能診断」というものもあるそうです。

 

参考：

【MBTI】「心理機能診断」の読み方を徹底解説！！ ｜ 夜無のブログ | 夜無のブログ

MBTI理論に登場する「心理機能（認知機能）」を個別に診断するものです。

以下4種類の心理機能の得意不得意を数値化してくれます。

・感情（F）「Feeling」
・思考（T）「Thinking」
・五感（S）「Sensation」
・直感（N）「iNtuition」

 

さらに、この「F、T、S、N」の4種類の心理機能は

・内向的な機能（i）
・外向的な機能（e）

の二種類に細かく分けられるので、
「Fi、Fe、Ti、Te、Si、Se、Ni、Ne」の計8種類があるということになります。

 

心理機能診断に則ると、自分のMBTI（16personalitiesで出た結果）の「INFP」は下記の特性になるようです。

①主機能：Fi（自分の心を見つめる力）

②補助機能：Ne（斬新なアイデアを思いつく力）

③第三機能：Si（出来事を記憶し、思い出す力）

④劣勢機能：Te（物事を達成する力）

 

通常は①主機能、②補助機能が働いていて、①→②→③→④の順に成長していくそうです。

④、一刻も早く成長したいなあ。

 

心理機能についてここで一言にまとめることはできないのですが、16personalities とはまた違う見方で面白いなと感じました。

参考にした記事にとっても詳しく解説が載っているのでご興味のある方はぜひご覧になってみてください。

 

まとめ

ここまで調べたことや感想など、つぎはぎ繋いで書いてきましたが、ネットで簡易的に診断できる結果については参考程度にとどめておいた方が良く、本当の自分のMBTIが知りたい場合は専門機関で診断を受けるのが確実だそうです。（それはそう）

自分と他人の特性について理解したいですが、この人はこんな言動しているからこのタイプだ、と推し測ろうとすると偏見につながってしまうので自分を理解するツールとしてとどめたいと思いました。

また、自分にはこの特性があるから〇〇できない/しなくても良い、みたいな免罪符のような考え方はしないように心がけたいと思いつつ、ここまで辛いとギブアップした方がいい、など基準を持っておきたいなと思いました。

 

全然関係ない余談

最近、自分が運動不足すぎることに気づき、マシンピラティスに通い始めました。

めっちゃ筋肉痛になるけど楽しいので続けられそうです🧘

JaSST’23 Review ミニ参加レポート

12/1（金）に開催されたJaaSST'23 Reviewに参加したので、感想などをまとめました。

参加後すぐに書こうと思ったのですがなぜか月末になっていました...

 

もくじ

 

参加経緯

  • 去年の講演内容が勉強になり、実務に活かしたいと感じたため
  • 招待公演の内容にも興味があったため

 

レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー

こちらのJaSST'23 Reviewのレビューページの講演1について資料公開されています。

JaSSTソフトウェアテストシンポジウム-JaSST Review'23-レポート

 

【感想】

レビュープロセスの概要については前回（JaSST'22 Review）で拝見しており、今回はその続きのようでした。

ちなみに去年も参加してレポートも書いたので載せておきます。

JaSST'22 Review 参加レポート: https://dev.icare.jpn.com/dev_cat/qae_zeni1031/

 

今回は、下記の2つの項目について新しく話されていたと思います。

  • テストのシフトレフトのようにレビューもシフトレフトの考え方を活かせるかもしれない
  • レビューアーキテクチャについて

 

レビューのシフトレフトについて

成果物が完成してからレビューすると、質問や成果物の欠陥が多く報告されてしまうことが問題点として挙げられていました。

上のような手戻りが発生する状態を改善するために、より上流からレビューまたは一緒に成果物を作成する（モブ）を実施することによって手戻りなどを防ぐことができるのではないか、という内容だったと認識しています。

 

要件定義や受け入れ条件が作成されているミーティングに、レビューアを入れてもらうだけでも効果が出そうだと感じました。

 

詳しくは「レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー」講演資料_p35

 

レビューアーキテクチャについて

下記の工程でレビューを開発工程において繰り返し実施していくことと認識しました。

①観点の洗い出し

②同類事項集約

③構造化（②で分類した項目の内容をまとめた項目名をつける）

=>振り返り

 

レビュー実施時のとっかかりとその後の進め方について明確になってきていると思うので、実務に取り入れやすいと感じました。

 

詳しくは「レビュー体系化の経過報告：レビュー体系とレビューアーキテクチャー」講演資料_p53~

 

この講演ではレビュー体系化の今後についても話されていて、

今後レビューマニフェストなど確定していくとのことなので楽しみです！

 

TEAM TRANSFORMATION TACTICS FOR HOLISTIC TESTING AND QUALITY _チーム一丸となったテストと品質のためのチーム変革戦術

こちらのJaSST'23 Reviewのレビューページの講演2について資料公開されています。

JaSSTソフトウェアテストシンポジウム-JaSST Review'23-レポート

 

 

【感想】

Lisiさんの講演で特に印象に残ったことは、「チームの文化が品質にとって一番重要」とおっしゃっていたところでした。

確かに、レビューやテストのシフトレフトなどをチームで進めるためには、チームの文化が醸成されていた方が良い、前提条件のようなものなのかなと感じました。

 

チーム文化の醸成を実現するために、Lisiさんはよくチームメンバーを観察して気がついたことをメモしているそうで、

チームメンバーに興味を持って観察することによって一人一人の特性を理解してチームワークを良くすると考えているそうです。

自分の偏見や憶測などでチームメンバーを判断せず、傾聴を心がける姿勢は自分も見習わなければいけないと感じました。

 

〇〇パスはハッピーパスだけではないらしい_「ソフトウェアテストをカイゼンする50のアイデア」の感想文①

ブログ更新するぞ

こんにちは、ぜにです。

なんだか最近学習へのモチベーションが高いので、

自身のブログを毎月1本を目標に更新していくことにしました。

3ヶ月坊主にならないようにスモールステップで頑張ります 🎉

 

書いていくこととしては、こんな感じを想定してます。

  • 本のつまみ読み感想文
  • 参加したイベントの感想
  • 資格受験について

 

今回は、「ソフトウェアテストをカイゼンする50のアイデア」の

「Chapter1 テストのアイデアを生み出す_ 感情を利用しよう」について感想を書いていこうと思います。

※電子書籍を購入しているため、引用に記載されているページ数が実際とずれているかもしれません

 

感情を利用しよう

テスターが日常的に指摘するように、新しいソフトウェアのフィーチャーが持つリスクを適切にカバーするために必要なテストの種類に関しては、ハッピーパスは氷山の一角にすぎません。

私たちが提案するヒューリスティックは、10の感情または行動の種類に基づいています。それは、「恐れ」「幸せ」「怒り」「非行」「恥ずかしさ」「寂しさ」「物忘れ」「優柔不断」「貪欲」「ストレス」の10個です。

引用：ソフトウェアテストをカイゼンする50のアイデア (p.29-30)

 

こちらの章では上記の通り、ハッピーパスも含め10種類のテストが紹介されています。

その中でいくつか気になったものをピックアップしました。

 

スカリーパス（恐怖）：

ステークホルダーにとって最もリスクの高い領域

機能や変更について、各ステークホルダーを最も怖がらせるもの

引用：ソフトウェアテストをカイゼンする50のアイデア (p.31)

 

こちらは、テスト分析時に優先的に考え、用心してテストする箇所だと解釈しました。

実務では「リスク」と表現されるもので、テスト設計する際やチームの品質の指標を考える時にも役立つのではないかと考えました。

 

アングリーパス（怒り）：

アングリーパスでは、アプリケーションの反応が悪くなったり、エラーが発生したり、うまく再生できず腹を立てたりするようなテストを探します。

引用：ソフトウェアテストをカイゼンする50のアイデア (p.31)

 

こちらはアプリケーションへの負荷で反応が悪くなったり、またはエラーハンドリングなどが網羅されていないなどユーザー体験が悪くなることについての観点だと解釈しました。

アングリーパスがある程度考慮されていないと、短期的にも長期的にもプロダクトへの評価へつながりそうだなと感じました。

 

エンブレシングパス（恥ずかしさ）：

それらがビジネスの損失のような即時の大惨事ではない場合でも、それらは内部または外部の信頼性に重大な影響を与える可能性

引用：ソフトウェアテストをカイゼンする50のアイデア (p.31-32)

 

こちらはスカリーパスほどの影響力はないものの、もしバグっていたら恥ずかしい、あちゃ〜なパスと解釈しました。

誤字脱字だけでなく、表示崩れ、仕様漏れなども時にはエンブレシングパスに入るのかな？と考えました。

 

読んだ感想

こういった不具合があるとユーザーさん怒るまたはがっかりするだろうな、など無意識にテスト観点を出す時に考えていたことが言語化されたような感覚でした。

また、誰にとっての感情なのかが気になりました。

「恐れ」はステークホルダ全員にとってな気がするし、「怒り」はユーザーが、な気がする。

「恥ずかしさ」は作り手がその気持ちになってるな〜など、一視点からの感情ではないということに気づきました。

 

もし10種の感情の観点を実務に取り入れるとしたら、

恐れ、怒り、幸せ、非行、恥ずかしさについては、テスト設計時や回帰テストを考えるときに多く用いる場面がありそうだなと感じました。

また、寂しさ、物忘れ、優柔不断、貪欲については探索的テストに多く用いる場面がありそうだと感じました。

ストレスについては、アプリケーションの性能を継続的に測る時に用いることができる観点だと感じました。

 

実務でも活かせるよう、頭の片隅に置いておこう。

 

全然関係ない余談

最近家の近くにすんごいおいしいパン屋さんがあることに気づいて、最高な気分になりました🍞

 

2年間の振り返り【後編】

ぜにです。

前編に引き続き、2年間を振り返って気になったこと、課題に感じたことを書いていきます！

 

▼前編をご覧になっていない方はこちら！

qaminarai.hatenablog.com

 

もくじ

  1. こんな振り返りしたよ
  2. 気になったこと、課題に感じたこと
  3. まとめ
  4. 余談

 

1. こんな振り返りをしたよ

※前編と同じ内容です

 

【前置き】

入社時点での開発組織はこんな感じでした

  • 開発組織全体の人数は約30名ほど
  • QAチームなど品質管理を専門としたチームはまだない

企業規模拡大の時期だったので、開発組織としても品質を専門としたチームが必要といった方針でQAエンジニアの採用が進み、ご縁あって自分がQAチームの第一号の社員として採用されました。

※自分のこれまでの経歴についてはこちらの記事をご覧ください。

 

【ここから本題です！】

ざざっと時系列で起きたことや良かったこと、気になったことなどをまとめてみました。

※なるべく企業にまつわる固有名詞は伏せています。

入社1年目のタイムライン

入社2年目以降のタイムライン

タイムラインという振り返り方法を実施しており、こちらの記事を参考にさせていただきました！

細かくて見えないところもあると思うので雰囲気を掴んでいただければ。

 

 

2. 気になったこと、課題に感じたこと

気になったこと、課題に感じたことを上のタイムラインから抜粋し、

それによって困ったことや、こうしたら良かったと思ったことをまとめました。

 

テスト自動化を早期に目指しすぎたかもしれない

【困ったこと】
  • 自動化すると効果的なテストが不明確で、テストを作成してもそれが有効であると言えない状態
  • 定期メンテナンスを行うことが難しい状態
 
【なぜ起きたか】
  • 自動化すると効果的なテストが不明確で、テストを作成してもそれが有効であると言えない状態
    • ツール選定を最初に行った
      • 社内全体のテスト（開発側行われているものも含む）を把握していない状態だった
      • QAで行う回帰テストが本当にこの内容で良いか精査していない状態だった
    •  自動化ツールの選定タイミングが早かった
      • メンバーが自分1人しかいなかったのになんでもやろうとしすぎた
      • とりあえずやってみなきゃわからない精神（自動化に関する興味はあったが知識がなかった）
  • 定期メンテナンスを行うことが難しい状態
    • 作成済みの自動テストに変更を加える必要がある場合、担当者が都度修正していたが、QAチームとして定期的に一定の基準を持ってメンテナンスをするというルールはなかった
      • 現在は回帰テスト/自動テストの内容精査のmtgを定期開催しておりメンテナンスへの動きが前進しているが、始めるタイミングが（自分の退社タイミングにとって）遅かった 
      • 機能リリースに対するテストで現状のチーム人数で手いっぱいのため、リソース不足な部分があった

 

【こうすれば良かった】

とりあえず1人しかいないのに色々やろうとしない...！

一旦やってみるの前に、目的や方針くらいは有識者に一度相談しておくべきだった。

やってみなければわからない部分もあるが、ある程度社内のテストの現状と自動テストにするべき項目をまとめておくべきだった。
 
ソフトウェアテスト293の鉄則にある「自動化は"銀の弾丸"にはならない」を身をもって体感しました。
※ソフトウェアテスト293の鉄則_鉄則105 より引用
 
 
 
QAEチームの立ち位置や開発工程のどこから関わるかが曖昧だった

【困ったこと】

  • QAチームも開発側も両者にどう関われば良いか探り探りで、開発者やチームメンバーを困惑させてしまった
  • QAチームのミッションを決めたが、チーム/開発部内でも浸透していない気がした
 
【なぜ起きたか】
  • QAチームも開発側も両者にどう関われば良いか探り探りで、メンバーを困惑させてしまうこともあった
    • QAチームで限られたリソースの中でどういった条件でどのようにプロジェクトに関わるか定義づけられていなかった
      • 各プロジェクトのリリーススケジュールを優先していた
        • リリーススケジュールを見てQAのリソースを見積もり、それをもとにQAがプロジェクトにどう関わるかを決めていた
    • 各プロジェクトのPjMとの接触タイミングが少なく、連携がとれていなかった
      • QAチームから主導していく形ではなく、あくまでプロジェクトから必要とされたときに受動的に動いていた
  • QAチームのミッションを決めたが、チーム/開発部内でも浸透していない気がした
    • こまめな周知がされていなかった
 
【こうすれば良かった】
QAチームで品質の定義、プロジェクトの関わり方を決め、毎月毎週でも周知したり時にはアップデートしていくと良かった。
開発者からはQAチームは未知の存在だったと思うので、QAチームから積極的に歩み寄る、参加した方が良いと感じたmtgには呼ばれていなくてもいくべきだった。

 

プログラミングスクールを途中で退会した

これについては、意志が弱かったに尽きる。
業務時間内に勉強しても良い、と言われていてもQAの業務が優先と感じて意図的に勉強時間を潰してしまっていた。
QAの業務を言い訳にしているが、就業時間外にいくらでもできただろうと言われるとそうだなと思う...。
この有給消化期間中に目的や目標を再設定したい。

 

勉強会/イベントなどから吸収する情報で、概念の理解は割とすぐにできるが具体への落とし込みに弱い
【困ったこと】
  • 見聞きした内容を業務に取り入れようと思った時にスムーズに実践できない
 
【なぜ起きたか】
 
自分の業務で実践する具体的な像が見えていない
  • 話の聞き方に課題がある
    • 話を聞いた時に、即座に「〇〇の場合」「もし〇〇だったら」などバリエーションが思い浮かばない
      • 話の中に複数パターンがある項目を見つけようとしてない
    • 話の中で引っかかるところがあっても一旦全部聞こうとすると引っかかったところを忘れる
    • 概念を理解するのが得意というか、見聞きした情報をもとになんとか辻褄を合わせようとする癖がある
      • 辻褄を合わせるので、ん？と思ったことを自動的にスルーするようになり、解消した方が良い疑問を解消しない

 

【こうすれば良かった】

  • 話や情報の中から、せめて自分の環境に置き換えるとどうなるか考えて引っかかったところを書き留めてみる。
  • 見聞きした情報をそのままメモして満足するのではなく、情報に対してどう思ったか、その情報に複数パターンや例外は存在しないか振り返ってみる
  • イベントなどで事前にテーマがわかる場合は、そのテーマにおける自分の状況を振り返っておき、聞きたいことを明確にしておく

 

3. まとめ

良かったことをまとめた前編と比べてどんよりとした記事になってしまいました... 🙏

根暗なのがもろ出てしまってるし、終始抽象的な話しかしていないのですが、自分の気持ちの整理として書いている記事なのでご容赦ください！

 

4. 余談

家だと集中できないのでシェアラウンジとかで記事を書いたのですが、良かったところ載せておきます🍹

 

▼ 飲み物とお菓子が充実してて席間隔ゆったりしてて最高でした！周りの本棚の本も読み放題 📚

store.tsite.jp

 

▼おしゃれ空間なので自分もおしゃれになった気分になれますが、パスワードの打ち込みに苦戦してしまいおしゃれな人たちにダサい姿を見せてしまいました！

www.te-fu.jp

2年間の振り返り【前編】

ぜにです。

このたび、2021年6月から2年勤めたiCAREを退職しました！

今まで会社の開発ブログでアウトプットしてきたので久々に自分のブログを書きます〜。

 

辞めた理由とか組織についてとかは全く書くつもりはなく、

「QAチーム立ち上げ」や「自分とチームの成長」という視点で振り返った内容を書いていきます！

 

もくじ

  1. こんな振り返りしたよ
  2. 良かったこと
  3. まとめ

 

1. こんな振り返りしたよ

【前置き】

入社時点での開発組織はこんな感じでした

  • 開発組織全体の人数は約30名ほど
  • QAチームなど品質管理を専門としたチームはまだない

企業規模拡大の時期だったので、開発組織としても品質を専門としたチームが必要といった方針でQAエンジニアの採用が進み、ご縁あって自分がQAチームの第一号の社員として採用されました。

※自分のこれまでの経歴についてはこちらの記事をご覧ください。

 

【ここから本題です！】

ざざっと時系列で起きたことや良かったこと、気になったことなどをまとめてみました。

※なるべく企業にまつわる固有名詞は伏せています。

入社1年目のタイムライン

入社2年目以降のタイムライン

タイムラインという振り返り方法を実施しており、こちらの記事を参考にさせていただきました！

細かくて見えないところもあると思うので雰囲気を掴んでいただければ。

 

2. 良かったこと

上のタイムラインから、良かったことを抜粋しました。

 

2021年10月　他社とのQAチーム交流会

交流会にて現状のQAチームについて意見をもらえたことによって正しい方向性を向けたと思う

▼ 詳しくはこちらの記事に書きました！

 atama plus × iCARE QAチーム交流会を開催しました！ | 働くひとと組織の健康を創る iCARE

 

2022年1月　QAについての勉強会開始

輪読会やテスト設計技法の勉強を実施し、QAEチーム全体のスキル底上げに寄与できたと思う

勉強会の内容としてはこんな感じでした

QAチームだけでなく興味のある開発メンバーとも一緒に取り組みコミュニケーションが取れたことも良かったし、自分たちの現状を把握するためにも有効だったと思います。

 

2022年5月　初の社外イベントでの登壇

人前に出るのが元々苦手で緊張でおかしくなりそうだったが、社外へのアウトプットができてよかった

▼ 登壇資料はこちら

QA経験2年で1人目QAになって感じた 課題と改善策 - Speaker Deck

 

2022年6月　WACATE2022夏に参加

社外のQAの方とワークができて、刺激をうけた

いい焦り、危機感を覚えてその後の活動の原動力になった

▼ 詳しくはこちらの記事に書きました！

テストエンジニアのためのワークショップ「WACATE 2022夏」の参加レポート | 働くひとと組織の健康を創る iCARE

 

2022年8月　broccoliさんがフェロー（技術顧問）としてジョイン
自分自身やQAEチームだけでなく、開発組織全体にとっても大きな影響を受けた

QA界隈で知らない人はいないのではないかと思っているbroccoliさんが技術顧問としてジョインされ、週に一度QAについての相談会を開催してくださっています。

相談会では、テストについてのお悩み/つまづいたところの相談や、テスト活動におけるアドバイスをたくさんいただきました。

broccoliさんがいてくださったおかげで、不安なところも相談すれば解決できるという安心感で精神的にも軽くなり、いろいろなことに挑戦できたと思います。

感謝でしかない...！

 

2022年9月　バグ分析活動開始

四半期のバグ分析結果を社内に展開することによって、組織内全体のシフトレフトへの意識づけができた

開発工程のどこでバグが混入したのかを、社内でストックしているシステム障害の情報一つ一つに対してヒアリングなどを重ね分析し、集計しました。

その結果、実装前の段階でバグが混入しているケースが過半数を占めていました。

それを開発部内に展開した結果、QAチームがより上流から関わる動きが推進されました。

 

2022年11月　テストプロセスの導入

仕様分析など上流に時間を割くことによって、考慮漏れやバグの作り込みに対して効果的に対処できる体制になった

▼ 詳しくはこちらの記事に書きました！

テストプロセスに沿ってテスト活動をしてみた | 働くひとと組織の健康を創る iCARE

 

2022年12月　QAチームのリーダーになった

マネジメント業務を経験できた

自分はこれまでの人生の中で、人を束ねることを全くしたことがなかったのですが、ここでリーダーという役割になりました。

各プロジェクトにおけるテストスケジュールの管理やテスト実行時の取りまとめなどはこれまでも経験はあったのですが、メンバーの評価や1on1など、良い経験ではあったけどプレイヤーとして頑張る精神とは全く別物（あたりまえ）でなかなか苦戦しました。

会社の意向やそれぞれのメンバーの気持ち/キャリアに向き合うことができてたか、リーダーとしての振る舞いが正しかったかというとそうではない気がしていて、そこは課題だなと感じています。

 

3. まとめ

今回は良かったことを振り返りました。

全体的に情報を追い続け活動を絶やさずにいれたことが良かったと思います。

ただ、それは開発部やその他部署の方々が協力的だったからできたことだと思っています。

本当に感謝でしかないです！

（前職だけでなく今までも各職場で本当に人に恵まれてきたな〜としみじみ）

 

後編は気になったこと、課題に感じたことを書きます！

 

IVEC エントリーレベル２を受けてきました！

資格試験

IVECとは？

IT検証技術者認定試験 - 一般社団法人IT検証産業協会 一般社団法人IT検証産業協会ホームページ

IT検証技術者認定試験(IVEC)は、一般社団法人IT検証産業協会(IVIA)が認定するテストエンジニアの資格試験です。

  

雑な性格なので手っ取り早く次のレベルを受験できるようになりたいと

いきなりレベル２を受けました。

 

場所

情報オアシス神田

入り口が細い路地でわかりにくいですがGoogle先生のおかげでたどり着けました。

 

持ち物

  • 受験票
  • シャーペン or えんぴつ（受験番号書くだけ） 

 

試験内容

2021春期は全部で6問でした。（※↓うろ覚えの内容です！）

  1. テスト環境準備
  2. 探索的テスト
  3. 質問表の回答
  4. 不具合報告？管理？
  5. テストスケジュールの策定
  6. テスト実行後の振り返り 

  

 所感

 一応全部埋めれたけど３時間あっという間でした。

ほぼ記述式なので、どの問題でも 内容はわかるんだけど言語化できない！

ということが結構ありました。

内容もわからん！ということも結構ありました。

過去問サンプルぽいものがあんまりなかった印象です。

知識テストは 2018年でなくなったってホームページに書いてあったけど、

知識テストのテキストの内容は試験にちょくちょく出てきました。（あたりまえ）

 

久しぶりに Windows を触ったので

キーボードとにらめっこする瞬間が度々あったのと、

問題ごとに別ファイルになっているので、ファイルの行き来が大変でした。

勉強しながらとか試験受けながら、

みなさんこんなに事細かく管理されてるんだ…ほげ〜...と思いました。

受かってるといいけど...自信はないです！

 

勉強方法

  • 知識テストのテキストの要点をノートに書く
  • シラバスと前回の総評を音読する
  • 過去問のサンプル２回くらいやる
  • 過去受験した方のブログとか note をいっぱい見る

書いたり音読したりしないと頭に入らない民

 

参考にさせていただいたブログ・note

IVEC レベル1 受験(2020秋) - 私は迷いの中にいる

IVEC Level1 受験してきました｜ごまずん｜note

IVEC Level2 試験の傾向と対策を予想します 1｜ごまずん｜note

IVEC Level2試験の傾向と対策を予想します2｜ごまずん｜note

 

余談

試験時間３時間て絶対にお腹すくな〜と思って、

会場の最寄り駅についてからスタバでご飯食べました。

試験中にお腹鳴っちゃう問題は深刻なので。

 

試験後は会場近くの近江屋洋菓子店さんに寄って

レーズンヴィスクイを買って帰りました！

試験後のレーズンサンドは格別においしかったです〜 。

 

f:id:rina_qa_minarai:20210530201701j:plain

f:id:rina_qa_minarai:20210530201711j:plain

 

追記

IVECエントリーレベル2落ちていました...

かなり対策したのですが...講評を見て振り返ります...

 

自己紹介

はじめまして

ブログをはじめてみました。

ぜにと言います。

 

ゆるゆるとですが、同じくQAに携わる方に

有益なこともどうでもいいことも共有できればいいなあと思っています。

 

ブログ開設時点（2021/05）の経験

iOS/Android アプリの（主に UI ）テスター1年

↓

iOS/Android アプリのQAマネージャー（と言っていいのか微妙）1年

 

未経験のテスターアルバイトとして自社開発の会社に入社。

その年に ITパスポートとJSTQB FoundaitionLevel を取得。

翌年にQAマネージャーというポジションになりました。

 

プログラミングの実務経験ないし、テストコードも書けないので、

まだまだ勉強することはいっっっぱいありますが、

現在は転職活動を終え、新しい会社にてQAエンジニアとして活躍できるよう奮闘中です。