TIMO Meetingの開発におけるリグレッションテストの進め方

こんにちは。
パーソルプロセス＆テクノロジー株式会社 プロダクト統括部 developmentGの赤嶺です。

2023年12月にSI事業部から異動してきました！
いまは経営会議のためのマネジメントツール TIMO Meetingの開発をしています。

今回はTIMOで最初に担当した
「リグレッションテストのシナリオ/ケース作成」についての話です。

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

まずリグレッションテストを簡潔にいうと
「ソフトウェアを変更した際に、その影響を確認するテストのこと」です。システムが複雑になるにつれ、変更した機能とは関係ない機能で不具合が生じる可能性が増加するといわれています。
そういった不具合を検出する目的で実施するテストです。

TIMOでは2週間のスプリントの中で新機能の開発・不具合の改修を行っています。スプリント内での変更した機能とは全く別の機能で不具合が生じていないことを確認する目的で毎回実施するテストとしました。

リグレッションテストの作成とテスト自動化の背景

以下の3つの背景から不具合を早めに検知する仕組みを考える必要がありました。

①  UAT（開発チームとは別のチームによるテスト）の段階で、
既存機能の不具合が見つかるケースがありリリース直前に修正がたまることがあった。

② 限られた人員（3人のエンジニア）で2週間のサイクルで開発&リリースを行っています。
そのため、テストの期間が短く、テストケースの相互レビューやテスト実施を十分に実施できずリリース直前になって既存機能の不具合を検知することがあった。

③ 今後フレームワークを変更する計画があり、
フレームワーク変更後にTIMO全機能に悪影響がないか確認する必要があった。

早期に不具合を検出する方法として、
リグレッションテストの作成とテスト自動化を行うことになりました。

テストシナリオ/ケース作成の進め方

大きな流れとしては以下の進め方で考えていました。
今回は①までの紹介で②～⑤は必要があれば追記したいと思います。

① リグレッションテストシナリオ/ケースの作成
② 開発チーム内の有識者や（要件を定義する）ビジネスチームによる①の成果物のレビューと指摘事項の反映
③ テストの自動化範囲の検討
④ テスト自動化ツールによるテストの作成
⑤ 自動テスト実施タイミングの検討と設定

① テストシナリオ/ケースの作成

次の順にシナリオ/ケースの作成の準備を進めました。

対象範囲
まず対象範囲を定めました。
今後フレームワーク変更の計画があり、
全機能への影響が見込まれるたため、このタイミングで対象範囲を全機能と定義しました。
プロジェクトの状況に応じて対象範囲は絞って小さくスタートしてもいいと思います。

【対象範囲】
　全機能

テスト粒度
次にテストの粒度を決めました。
ある程度の粒度を決めていない場合、
細かすぎてケースのメンテが難しくなったり、
機能や担当者によってばらつきが出るので粒度感を決めました。

【テスト粒度】
　単体テストのレベル：対象外
　　　各開発担当者が実施するため本テストでは対象外とする。
　結合テストのレベル：一部対象
　　　各開発担当者が実施するが一部重要機能を本テストの対象とする。
　総合（業務シナリオ）テストのレベル：対象
　　　実際のユーザ利用を想定したシナリオを本テストの対象とする。

INPUTとする資料の定義
次に上記の粒度でテストシナリオ/ケースを作成するための
INPUTとする資料を定義しました。

　・業務一覧
　・機能一覧
　・画面一覧
　・メール一覧
　・バッチ一覧
　・帳票一覧
　　など

今回は対象の資料がなかったため、
画面を操作しながらリバースして作成しました。

抜け漏れなくシナリオ/ケース作成するには、
INPUTとする材料は一覧化して整理する必要があります。
資料がない場合は作成、情報が古い場合は更新する必要があります。
また作成や更新をした際には、有識者などによるレビューがあるとなおよいと思います。

テストシナリオの作成

基本的には業務一覧をベースに作成しますが、
機能一覧や画面一覧などの上記INPUTをもとに、抜けもれなくシナリオに落とし込んでいきます。

シナリオ作成時に想定するケースも概要レベルで記載すると
ケース作成時に再度考える必要がなくなるので楽になります。
以下ではプロセス列に記載しています。

イメージ例）

業務一覧

テストシナリオ

テストケースの作成

次にシナリオをもとにケースを作成します。
シナリオ作成時と同様に機能一覧や画面一覧などの上記INPUTをもとに、抜けもれなくケースに落とし込んでいきます。

イメージ例）

テストケース

今回は時間の都合上、簡略化して既存のドキュメントを流用して記載しました。ケース番号、前提条件、確認手順などを加えるともっといいと思います。

結果

現在フレームワークの変更を対応中ですが、
上記のリグレッションテストにて不具合を検出し価値を発揮することができました。
また自動化できたことで、早期に不具合を検出できるようになりました。
（夜間ツールを実行して翌朝には不具合を検出）

これから改善したいこと

・新規機能の開発後、リグレッションテストのシナリオ/ケースの見直しフローを考えられていないため、シナリオ/ケースの情報が古くなる。
開発サイクルに組み込む必要があるが、他対応が優先され対応できていない。メンテしやすい仕組みに変える必要がある

・ツールはSaaS製品を利用しているのでツールの仕様やコストに以下が制限されている。
　　- 自動化できる範囲
　　- ツールの設定の実装や管理方法
　　- テスト実行回数
SaaS製品の恩恵を受けつつも制限されている部分の影響が大きいため、
メリデメを今一度整理する必要がでてきた。

最後に

弊社は一緒に働いていただける方を募集中です！
就職/転職活動中や、まだ情報収集中の方、
少しでも興味を持っていただけた方は、以下のアドレスに「note見た！」とご連絡いただけると幸いです💡
プロダクト推進部/採用担当アドレス：pdo_js@persol.co.jp

タイトル未設定