リグレッションテストを導入した話

こんにちは。N予備校の品質保証グループです。
品質保証グループでは、日々案件ごとの業務に関わっています。今後はより横断的な関わりを強化していき、開発チームと密な連携を進めようとしています。
そこで、今回はリグレッションテストについてお話しようと思います。

リグレッションテストとは?

一般的には、新規機能や既存機能の改修、不具合修正によって、既存機能に意図しない影響が出ていないかを確認する目的のテスト全般のことを指します。
リグレッションテストをしないと、元々問題なかった機能が使えなくなったり、意図しない動きになっていたりと品質低下に繋がります。

横断リグレッションテスト導入前の状況

品質保証グループは2021年1月に立ち上がりました。(チーム立ち上げのブログ詳細はこちら)
以前までは機能ごとの動作確認はもちろんのこと、リグレッションテストも同様に開発チームごとに開発者が自身の手で行っていました。

同じN予備校のサービスをクライアントごとに提供していますが、リグレッションテストの確認項目ややり方はまちまちという状況でした。 よって、共通のテスト項目は存在していなかったというわけです。
そこで横断的にリグレッションテストが行えるよう、品質保証グループでとりまとめていくことになりました。

横断リグレッションテスト導入にあたってやったこと

導入にあたり、いくつかやったことをお話します。

1. 動作確認項目書の管理方法の統一

品質保証グループでは、一般的にテスト設計で作成する「テストケース」のことを「動作確認項目書」と呼んでいます。 この「動作確認項目書」が、各クライアントごと(iOS,Android,PC web)バラバラで管理されていました。

具体的には、Confluence、GitHub、Google スプレッドシートと開発チームでバラバラでしたので、Google スプレッドシートに統一して管理することにしました。
これは品質保証グループとして管理のしやすさから、このような以下の形に着地しました。
・案件ごとの機能テスト時の動作確認項目書がGoogleスプレッドシートを使用(過去ログ一元管理可)
・動作確認項目のメンテナンスのしやすさ
・テスト協力会社などの第三者への情報提供のしやすさ

2. テストしている/していないテスト動作項目の統一

同じ機能を搭載している部分であっても、確認範囲の細かさや視点が異なっていたりと各クライアントで粒度に差がありました。
品質保証としては、クライアントごとの温度感を合わせ、安定した品質を提供するために、いいとこどりで項目化することを決めました。
また、このタイミングで確認が不足していた部分の項目追加を行いました。
開発チームでリグレッションテストを実施していた時もより、工数は少し増加してしまうかもしれませんが、まずは安全策を取る形にしたのです。

3. テスト動作確認項目手順の詳細化

基本的には品質保証グループ内で実施しますが、新たに仲間が増えた場合や、時には第三者テスト会社さんの協力を得て動作確認をすることが出てきます。
N予備校の仕様把握していない人でも、確実に期待結果まで確認できるようにする必要があります。
そのために、動作確認手順の詳細化を行いました。
例えば、開発チームでのテスト項目内容で、
・〇〇の教材を受講完了することができる
という機能を確認することのみとなっていたものに対して、この機能を確認するまでの手順や手順時に使用する教材のテストデータ、アカウントといったものを細かく設定しました。

f:id:takumaron:20211020171737p:plain
動作確認項目書の一部抜粋

横断リグレッションテスト導入後の状況

数回程度の運用を通して、横断的に対応するベースは出来上がったと感じます。 実際にやってみた所感を羅列したいと思います。

達成できたことは、以下2点です。

達成1. 運用がスムーズにいった

これは当然ながらのことであり、それは自身で作成したものであるからです。自身で作成したものにやりづらさがあるならば、自身の作成/構成能力を疑った方が良いですね。。。 今後は他スタッフも実施していきますが、安定的にリグレッションテストが回していけるように進めたいと思います。

達成2. 開発実装に注力できる環境のベースが作れた

前述の導入前の状況でもお話しましたが、リグレッションテストは開発者自身の手で行っていました。品質保証グループで運用することで、開発チームにはより開発に専念できる流れが作れたかなと思います。


一方、課題もいくつか出てきました。

課題1. 確認環境が複数で行き来する必要がある

確認する機能によって、「本番環境(商用環境)」「本番相当環境」「特定機能確認環境」を使い分ける必要があり、最大3つの環境を行き来する手間が発生しています。
どうしても同じ環境で確認できないものが存在しており、こればかりは現状致し方ない部分ではあるので、確認手順の効率化で当面は乗り切っていこうと思います。

課題2. 新機能リリースの狭間でクライアントごとで機能構成が異なる

本ブログが掲載されるタイミングでは、iOSとAndroid&PCWebで使用できる機能が異なっています。それは最近大幅にリニューアルされた「ホーム画面」です。
3クライアントを同時にリグレッションテストを進めると、この辺りに差が出ていて混乱の元となりリグレッションテストのしづらさが出ました。
現在の機能はもう少しで統一されるため解消される問題ではありますが、今後もクライアントごとでリリースタイミングが異なるものが出てくれば、同じ状況に遭遇することは間違ないなと感じています。

旧ホーム画面 iOS版 新ホーム画面 Android版
f:id:takumaron:20211020171658j:plain
f:id:takumaron:20211020171256j:plain

今後の展望など

日々進化するN予備校のサービスのため、リグレッションテストもそれらに対応するために進化していく必要があります。
テスト項目の改善はもちろんのこと、効率化を視野に入れていかなければならないと感じています。
今後はリグレッションテストの自動化を検討しつつ、品質保証グループで対応できるメニューも増やしていきたいと考えています。

We are hiring!

N予備校 品質保証グループでは、一緒に品質保証を進めていただける方を募集しています。

採用に関係のないカジュアル面談も行っています。
この記事の内容について、また 品質保証グループ全般の活動について興味がありましたら、ぜひお気軽にお話しましょう。

カジュアル面談応募フォームはこちら

saiyo.dwango.co.jp

N予備校の他チームの取り組み、教育事業の今後については、他の記事や採用資料をご覧ください。

speakerdeck.com