はじめに
この記事では、私が担当しているタイトルで行った定常的なテストの工数削減過程を紹介します。「定常的なテストの工数が膨らんでいて削減したい」「設定値テストの導入の仕方が分からない」という方は参考になると思うので、ぜひご一読ください。
直面していた問題
当時、担当していたタイトルでは新規イベントや大規模な機能改修が進んでおり、テスト工数が増加傾向にありました。また、対応できるテスト担当者やかけられる予算に限りがあるため、テストの稼働に限界が近づいていました。そこで、QAチームとして、テスト内容の見直しによる工数削減の検討を開始しました。
現状の整理
安定して削減効果を得るために、定常化した施策を対象としました。
過去のテスト工数実績やテストケース、不具合などを調査しました。その結果、定常化している施策の特徴としては以下の様なものがありました。
- 別々の施策が月に複数回予定されておりいずれもテスト規模は大きめ
- 報酬/日時といった設定値の変更がほとんどで機能的な改修は稀
その上で「リスクはできるだけ抑えつつ、逼迫した状況の早期解決を図ること」を本取り組みの前提としました。
改善策の検討
対象の選定
整理した内容から、定常施策のテスト内容見直しを進行することにしました。
定常施策のテスト項目は、大別すると「バナーやお知らせなどの表示テスト」「報酬や日時などの設定値テスト」「定常機能や改修箇所などの動作テスト」の3つに分かれています。
検討を重ねた結果、前提を満たしつつ効果が見込めるテスト項目として設定値テストを対象にしました。
理由としては以下のとおりです。
- ほぼ全ての定常施策に組み込まれている
- 機能的な改修等リスクの高い箇所は動作テストで担保できる
表示テストと動作テストも工数削減できないかを検討しましたが、作業手順を中心にテスト内容の変更が多く生じ、リスクが高く対応コストも膨らむことから対象外としました。
削減に向けた調査
設定値テストの見直しにあたり、内容を改めて確認しました。すると以下のことが分かりました。
- 設定値テストできる状況に至るまでの準備に時間がかかる
- 報酬獲得などにはランダム要素があり1項目の消化に時間がかかる
このことから、設定値テストの作業手順を見直すことで、これらの時間の削減につながるのではないか、と考えました。
削減策の検討と課題
担当タイトルでは、従来の設定値テストは、端末にインストールされた開発版アプリを用いてテスト作業をしていましたが、これには時間がかかります。そこで、実機を用いないでテストができないかと検討を開始しました。
その際課題として上がったのは以下の3つです。
- 設定値を実機を用いず見る方法はあるのか
- 新しい方法にテスターが対応できるか
- 実機を用いないことで漏れる不具合はないか
課題の解決
1. 設定値を実機を用いず見る方法はあるのか
まず開発チームに問合せをしましたが、当時担当タイトルでは設定値を直接閲覧する方法が少なく、準備に時間がかかることが分かりました。
そこで、アップロード直前の設定値を対象とすることで直接テストするのと同等の効果を得られないかと考えました。定常施策なので、設定値のアップロードや、アプリとサーバー間の設定値のやり取りには問題がないと想定できたからです。開発チームのエンジニアとも検討を重ね、過去の不具合や変更点を確認し、アップロード直前の設定値をテストすることで代替することにしました。
2. 新しい方法にテスターが対応できるか
代替するにしてもテストが難しい設定値ではかえってリスクの元になります。
調査を進めた所、アップロード直前の設定値は複数のExcelファイルで構成されていることが分かりました。そのファイルの意味合いや、どのファイルのどこに変更が加わったのかといった情報が必要になることも分かりました。
そこで、開発チームに協力を要請し、仕様書上に各ファイルの役割と変更点の記載をしてもらいました。この対応で、テスト対象の絞り込みを実施してテストが可能となりました。
3. 実機を用いないことで漏れる不具合はないか
この懸念は、実機を用いないテストで取り除くことは難しい認識でした。そこで、あえて一部分に実機を用いたテストを残すことでリスク回避をすることとしました。
どういった項目を実機テストとして残すのかを開発チームと相談しました。相談の上で懸念として上げられたのは、端末上での表示崩れと新しい報酬等を追加した場合の不具合発生でした。そこで、以下のルールを設定し運用することしました。
- 新しい仕組みの報酬等設定値に大きな変更が加わった箇所は、実機でもテストする
- 変更がない場合でも設定値が正しく反映されていることを確認するため、一部は実機でのテストを残す
また、定常施策に大きな改修が加わるなどして、設定値に関連するシステムに変更が入った場合も実機確認してリスクを回避することにしました。
削減効果の予測
既存の項目を設定値テストに置き換えた場合の効果を見積もった所、テスト工数では定常施策平均30%程の削減が見込めました。
改善策の開始
全体としての動き
各チームでの対応を取り決め、実際の運用を開始しました。しかし、最初は慣れない対応のため、双方で対応の遅延や漏れが発生しました。特に「変更箇所の共有漏れ」や「ファイル共有方法が担当者によって異なること」が課題となりました。
前者は仕様書への記載漏れでしたので、QAチームから依頼をし解決しました。後者は、開発チーム内でどのファイルを共有すればいいのかがいまいち周知されていない、とりあえず全ファイル共有する、といった事象が発生しました。
そこで、共有するファイルの内容と、検証で必要なファイルを今一度精査しました。定常施策なので必要な設定値のセットが変化することはほぼないです。なので、改めて施策毎に精査の上どのファイルが必要なのかを絞り込み、共有作業の簡略化に務めました。
QAチーム側での準備
開発チームとの認識合わせができたので、QA側での準備についても開始しました。主に対応したことは以下のとおりです。
テストケースの改修
従来と異なるテスト手順になるため、テストケースの手順記載を変更しました。手順以外は変更がないため、流用しています。
設定値テストの範囲指定
「手順変更の対象かと思ったら違った」「変更対象だったのに漏れた」ということがないように、どの施策のどのテスト項目に影響するのかをまとめました。テストケースから中項目程度までを抜け出し、どの項目が従来どおり実機か、どの項目が新しい検証方法かを見やすくしました。また、開発チームと認識ずれを防ぐため、変更箇所のすり合わせも実施しました。
結果と振り返り
結果
初期こそいくつか課題が発生したものの、結果として当初見込んでいた平均30%前後の削減は無事達成できました。導入した施策において、リリース後の不具合検知漏れも特にありませんでした。
振り返り
今回の対応では開発チームとの協力が不可欠でした。もちろん、デバッグツール等で実際のデータをテスト対象にできる方が好ましいと思います。それも含めると、今回の良かった点、改善点は以下の様に考えました。
良かった点
- 開発チームと逐次連携をして改善を進行したという実績作りができた
- 安全にテスト方法の変更と工数削減を達成できた
改善点
- 逼迫以前から今回の様な対応を検討し、デバッグツールなどを用意できていればもう少し円滑に移行ができたと考える
- 導入期間が短期で、関係者の負荷がかなり高かったためもう少しゆとりあるスケジュールにできればよかった
まとめ
設定値のテスト自体は目新しくない上、タイトルによってはデバッグツールを用いてもう少し効率よく確認する方法を確立している場合もあると思います。今回は新しく導入する場合、どういった課題や解決策があるのかを記録し、同じ様な課題に直面している方の助けになればと思いこの記事を執筆しました。
実際、安直に導入するにはリスクがあり、課題もたくさんあります。また開発チームの協力も不可欠です。しかし、うまいこと導入ができた時の効果は非常に大きいです。逼迫しているテスト工数を何とかしたい、という方は、方法のひとつとしてご活用くださいませ。