この記事は techtekt アドベントカレンダー2021 の 10日目の記事です。
テクノロジー本部 エンジニアリング統括部 サービス開発部でエンジニアをしている maoki です。
今年、担当していたプロジェクトでテスト管理ツールであるQaseを導入した話を紹介します。
こんな人に見てほしい
- プロジェクトの品質検証プロセスを改善したい
- 最近障害が多発している
- テスト管理ツールに興味がある
背景
当時担当していたプロジェクトでは、2週間1スプリントで開発を行い、その後本番リリースをするスケジュールを採用していました。
初期リリースや大きな変更を含むリリースの場合は品質検証を外注しますが、日々のリリースでは品質検証に関しても開発チームで担当する必要がありました。
開発プロセス
開発の流れとしては、タスクの担当者がコードを変更し、セルフテストが完了したらPR（プルリクエスト）を起票し、レビュアーにレビューを依頼します。
レビュアーはコードレビューを実施した後、動作検証します。コードレビューや動作検証の時点で問題が見つかった場合は、PRにコメントを書いて修正をリクエストします。
問題が解消するまでこのサイクルを繰り返した後、PRを承認します。
開発者は承認を受けて、PRをマージします。
スプリント＆デプロイスケジュール
上述の通り、開発については2週間を1スプリントとして進めます。スプリント最終日にスプリントレビューを実施し、無事ステークホルダーの了承が得られたら翌日にステージング環境へのデプロイを実施します。
1週間、ステージング環境上でのステークホルダー側での最終機能確認を経て、問題なければ本番環境にデプロイされます。
問題点
上記の通り、コード変更があった周辺の機能については、レビュアーの動作検証によってテストが実施されます。
しかし、共通コンポーネントを編集した場合など、副作用が広範囲にわたる場合、思わぬところにバグが発生することがあります。
本番環境で障害が発生すると、お客様にご迷惑をおかけすることになりますし、hotfixリリースなど予定にない作業が発生して開発プロセスへも影響があります。
そこで、これまでのPRベースの動作検証に加え、必要に応じて回帰テストを実施できる状態を担保したいと考えました。
プロジェクトの状況を確認すると、回帰テストを実行するためにまず以下の問題を解決しないといけないことがわかりました。
- テストケースの不在
- テスト実行結果ログの不在
テスト管理ツール調査検討
テストケース管理やテスト実行結果ログの管理ツールとして、Excelはポピュラーです。
ただ今回に関しては、すでに他のプロジェクトでテスト管理についてExcelの使用実績があり、部として新しい知見を得たいという目的もあって、テスト管理ツールの新規導入を検討することとしました。
ツール選定要件
ツール選定にあたっての、必須の要件は以下になります。
- テストケースが作成・管理できる
- そのテストケースが「いつ」「誰によって」実行されたかの記録を残せる
また、必須ではないものの、以下のような機能がサポートされているとより望ましいと考えました。
- テストケースをCSVなどからインポートできる
- テストケースをCSVなどへエクスポートできる
- Github と連携できる
- SSO でログインできる
ツール選定結果
Qaseを導入することに決定しました。
TestRailやTestLinkなどの他ツールも検討対象でしたが、無償で利用できるのは評価版のみであったり、新しい情報に乏しかったりしたため、最終的には除外しました。
Qaseは無償で3ユーザーまで主要な機能が使え、上にあげた要件をすべて満たしていると考えられたのが一番大きな選定理由です。プロジェクトの規模的に無償版でスタートすることが可能だったため、試用からはじめることとしました。
ただ、新進のサービスであることから品質面や日本語テキストの利用などに問題が発生する可能性も考えられました。もしQaseの機能に問題が見つかった場合や、要件を満たさないと判明した場合、作成したテストケースをエクスポートし、Excel管理へと切り替えることも考慮した上での判断でした。
Qase試用結果
Qaseを使用してテストケースを作成、大きな機能変更があったタイミングで回帰テストを実行するところまでを実施しました。
良かったこと
Test Case/Test Suite作成の操作性は良好
- 日本語入力に関して特に問題なし
- 複数のTest Caseを一括で別のTest Suiteへ移動できる
- 複数のTest Caseのフィールド(Severityなど)を一括で変更できる
任意のTest Case/Test SuiteのセットをTest Planとして定義できる
すべてのテストケース、正常系のテストケースのみ、など任意の切り口でTest Planを作成できる
Test Plan単位でTest Runを実行できる
正常系Test Planを前回実行したのはいつか、などが明確になる
課題を感じたところ
- 製品内で使用されている用語が変更された場合などに一括で置換する方法がない
- Shared Stepを使う選択肢もある
- QaseからGithubに起票したissueに関しては、連携を設定した人が起票者になる
- できれば問題を発見した人を起票者にしたい
- 領収書の宛名の件でサポートに連絡したらしばらく返事が来なかった
- 催促したら返事が来て手続きに時間がかかっていたとのこと、総じて親切ではあった
- 最上位プランでないとSSOが使えない(その後課金プランには変更があった模様)
まとめ
上記の結果を踏まえ、Qaseには今回の要件を満たす十分な機能があり、品質面も特に問題ないことがわかりました。
「回帰テストを実施し、その実行結果ログを残すための環境を整える」という目標を達成するにあたって、開発メンバーがテストケースの作成およびテストの実行も担当しました。これにより、メンバーの品質検証に関してのスキルの棚卸しおよび意識の向上を図れたことも大きな成果でした。
以上から、部としてQaseの正規版を購入し、必要に応じて各プロジェクトに導入していくことが決定しました。他プロジェクトでも品質検証は外部へ発注している場合がほとんどなのですが、そもそも外注が難しい機能（管理画面など）を内部テストする場合などにQaseが有用と判断したためです。
上記の通り、Qaseには不便な部分もあります。今後、新しいテスト管理ツールが出てきた場合は適宜比較検討しつつ、品質検証をどのように開発プロセスの中へ組み込んでいくかを引き続き考えていきたいと思います。
次回予告
明日はm-kaiyaさんの「リモートワークでのお昼ご飯の工夫」です。個人的にも興味のある話題で楽しみです！
maokiさんのプロフィール
エンジニアリング統括部 サービス開発部 第1グループ シニアエンジニア
新卒でIT企業へ入社。コンシューマ開発、金融・保険系プロジェクトへのサービスデリバリーなどを経て、Webアプリケーションフロントエンド開発のリーダーとしてBtoBサービスの開発に携わる。新規サービスの立ち上げとチームビルディングに参画できる機会に魅力を感じて、2020年7月にパーソルキャリア入社。
※2021年12月現在の情報です。
