こんにちは！Classi QAチームの池田です。 今回は、テストを自動化した話をご紹介したいと思います！ （※弊社で使用しているテスト自動化ツールはAutifyです。）
なぜテスト自動化？
①品質の担保
弊社のQAエンジニアは、各開発チームに「専任QA」として配属されています。 私が専任QAとして所属している開発チームのプロダクト領域は「設定・登録」です。
プロダクトの中でもコアな部分であり、不具合や障害が起きればその他の機能にも影響してしまうため、とても重要な機能です。
例えば、「ID・パスワード配布/再発行」という機能があります。
「設定・登録」内でも使用率の高い機能ですが、仮にこの機能が動かなくなってしまった場合ID・パスワードの配布等ができなくなり、状況によっては多くのユーザーがログインすらできなくなってしまいます。
しかし、私がチームにジョインした当時は定期的なリグレッションテストが行われておらず、開発/QA側ともに既存の不具合があると認知しつつもすべてを把握してない、という不安定な状況でした。
重要な機能であるからには定期的にリグレッションテストを行い、この状況を改善する必要があると思いました。
②既存不具合の検出（＝現状把握）
自動化をするにあたって「既存不具合の検出」をしたいという目的もありました。
上記にも記載した通り、この領域は不安定な状況が続いていました。 開発チームに所属しているQAの立場として、この状況は一刻も早く解消したい問題でした。 そのため、テストを自動化する過程で既存不具合を検出し、現状把握をしていきたいと考えました。
STEP1 計画
まずは自動化の計画を立てるところからスタートしました。 具体的には下記内容を計画、準備しました。
①範囲
まず本番環境の自動化を進めることにしました。
そして範囲については、「メインパスを網羅すること」を基本条件としました。（メインパスについては、公開されているプロダクトのガイド一覧に説明があるパスをメインパス、と定義しました。） 限られた時間やリソースの中でまず優先すべきは本番環境、そしてユーザーが一番通るメインパスであると判断しました。
②テスターのアサイン
自動化するにあたって、QAチームのテスターの力を借りました。
テスターは開発チームには属さず、専任QAからの依頼ベースで動いています。 専任QAが検証でテスターを必要とした際に、QAマネージャーに手空きかの状況を確認し、一定期間テスターをキープする、という流れです。
もちろんテスターの最優先業務は検証であるため、今回私からテスターを一定期間アサインすることはせず、手の空いている際に自動化に対応していただくことになりました。 そのため直近のテスターの空き状況を確認し、どのくらい動いてもらえそうかを想定しました。
③完了期限
上記を踏まえた上で、大体の完了期限を設定しました。
約50シナリオの作成が必要となり、1日1人ほどはテスターを確保できそうでした。 1日1人で2シナリオ程度は作成可能であるため、期間を1ヶ月と設定しました。
④環境の確保、整備
弊社のプロダクトは学校（主に高等学校）に導入されており、学校単位で機能しています。 そのためQAチームも ”検証学校1"、”検証学校2”のように、本番環境にいくつか検証用の学校を所持しています。 環境についてはQAチームが所持している”学校”の中から、初期状態で1度も検証等に利用されていない"学校"を1つ借してもらいました。
また、最低限必要と思われるアカウントの作成等も行いました。
STEP2 自動化
自動化作業は想定よりもスムーズに進んだため、本番環境に加え検証環境でも自動化を進めることができ、両環境合わせて約1ヶ月半で無事完了することができました！
具体的にこの1ヶ月半での出来事を大きく4点に分けました。
①テスターの進捗管理
テスターの進捗を把握するため、作業してもらった日の終わりに進捗を報告してもらいました。
ただ、やはり難しかったのはテスターのアサイン状況の整理に関してでした。 テスターは直前でQAから検証依頼が入ることもあるため、空き状況が読めないことも多かったです。
しかし、テスターは以前からテスト自動化ツールに触れていたこともあり、私が想定していた以上にスピーディーに進めてくれました。
②Weekly MTGでの進捗報告、相談
私は今回テスト自動化が初めて、且つテスターの進捗管理も初めて、と初めてづくしだったため、QAマネージャーが「Weeklyで進捗相談のMTGをしようか」と提案してくれました。
当初は同じチームのQAメンバーとQAマネージャーだけで行なっていましたが、途中からはテスターも招待してMTGを行いました。 テスターとは基本Slackでやりとりしていましたが、Slackのやりとりではなかなか出てこないような些細な事、困っている事などを話せる場があれば良いのではないかと思ったからです。
また、私自身もテスターの意見から何か良い方向に取り入れられることがあればいいな、という思いでした。
③既存不具合の検出
想定していた通り自動化の過程で既存の不具合が検知され、計4件の不具合を起票しました。
どれもクリティカルな不具合ではありませんでしたが、開発側がすぐに改修に着手してくれました。 すぐに不具合改修に対応してくれた開発側には感謝しかありません...！
④改善要望チケットの起票
また、自動化の過程で改善要望チケットを2件起票しました。
改善要望チケットを起票した意図としては、正式な改修依頼ではなく、違和感のある、もしくは明らかに使いづらいUI/UXを記録に残しておきたいと思ったからです。
当時私が入社してからまだ数ヶ月だったこともあり、プロダクトへの使用感覚が新鮮だったのもあるかもしれませんが、少なくとも私の感覚ではおかしいな、と感じる挙動がいくつかありました。 QAとしてプロダクトを過信せず、こういった違和感を忘れないようにしたいと思いました。
STEP3 運用開始
当初は、自動化が完了してから運用（定期実行）を開始するつもりでしたが、開発チームから「できてるシナリオからどんどん回していけば？」と提案してもらい、自動化開始数週間目から定期実行をスタートしました！
運用についてはまた別途記事を書く予定ですのでここでは割愛させていただきます！
STEP4 振り返り
この1ヶ月半を振り返り、良かった点と反省点がありました。
良かった点：進捗報告や相談を定期的にできた
QAメンバー、テスターとの定期的なMTGで進捗報告や相談をすることができたお陰で、スムーズに進めることができたと思います。 もし定期的に相談できていなかったらアドバイスを頂いても事後となってしまい、後回しになっていた可能性もあったと思います。
反省点：環境の準備不足
一方反省点としては、環境の準備が不足していたと感じています。
開始前にログイン等に使用する必要最低限のアカウント等は準備していたのですが、作業過程で必要になる細かな設定等を把握できておらず、自動化しながら必要な設定やアカウントに気づき都度追加していく、という流れになってしまいました。
例えば、Classiに登録されている「先生」を検索し、ページネーションの確認をするというシナリオがありました。1ページに表示される「先生」の数は20人のため、ページネーションを確認するには最低21人の「先生」の登録が必要でした。 このようにシナリオで具体的にいくつのアカウントが必要になるか、という想定ができていなかったため、作業中のテスターに余計な作業を増やしてしまう結果となりました。
テスターに指示を出す側の私が、もっと事前に準備に時間を費やすべきであったと反省しています。
まとめ
私は2022年にClassiに入社したのですが、入社以前からテスト自動化に興味を持っており、今回テスト自動化に携われたことがとても嬉しかったです！ （私が入社前後で感じたClassi QAチームについての記事もありますので、ぜひご覧ください。）
入社前後で感じたClassi QAチーム tech.classi.jp
自動化の作業はもちろん、テスターの進捗管理等初めて対応する業務が多く勉強になりました。 自動化を進めていく過程で、想定していなかった改善要望チケットの起票など、プラスαでできたこともあり、プロダクトに対する気づきも多かったです。
現在運用中の内容、取り組みについても今後こちらのClassi開発者ブログにて共有していきたいと思っております！
