【初心者向け】QAエンジニア１年目がぶち当たった壁と、初期に意識すると良いことまとめ
１、この記事の概要
QAエンジニア１年目のCarolです。
QAとしての実務は半年を超え、ここ最近ようやく業務中に「これから何に取り組んだら良さそうか」「次に何を目標に立ててチームへの貢献をしようか」「そのために何を具体的にしようか」などといったことが自分で計画を立てて行動できるようになってきました。
振り返ると、「もっと最初の時期にきちんと勉強しておいた方がよかったなぁ」と憤りを感じたことがあったので、それらをまとめました。
２、読者対象
・QAを始めてまだ経験が浅い初心者
・テスト業務を始めてこれからステップアップを考えているが次に何を取り組んだらいる駆け出しさん
※目標や学習ステップは個人や組織で異なるので、あくまで個人の体験に基づいた感想、として参考程度に読んでいただけると嬉しいです。
３、成長曲線の軌道に乗れなかった時に感じた壁と、つらみ
（１）スキルアップの適切なステップがわからなった
QAエンジニアって、やることは結構多岐に渡ると思います。例えば
- ・テストを設計する
- ・テストケースを書く
- ・テストを実施する
- ・テストを自動化する
- ・テスト結果を管理、分析して次のPJに活かす
また現在所属している会社では、QAEのステップアップのモデルとなるシニアの方やアドバイザーの方がおらず、適切な目標の立て方がわからなく、配属初期の頃はとにかく渡されたテストケースを消化するマシンと化していました。
日々増えていく単純作業に追われる毎日で忙殺され当然楽しさや充実感も十分に感じられない中、テストを実施するだけでなく、上記の項目に対してバランスよく取り組んでいきたいし、チームでうまく分業できるようになりたい、でも限りある人数と時間の中でどこから手をつけたらいいのだろうか？という思いも常に心の中にあり、理想と現実のギャップに苦しんだこともありました。
（２）どうしたらテストケースを作れるようになるのかわからなかった
業務の中でも「テストケースを作成する」ことは大きな仕事の一つだと思うのですが、そこが個人的に結構なハードルを感じていました。先輩の作成したテストケースの見様見真似で「こんなふうに作っていけばいいのかな？🤔」とイメトレすることはできるのですが、実際形にすること、そしてそれらに漏れがない精度で完成させることにはそれぞれ大きなハードルがあると感じています。
少し疑問点の解像度を上げると、
- テストケースは完璧に書こうとすると何万通りもできてしまうので、その中から効果的なテストケースを選別し、うまく削るための指標がわからない
- 完璧ではなく最適なテストケースを作るにはどんなステップを踏んだら良いかがわからない
- どの切り口からテストケースを作成・レビューを開始したら漏れがなく行えるのかがわからない
- チームやテスト実行者にとってわかりやすいテストケースを書くために必要な情報の選別の仕方がわからない
- 自動化する箇所に明確な自信がない
以上のような「わからない」が組み合わさって、テストケースのレビューや作成業務に心理的ハードルを感じてしまっていました。
（３）キャリア初期の段階でQA像を深掘りしてしまい沼にハマってしまった
QAの仕事内容は上記に述べたのですが、より理解を深めようと、キャリア初期のスキルが乏しい状態で「QAとは」という奥深すぎるところまで視点を広げてしまい、どこから手をつけていったら良いのか混乱してしまったこともありました。
知識のインプットは大切だし、多くの情報に触れていくことはQAとしての見識の深さを広げるので良いことだと思うのですが、キャリア初期の段階、という「今必要な情報」の優先順位を間違える可能性があるタイミングで、あまりに色々なことに視点を広げすぎてしまって、効率の良い成長を感じることはできませんでした。
４、ちょっと知識や経験が貯まってきて見えてきた、「駆け出しQAエンジニアが最初に学ぶと良いこと」
上記のように、うまく成長曲線を感じられずつらみを感じていた時期もあったのですが、やっていくうちにすこしずつ「こうしていけばいいんだ！」というコツがわかってきました。
そのきっかけとなったのが、会社の先輩の「テストしてきたこれまでの期間の中で出会ったバグとか、感じたこととか、経験を生かすのも大事だよ」という言葉でした。「QAはこういうことまで考えるべき！」といった自論に縛られることを一旦止め、これまでチーム活動の中でやってきた基本的なことに注力しよう、と感じた瞬間でした。
下に、具体的に意識していることをまとめました。
（１）まずはたくさん製品を触って慣れる
当たり前のことかもしれませんが、製品を触ることで、今まで知らなかった「ソフトウェアサービス」の暗黙のルール、やよくある製品の構造、こういう時にはページに表示されるもの、などの暗黙のルール的なものを無意識に把握していたことに気づけました。製品は成長していきますので、その過程でもたくさん製品を触ることで、その製品に対しての癖を把握し、「勘」が養われるようになってきます。
これらの視点や勘は、機能や製品が変わったとしても、生かされるのではないか、と思っています。
（２）技法と知識のインプットを正確にしよう
ここは個人的に重視したい、かつ重要だと思う点です。
経験談ですが、ソフトウェア開発のフローというものが把握しきれていないうちは、なぜこのタイミングで「あるテスト」をしているのか、また「されていないのか」がわからなくて、言われるがままになんとなくテストを行うことになってしまいました。
「決まっているタスクだから」という流れでテスト作業がルーチンになってしまうと、製品が成長していくごとにテスとしなければならない項目も増え、結果的に工数管理ができなくなってしまったり、テスト内容に漏れが生じてしまうように思います。
また、なぜ先輩方がそのテストケースを書いていて、何を意図として書かれたテストなのかがわからず、何が守られたのか理解せずにテストを実行することになってしまいます。
従って、「正しい技法と知識」をインプットすることで、
・このテストケースで何を確認したいのか
・なんのためにこのテストをするのか
を意識してテストを実行することができるので、他人が書いたテストケースのレビューをする際や、効果的・効率的なを実行することができるのではないかと思い、個人的には特に重要な作業であると考えています。
また、テスト関連の知識や技法は、複数の切り口があって最初混乱しやすいかもしれません（自分だけかもしれません😅💦）ので、製品を触るときに、インプットした知識や技法を頭の中で確認しながら製品と関わると良いのかもしれません。
・E2Eテスト
など、これらはそれぞれ何のためにあって、何を確認したいテストなのか、を意識して学ぶと、記憶に残りやすいと思います。図などを用いて整理してみると、よりいいかもしれません。
さらに、テストの知識や技法だけでなくて、ソフトウェア全般の知識を持っておくことで、PJのテストの優先順位や、重要度が分かり、チーム内での話し合いや先輩の指示が理解しやすくなり、チームとしての共通認識や目指すものを汲み取れるようになると思います。
（３）いろんな立場や経験の人にアドバイスをもらおう
QAチームは人数が少ないのと、他チームや他部署と関わる機会も生じるため、いろんな立場の人とのコミュニケーションを取ることが大切です。また会社によって優先するべきことも異なりますが、社内のチームだけで話しあうには考えが偏る場合もあるので、経験が浅いうちに、あらゆるQAイベントや勉強会、交流会などに出向いて、他社のQAEチームの運用についてヒアリングしたり、他社から見た自分の会社のQAEチームの運用についてアドバイスをもらうと、新たな視点の発見になり、参考になるかもしれません。また、自分の成長のステップアップについて客観的に見直すきっかけになるかもしれません。
５、最後に、おすすめの本や記事
以下の教材やイベントなどを活用して学習し、スキルアップに臨んでいます。
・ソフトウェア技法練習帳
この本はテスト技法の基本を簡単な練習問題サイズの内容でテストケース作成の練習をすることができます。
複雑なテストケースを作る前段階において、あらゆる場面に適した技法の、考え方を学ぶことができます。結構例題設定も面白いものが多いので、チームで輪読しながら取り組んでいくと大変勉強になります。
・web技術の基本
ソフトウェア全般のことがわかりやすくて一番おすすめ
イラスト図解式 この一冊で全部わかるWeb技術の基本 | NRIネットコム株式会社, 小林 恭平, 坂本 陽, 佐々木 拓郎 |本 | 通販 | Amazon
・ソフトウェアテスト293の鉄則
少し詳しい、Q & A方式で書かれているので、頭の中の疑問に答えてくれるような形で読めるため、個人的に頭に入ってきやすいのでおすすめ。
・イベント
conppassのイベント ：
JaSST: JaSSTソフトウェアテストシンポジウム-JaSST'22 Tokyo
その他各社が開催するQAイベント
などなど。おすすめの教材を知っている方いたら、教えてください😁
では 👋
