QA未経験の駆け出しエンジニアが、IVRyの爆速開発をサポートできるようになるまで
こんにちは、電話自動応答サービスIVRy QAEの関(@IvryQa)です。
1人目QAEとしてIVRyにJoinし、本格的にQAを取り組み始めて半年が経ちました。
私の自己紹介については、過去の記事をご覧ください。
QA未経験だった私は、「QAはテストする人」ぐらいの認識で、右も左もわからない状態でしたが、現在では爆速開発をサポート出来るようになりました。※ IVRyでは毎週リリースを行なっています。
本noteでは、未経験のQAEの私がこの半年間で取り組んだことに焦点をあて、振り返ってみました。
ぜひ、最後まで読んでいただけると光栄です👏
IVRyについて
まず課題と感じたこと
【個人】QAに関する知識不足
【社内】QAに関するルールがなかった
特にルールはなく「クライアントに提供する最後の砦」いう言葉とテスト項目書、不具合発生時の共有方法だけでした。
課題に対しての取り組み（個人編）
QAに関する知見を集める
知見を集めるために、2,3日掛けてqiitaやnoteを約30本、本を5冊ほど読みました。
また、meetyを利用してQAEさんと繋がり、スキルセットやQA × 開発 × ディレクターの関係性、開発フローなどの生の知見を集めていきました。
現状の悩みや工夫してるポイントなども聞けるので、本やドキュメントの情報だけだとよくわからない。具体的なイメージがわかないと感じてる方はおすすめです。
※ 今でも、QAの取り組みや運用フローを改善する上で参考になっています。
課題に対しての取り組み（社内編）
① QA・テストの再設計
② QAに関するドキュメントを整備
課題でも取り上げましたが、QAに関するルールがなかったため、QA・テストを再設計しながら、ルールを作っていくことにしました。
① QA・テストの再設計
QA・テストの再設計では、「テスト計画・テスト設計・テスト実行・不具合、バグの共有方法・不具合、バグの管理」を行いました。
a. テスト計画
まずは、大まかなアクションを洗い出しました。
アクションについては、改善することを前提として、解像度が荒くてもいいので書き出していきます。
シナリオ作成のために「現状のIVRyの調査」が必要だとわかりました。
【現状のIVRyの調査】
画面一覧を元に、機能ごとの仕様調査
因子と水準調査
因子と呼ばれる「条件」に対して、水準「因子の値」を洗い出すことで、データバリエーションや組み合わせテストの検討が容易になります。
エラー調査（入力バリデーションなど）
「準正常系テスト」を作る際の検討材料として調査しました。調査内容は、機能や該当画面、発生条件とエラー文言を記載します。
※ 準正常系: ユーザ操作によって発生する想定内のエラー
b. テスト設計
調査内容や過去のテストケースを元に、「ユーザシナリオ」を作成しました。ユーザシナリオの作成では、シナリオの抜け漏れを防ぐために、IVRyメンバー全員に呼びかけ全員レビューを実施しました。
最後に、ユーザシナリオと画面一覧を比較し、開発チーム全体で抜け漏れがないか確認しました。
そして、設計書をもとに、「テスト項目書」を作成しました。
これまでのテスト項目書は、「ログインが正しくできた」など漠然と書かれているテスト項目書でしたが、期待値を記載し、何をもって「OK」とするか、また「NG」とするかを明確にしました。
さらに、入力条件や再現方法まで記述することで、誰が実施しても同じテスト結果になるようにしました。
さらに、テスト実施へ向けテストで使用するアカウントの作成や不具合チケットのフォーマット作成、QA専用のSlack ch/notionのチケット管理一覧を準備しました。
今回は、IVRyの作り直しが同時期に進んでおり、開発とQAを並行して進めることになった為、どの順番でQAを行うかを機能別にスケジュールを作成しました。
c. テスト実施
テスト項目に従ってテストを実施します。
d. 不具合、バグ共有方法
不具合、バグ共有方法については、以下の運用フローに決めました。
1. 不具合、バグの発見後、事象を確認する
2. Slackにて、関係者へ不具合、バグを共有する
3. すぐに修正対応できない場合は、notionで不具合チケットを作成する
4. チケット作成後は、スレッド内でチケットを共有する
不具合、バグの共有時は、画面キャプチャを添えることで認識ずれがなくなるので良いです。場合によっては、バグの特定がしやすいようにデベロッパーツールのネットワークタブでAPIレスポンスのステータスコードや、レスポンス内容を添えると良いと思います。※ 開発環境によって異なりますが…
さらに、不具合、バグの共有内容はフォーマットに沿って記載することで可読性が上がります。
[不具合共有のフォーマット]
事象:
-
環境:(必要に応じて)
-
期待値:
-
再現方法:
1. xxをクリック
2.xxをクリック
備考:(必要に応じて)
-
e. 不具合、バグ管理
Slackベースで管理されている不具合に関しては、適度なコミュニケーションを取り実装状況を把握していました。
notionで管理している不具合チケットが多くなった場合は、開発メンバーと優先度を選定しました。（優先度:低になったチケットは、リリース後に対応しても良い or 修正できるタイミングで対応するなど基準を決めました）
② QAに関するドキュメントを整備
QA設計中やテストで得た知見は、社内のナレッジを貯める目的で、ドキュメント化していきました。
ですが、ドキュメントを常に最新の状態に更新することが難しく、効率良く運用する方法はないか模索しています。
新しく関わる方のためにも、整備し続けたいと考えています。
これらを通して良かったこと、難しいと感じたこと
良かったこと
① 大型リリース後に、大きな不具合が発生しなかったこと
大きな不具合が発生しなかった要因として、テスト設計時の「シナリオケース」が網羅されていたことが大きいと考えています。「シナリオケース」を元に「テスト項目書」が作成されるため、「シナリオケース」の時点で漏れていると「テスト項目書」の時点では抜けてしまいます。なので、時間をかけて作り込む事をおすすめします。
また、開発チームのレビューだけではなく、IVRyメンバー全員レビューを行ったことで、様々な観点から網羅性を担保することができました。
② QA・テストを1から再設計したことによって、QAの知見が高まったこと
未経験だった当時は、テストをこなしていただけの人に思えます。1から設計したことによってQAの知見は一気に深まりました。全体像がシャープになることで、新機能などのテスト設計を早いサイクルで回せるようになりました。
③ 不具合の共有をフォーマット化することで、認識ズレが減ったこと
不具合の共有時に認識ズレが発生し、事象の説明や認識を合わせにいく時間が多く発生していました。フォーマット化することで、事象が正確に伝わるようになり、可読性も上がります。認識ズレが発生した場合は、新たな項目を追加、更新できるので、双方にとってベストな状態を簡単に作ることができます。
難しいと感じたこと
不具合共有時のFE/BEの切り分けと情報の粒度
不具合の原因がどこにあるのか、開発者が欲しい情報は何なのか、事象に対して対応する人は誰なのかなど、適切に対応できなかったことが難しかったです。開発知識がないことによって、言われた言葉の意味を理解していないまま進めていたり、言葉を調べるが、即返答を求められることで勝手なバイアスが発生し心理的ストレスを感じたこともあります。
しかし、開発チームの濃いコミュニケーションをきっかけに改善されていきました。
不具合の調査方法を教えて頂いたり、「画面キャプチャにデベロッパーツールのネットワークを開いた状態で撮ってもらえると嬉しい」という意見をいただいたり、適切な担当者が割り振られていないチケットに関しては、オープンな形で対応していただいたことで、コツを掴むことができました。
また、FEやBEの実装をやらせて頂く機会があり、経験ベースで開発知識と向き合っています。
まとめ
未経験の状態からQA・テスト再設計を経験し、爆速開発のサポートが出来るようになったのは、網羅性のあるテストを早いサイクルで作成できるようになった、認識ズレを減らす取り組みで全体工数が抑えられていることが主な要因と考えています。
まだまだ、取り組めていない箇所や改善の余地はありますが、常に課題を見つけて前向きに取り組んでいきます。
これからも、爆速開発を行いながらIVRyを安心してご利用いただけるようサポートしていきたいと思います。
最後に、IVRyでは一緒にプロダクト開発を行うエンジニアさんを募集してます
本noteを読んで、少しでもIVRyが気になった、開発に興味を持った方は、ぜひお話ししましょう！！
この記事が気に入ったらサポートをしてみませんか？