テスト設計からテスト実行までQA初心者が挑戦してみました！

文系学部出身のQA初心者が、テスト設計からプロダクトチームへの報告まで一連のプロセスに挑戦してみました。
今回の記事では、取り組みを通して得た知見をご紹介します。

はじめに

こんにちは！グロービス・デジタル・プラットフォーム QAチームでアルバイトをしている岩崎です。
実は、テックブログを書くのは、2回目です。
前回の記事は、想像以上にたくさんの方に読んでいただけたようで、うれしかったです。
もしよろしければ、前回の記事もご覧ください。

https://note.com/globis_engineers/n/nc94a6c29ccd0

今回の記事では、QA初心者が実務でテスト業務全般を行なうときに考えていたことや、どんなサポートをしてもらいながら業務を進めていったかをまとめてみます。
似た立場にいらっしゃる方の参考になれば幸いです。
＊この記事では、「QA＝プロダクトの品質向上を目的とした活動全般」としています。

なぜ挑戦しようと思ったか

テストや品質管理について学んで1年経った段階で、どれくらい実務をすることができるのか自分の力量を試してみたかったからです。また、JSTQBのシラバスにかかれている内容がどれくらい現場に即したものなのかを肌感覚で確かめてみたかったからです。
以上をふまえたうえで、テストを担当してみたいと上長に伝えたところ、案外簡単に「いいですよ」と言ってもらえました。挑戦することを前向きに捉え、サポートをしてくれるのでとても仕事がしやすく、ありがたく感じています。

対象となったプロダクト

本題に入るまえに、テストの対象となったプロダクトと機能について少しお話します。 このプロダクトは、グロービス 学び放題 フレッシャーズという、グロービス学び放題とは別の関連サービスで、内定者や新卒者の方を対象にしたものです。 担当したのは、このプロダクトの申込システムの社内管理画面で、1申込あたりのログイン率と進捗率のデータを表示する機能のテストです。
検索欄に、登録されている企業様の名前や、開講日、閉講日などの絞り込み機能があり、検索をかけるとログイン率と進捗率が表示されます。

どんな風にテストをしたのか

テストの基本的な流れは上長に教えてもらいましたが、JSTQBのシラバスでいうテスト分析からテスト設計、テスト実行、テスト完了まで、作業全般の実行は私が担当しました。
上長には、テストのためのタスクの細分化、また、それぞれの締め切りを設定してもらい、カンバン方式でタスク管理をしてもらいました。加えて、週１で業務進捗報告会をし、前の週にしたことと次の週までにすることを報告、フィードバックをもらう形で進めていきました。

苦労したこと・大変だったこと

一番困ったのは、テスト設計の段階では、一部で具体的な仕様が決まっていない部分があり、それをどうテストに反映するかを考える必要があったことです。
実務の世界では、テスト設計段階で仕様が決まっていないという事態は、往々にして起こります。
それはある程度予想していたのですが、「何をもって正しい挙動とするのか」の判断軸となる仕様が決まっていないことがありました。そのときは、開発さんにその旨を伝え、正しい挙動を決めてもらいました。また、開発側で想定されていないユースケースを指摘したため、テストをややこしくしてしまうことや、開発チームのチケットに書いてある独特な言葉を理解するのに時間がかかることがありました。

テストをするうえでの課題とその解決策

今回のテストでは、テストをする時間が限られているにも関わらず、ある程度の品質が保証された状態でリリースをする必要がありました。
この課題を認識したとき、まず、どういう状態であれば、このシステムの品質は保証されるのかについて考えました。まずは、自分で考えてみて、そのあと出た考えをもとにチームメンバーに相談しました。その結果、今回の場合は、①表示されるデータが間違っていないこと、②システムを使う側が頻繁に使う機能で不具合が起こらないことの2点が最低限必要な条件だと判断しました。
①に関しては、こちらで確認ができましたが、②に関しては、ユーザーの視点に立ってみないと必要な機能が見えてきません。そのため、ユーザーとなる社内の方に直接インタビューを行ない、使用頻度が高い箇所を洗い出し、その箇所を重点的にテストしました。これは、テスト対象が社内システムだったからこそできたことですが、短期間でテスト範囲を絞り込むのには、効果的な方法だと感じました。
このような取り組みの結果、ステークホルダーにとって必要だと思われる機能を重点的にテストをしながらも、時間内にテストを完了できました。

結果として得られたもの

プロダクト面でいうと、クリティカルなバグをいくつかリリース前に修正することができました。具体的には、実際の進捗率が0.2%でも進捗率0%と表示される問題（小数点切り捨て問題）などがありました。
もしそのままリリースされていたら、後々問題になるおそれがあったので、そのような不具合を見つけることができてよかったです。
さらに、クリティカルなバグを見つけたことで、プロダクトチームに貢献でき、仕事をするうえでの自信がつきました。

個人としては、基本的なテストの進め方を実体験をもって学ぶことができました。
これまではテスト実行のみをしていたので、テストを全体的な過程として見ることがあまりなかったのですが、テスト分析からテスト完了まで関わらせてもらったことで、テストという業務を俯瞰して捉えることができ、業務をする上での解像度が一気にあがりました。
チームメンバーの会話に出てくる言葉が、以前よりも具体性をもって感じられるようになり、ミーティングで話されていることが理解しやすくなりました。
JSTQBシラバスで書かれていることと実務を結びつけるのは、場合によっては少し無理がある気もしましたが、シラバスで学んでおくと実務の場でも、いわゆる「教科書どおりの対応」まではできるようになります。基本を身に着けたい初心者にとってはいい経験になると感じました。

今後の抱負

今回のテストでは、時間がかかってしまったので、今後似たような業務を担当する際は、もう少しスピードを意識して取り組みたいです。また今回は、社内システムのテストだったので、お客様が直接操作するシステムのテストにもいつか挑戦してみたいです。そのような業務を担当させてもらえるように、これからも日々の業務を通して学びを深めていければと思います。
最後に、今回のチャレンジは、基本的なことを何回も質問してもやさしく答えてくださったプロダクトチームの方や、ささいなことでも相談に応じてくださった上長やQAチームメンバーからのサポートがあったからこそできたことです。
このような環境で働けることに感謝をしつつ、もっと成長していけるよう頑張っていきたいと思います。