こんにちは、品質向上の木下です。
この記事では、弊社でテスト自動化が根付くまでの、苦難な道のりをお伝えします。今後、テスト自動化を目指される方のための参考となれば幸いです。
品質向上チームが主管するテストとその課題
前提情報
まずは、本題に入る前に、弊社でのテスト工程での確認単位や確認観点について整理します。弊社の定義は、一般的なテストと定義が厳密には違うので、ご留意をお願いします。
弊社の品質向上チーム(QAチーム)は、上記組み合わせの中で、以下のテスト実施及び責任範囲[1]をもっています。
テスト責任範囲
品質向上が実施しているテスト
開発サイクル
弊社では、以下の開発サイクルがあります。
- 小規模案件
- 開発サイクルは、2週間単位である
- 特徴として、サイクルが崩れることがほぼなし
- 中・大規模案件
- 開発サイクルは、期間が案件ごとに流動的で、1週間単位から数ヶ月単位がある
- 特徴として、複数案件が連続して発生する場合もあれば、案件が一定期間発生しない場合もあり
品質向上チームでは、開発サイクルに合わせて、ITのシステム間の機能やレイアウト等を確認するテストケースをテンプレートとして作成・更新しています。また、STのリグレッションテストについても、同様にテストケースを作成・更新しています。
ITにおけるシステム間結合のテスト
システム間結合のテストでは、案件で変更が入る箇所について、正常系だけでなく、準正常系、異常系について、初期値や組み合わせ、データ正誤、バリデーション等を細かく確認します。案件が発生するたびに、サービスサイトへの仕様変更が入ります。弊社では、上述した通り、開発サイクルが短い案件も多くあるため、手動でテストケースを作成し手動で確認する手法が効率良くなります。
STにおけるリグレッションテスト
リグレッションテストでは、全体の機能について、一つの流れの正常系を通してデグレードが発生していないかを確認します。リグレッションテストは、大きな粒度でテストケースを作成しているため、開発サイクルによる仕様変更でテストケースに変更が発生する頻度が少ないです。そのため、弊社にとって機械的に繰り返し実行できる手法が効率良くなります。
チームの課題
品質向上チームでは、チーム発足以来、IT・ST・UATの多くのテストにおいて直接手を動かして確認していました。しかし、会社全体の規模が大きくになるにつれ、案件の規模や数が増大した結果、品質向上チームで対応できる余裕に限界を迎えつつありました。
そこで、テストの品質を維持したまま、チーム全体の工数を削減する手法を模索しました。
弊社でのITのテストは、完全オーダーメイドで作成し確認していたため、アウトソーシングやテスト自動化に向いていません。一方、STのリグレッションテストは、テストケースに大きな変更が発生する頻度もなく、繰り返し安定的に動作することを確認できれば良いため、アウトソーシングやテスト自動化への置き換えが適当でした。
当初は、テスト自動化ツールを調査・研究する余裕がなく、STのリグレッションテストをアウトソーシングで外部の企業の人的リソースを利用して対応していました。しかし品質向上チームでの予算が、弊社と提携している企業の数すべてを一度に実行するだけの余裕がなく、STでの品質維持が困難な状況でした。
そのため、サービスサイトの数に応じて予算や工数が増大しない、テスト自動化への移行を模索することとなりました。
どのテスト自動化ツールを採択すべきか
最初は無償で利用できるテスト自動化ツールを試す
2019年1月に、弊社で最初のテスト自動化ツールの検証が始まりました。無償のテスト自動化ツールには、以下にある代表的なツール[2]があります。
-
Selenium
- 2004年に開発が始まり、2010年に正式リリースされたオープンソース
- ChromiumやWebKit、Firefoxを含む、レンダリングエンジンを搭載したブラウザをサポート
- WindowsやLinux、MacOS上で動作する
- JavaやPython、C#、Ruby、JavaScript、Kotlinでテストコードを記述できる
-
Cypress
- 2017年に、開発・正式リリースされたオープンソース
- ChromiumやWebKit、Firefoxを含む、レンダリングエンジンを搭載したブラウザをサポート
- WindowsやLinux、MacOS上で動作する
- JavaScriptでテストコードを記述できる
-
Puppeteer
- 2018年に、Googleによって開発・正式リリースされたオープンソースのNode.jsライブラリ
- Chromiumを含む、レンダリングエンジンを搭載したブラウザをサポート
- WindowsやLinux、MacOS上で動作する
- ChromeのDevTools Protocolを制御できるAPIを提供する
-
Playwright
- 2020年に、Microsoftによって開発・正式リリースされたオープンソースフレームワーク
- ChromiumやWebKit、Firefoxを含む、レンダリングエンジンを搭載したブラウザをサポート
- WindowsやLinux、MacOS上で動作する
- TypeScriptやJavaScript、Python、.NET、Javaでテストコードを記述できる
弊社では、以下の目的を達成するために、技術的に一番枯れているSeleniumの検証を行いました。
- テストを自動化し、品質向上や開発効率の向上に寄与する
- Seleniumスクリプトによって、まずは「正常系が問題なく動作する」ことを保証できる
- チームの工数削減により、開発のより上流から品質向上のためのテスト計画や開発設計が行える
- 複数の提携企業向けのサービスサイトに対して同時にテスト実行することで、仕様変更の反映漏れを事前検知できる
- 品質向上チームでの予算を別の領域に利用できる
- アウトソーシングしている費用を、新技術やサービスの研究などへ充てがえる
- 技術を持った新規メンバーへの採用予算を確保できる
しかしながら、以下の理由から、Seleniumでのテスト自動化は失敗となりました。
- 正常系のケースを安定して、テストを終えられない
- テスト環境問題やコーディング問題による、テスト失敗が多く、Seleniumによるテスト結果に対する信頼を得られない
- 参考記事：How To Find Flaky Selenium Test Suite
- サービスサイトへの仕様変更に伴う、スクリプトの修正が開発サイクルに追いつかない
- サービスサイトの開発が完了しない限り、スクリプトの修正を始められない
- スクリプトの修正が完了する頃には、テスト実施期間が終わっている
- Seleniumに精通した技術者が必要である
- チームメンバー全員が全員、開発経験を有してはいないため、対応できるメンバーが限られる
他のテスト自動化ツールにおいても、上記課題の一部は解決が見込まれないと判断し、他のツールの検証を中断しました。そこで、有償で利用できるテスト自動化ツールの検討となりました。
次に有償で利用できるテスト自動化ツールを試す
2021年3月に、弊社で2回目のテスト自動化ツールの検証が始まりました。有償のテスト自動化ツールには、以下の候補がありました。
上記の中から、日本語サポートがあり、Seleniumを採用していない、「Autify」と「Magic Pod」に絞って検証[3]を行いました。
- テスト結果またはテスト一括実行結果より内容を確認
| 製品 | Autify (※Advanceプランを参照) | Magic Pod (※スタンダードプランを参照) |
|---|---|---|
| 価格 | お問い合わせ | ¥43,780/月（税込）〜¥54,780/月（税込） |
| セキュリティ・ポリシー | 情報セキュリティ方針 |
セキュリティ概要 プライバシーポリシー |
| 作成可能なテストケース数 | 無制限 | 100件 |
| 月間テスト実行回数 | 1000回〜 | 無制限 |
| 作成可能なユーザー数 | 無制限 | 無制限 |
| ユーザー固定IPアドレス | あり | なし (エンタープライズプランのみ) |
| テストケース作成手順 | 1. ブラウザ上で、Autify Recorderを操作して、テストシナリオの雛形を作成しクラウド上に保存 2. 不要なステップを削除、または足りないステップをAutify Recorderからリプレイ機能を利用して追加 3. 条件を設定 |
1. クラウド上でブラウザを起動 2. 表示された要素をエディターにドラッグ・アンド・ドロップしてステップを作成 3. 条件を設定 |
| テストケース作成での特徴 | ・ CSV形式で複数データを投入し、一括検証できる ・ ステップの一部をグループ化することで、他のテストシナリオに共有できるステップを生成できる ・ テストシナリオの途中で、JavaScriptを記述してデータの生成や検証ができる |
・ CSV形式で複数データを投入し、一括検証できる ・ ステップの一部をグループ化することで、他のテストシナリオに共有できるステップを生成できる ・ 独自の命令文で、条件分岐や変数の保存や参照ができる |
| テストの実行手順 | 1. テストシナリオもしくはテストプランを選択 2. 実行ボタンを押下 3. テスト結果より内容を確認 |
1. テストケースもしくはテスト一括実行を選択 2. 実行ボタンを押下 3. テスト結果またはテスト一括実行結果より内容を確認 |
| テスト実行後、参照できる項目 | ・ 実行日時 ・ 所要時間 ・ テスト結果 (成功/失敗/警告/スキップ) ・ スクリーンショット画像 |
・ 実行日時 ・ 所要時間 ・ テスト結果 (成功/失敗/要確認/中止) ・ スクリーンショット画像 ・ 実行ログ (Seleniumログ) |
弊社では、検証から総合的に判断した結果、以下の観点[4]から「Autify」を採用しました。
- 複数のサービスサイトに対して、同時に並列で自動テストを実行できる
- 提携している企業が多い弊社にとって、実行工数を削減できる
- 非技術者がテストシナリオの作成・更新が行える
- ブラウザでの操作だけでテストシナリオを作成できる
- JavaScriptを直接記述できる
- テスト実行ツールから外部のAPIを参照できる
- テスト実行ツールに用意されていない機能をコーディングすることで、実施したいことを代替的に実現できる
採用すべきテスト自動化ツールを決定した、その後
ロードマップ
テスト自動化ツール採択後、以下の時系列の通り、リグレッションテストをアウトソーシングしていた会社から「Autify」に完全に置き換えることとなりました。
テスト自動化ツールにより得られた成果
弊社では、リグレッションテストにおいて、アウトソーシングによる手動テストからテスト自動化ツールに置き換わったことで、以下の成果を得られました。
- 予算と実績
- 32.4%の費用削減に成功
- 月間でテスト実行可能な回数
- 1回から、リリース対象のモジュールすべてに改善
- 一度にテスト可能なサービスサイトの数
- 1件から、全件すべてに改善
- 不具合検出
- 0件から、1件以上検出されるよう改善[5]
- 人では見ても違いが分からない、差異の検出も可能に
- テストに関わる工数
- 変わらず
- しかし、テストケースの最新化や深化が可能に
以上の結果から、弊社にとって、テスト自動化ツールの採択は良好な結果となりました。
さいごに
最初の構想から実現まで、実に3年以上かかりました。
実現に長期間を要した理由として、普段の品質向上によるテストの品質を落とさず、テスト自動化ツールを検証する工数を確保することに時間がかかったことがあります。またテスト自動化ツールを採用することによって、相応の検証・対応工数がかかるにも関わらず、置き換えが完遂するまで成果が見えづらい点も非常に辛く感じた点でした。
しかし今回の試みによって、弊社での品質向上チームの機動性があがり、緊急案件に対する即応性も高まりました。結果、複数同時に案件が走った場合でも、リグレッションテストは対応できる、最良の結果となりました。
テスト自動化ツールをご利用されていないのであれば、ぜひ弊社での経験を参考に、テスト自動化ツールを試してみてください。
📣ウェルスナビは一緒に働く仲間を募集しています📣
著者プロフィール
木下智弘(きのした ともひろ)
2015年10月にウェルスナビに、エンジニアとして入社。
プライベートでは、Google Cloudを好んで利用しています。
Goのシンプルな考えが好きです。
Discussion