テスト自動化の進展：DatadogからPlaywrightへの移行（後編）
はじめに
こんにちは。カラクリ株式会社QAチームリーダーの芹沢です。
前回記事の続きを書かせていただきます。
まだご覧になっていない方は、「テスト自動化の進展：DatadogからPlaywrightへの移行（前編）」をお読みいただけたら幸いです。
今回は、Playwright導入時に整理したテスト自動化設計の内容を紹介します。様々な視点を考慮しながら整理を進めたため、色々と書いてしまうかもしれませんがご了承ください。
後編の記事から得られること
Playwrightの特徴
テスト自動化活動設計の事例・工夫
Playwrightについて
Playwrightの特徴を紹介します。Playwrightの試験的導入と評価を進めることで、以下の利点があることがわかりました。
豊富な機能
Playwrightは多様なテストシナリオに対応できる豊富な機能を備えています。これにより、複雑なテストも効果的に実施することが可能です。カスタマイズ性の高さ
テストコードを自由に設計し実行できるため、プロジェクトの特性や要件に合わせた最適なテストを組むことができます。この柔軟性により、堅牢で変更に強いテストスイートを構築できます。安定性
自由度の高いテスト設計が可能なため、予期せぬ状況にも対応しやすく、「テストが失敗しづらい」「失敗しても原因の特定とメンテナンスがしやすい」特性を持っています。これは長期的なメンテナンスコストの削減にもつながります。実際の利用に近いテスト
Playwrightは実際のユーザーの挙動に近い形でテストを実行できます。これにより、「より目的に即した現実的なテスト」が可能となり、実環境での動作をより正確にシミュレートすることができます。
これらの特徴により、Playwrightは品質保証プロセス全体を強化するための戦略的なアセットの１つになると考えました。
テスト自動化プロセス全体の再設計
Playwrightの導入をきっかけに、いきなり手を動かして自動化を進めるのではなく、一度テスト自動化プロセスの全体を整理・再設計してみることにしました。
テストレイヤー・Playwrightの位置づけを整理
テスト自動化を進める上で、まず重要なのはテストの全体像を理解することです。「テスト」と一言で言っても、ソフトウェア開発の各段階で異なる種類のテストが必要となります。この考え方は、ソフトウェア開発のライフサイクルを表す「V字モデル」に反映されています。
V字モデルでは、開発の各フェーズに対応するテストレイヤーが存在し、これらのテストレイヤーを理解することで、効果的なテスト戦略を立てることができます。
テスト自動化も同様に、各テストレイヤーで行うテストに適したツールが存在します。このため、まずはPlaywrightを導入する上で、このツールの位置づけと最適な活用方法を整理しました。V字モデルの考え方を参考に、テストを以下の4つのレイヤーに分けて考えました。各テストレイヤーで使用可能なツールの例も可視化してみました。
この表のとおり、PlaywrightはIT（インテグレーションテスト）の段階で活用することにしました。つまり、ST（システムテスト）に入る前の事前テストとして活用します。この方針により、以下のような利点が期待できます。
コンポーネント間の連携を効率的に検証できる
システムテストの前に多くの問題を早期発見・修正できる
システムテストにかかる時間と労力を削減できる
全体的なテスト品質と効率性の向上が見込める
この位置づけにより、Playwrightの特性を最大限に活かしつつ、テストプロセス全体の最適化を図ることができます。
テストレイヤーに合わせた役割分担
開発チームと相談し、テストレイヤーの分類に基づき、役割分担を以下のように決めました。
開発チームの担当：ST、CT（ユニットテスト、コンポーネントテスト）
開発チームには、個々のコードの正確性とコンポーネントレベルの機能性を確保してもらいます。専門知識を活かし、コードの品質を早期段階から維持することが期待されます。QAチームの担当：IT、ST（インテグレーションテスト、システムテスト）
QAチームは、複数のコンポーネントが連携して動作するインテグレーションテストと、システム全体の機能や性能を検証するシステムテストを担当します。幅広い視点と品質保証の専門性を活かし、プロダクト全体の品質を確保します。
※以降は略語を使わせていただきます。
この役割分担により、各チームの強みを最大限に活用し、効率的かつ効果的なテストプロセスを実現できると考えました。また、開発とQAの間で密接な連携を取ることで、問題の早期発見と迅速な解決が可能になります。これにより、全体的なプロダクト品質の向上につながることを期待し、このようにしています。
テストプロセスの課題と改善策
ここからは、QAチームが担当するSTとITに焦点を当て、ここでの課題と改善策についてお話ししていきます。
STの課題
当社のテストプロセスにおいて、特に課題となっていたのはSTのボリュームが過大になっていることです。これにより、リリース前のQAテストに要する工数が増え続けていました。主な原因は、マニュアルテストのボリュームの増大でした。これを「非効率な状態」と捉えました。この負荷をいかにして軽減できるかを検討する必要がありました。
（イメージ）
改善策
この問題に対処するため、以下のような改善策を講じることにしました。
ITの強化
STとITの両方を担当しつつも、ITの強化に重点を置くことにします。具体的には、STの範囲を見直し、詳細なリグレッションテストをITで実行する方針への転換です。これに伴い、従来マニュアルで行っていたリグレッションテストの自動化を進め、テストツールもDatadogからPlaywrightへ移行を行います。Playwrightへの移行理由はこれまでの説明の通りです。
この戦略転換の背景には、ST固有で検知される問題の希少性もあります。過去に検知した不具合を分析したところ、その大半がSTに限らずITでも検知可能であることが判明しました。この分析結果から、IT段階でPlaywrightを活用した自動テストにより詳細なリグレッションテストを行うことで、多くの問題をより早期に、かつ効率的に検知できると判断しました。STの役割を見直し
STの役割も見直しました。STでは、新規機能追加や既存機能の改修に合わせたテスト設計と実行に今まで以上に注力し、STで行うリグレッションテストは、ユーザーシナリオに即した疎通確認テストを中心に行い、テストのボリュームを最適化します。これにより、テストの効率化と品質保証の両立を実現します。テスト戦略の見直し
早期の品質保証を目指し、開発プロセスの上流でのテスト強化を図ります。詳細は「QAシフトレフトの取り組み」の記事で紹介しています。この取り組みにより、リリース前QAテスト時のテスト設計の負荷軽減と、プロダクトの品質向上を目指します。
このアプローチにより、以下のような効果が見込まれます。
不具合の早期発見
全体的なテスト工数の削減
不具合の混入を未然に防止
このような背景から、Playwrightを活用したテスト自動化を進めています。
Datadogの今後の活用について
現在、Playwrightへの移行を進めていますが、Datadogの利用を止めたわけではありません。Datadogは、その特性を活かした形で今後も継続して利用していく予定です。具体的には、以下のようなケースで活用しています。
STで実施するシナリオテスト
疎通確認のための自動テスト
本番環境での動作確認テスト
この理由は、主に以下の点にあります。
簡易なテスト構築
複雑な処理を必要としない単純なテストケースであれば、ノーコードで気軽にテストを組むことができます。環境適応性
テスト対象に合わせた環境のセットアップが不要で、様々なテスト環境に対して柔軟にテストを実行できます。低い学習障壁
ツールの基本的な使い方を覚えれば、プログラミングの知識がなくても自動テストを構築できます。これにより、マニュアルテストが専門のメンバーでも自動テストの作成に参加できるようになります。
このように、DatadogとPlaywrightそれぞれの特性を活かし、テストの性質や目的に応じて適切なツールを選択することで、より効率的かつ効果的なテスト体制を構築しています。
まとめ
最後に、これまでのお話の内容を纏めておきます。
Datadogを活用したテスト自動化を実現（前回の記事内容）
テスト自動化の拡大に伴う、有償ツールの課題に直面
課題解決策としてのPlaywrightへの移行を決定
Playwright導入を契機としたテスト自動化プロセス全体の再設計
テストの役割とテスト自動化ツールの使い分けを明確化
現在はPlaywrightへの移行を順次進めている
これらの取り組みを継続的な改善業務として進めてきました。現在も、Playwrightの実装を日々進めている状況です。
プロダクト開発においてQA業務やテストは不可欠なものです。特にアジャイル開発が主流となる中、不具合を早期に検知する仕組みを考えることの重要性はより一層増しています。
一方で、QA業務は時間と労力を要する大変な作業でもあります。開発者にとってはモチベーションを保ちにくい業務です。QAチームの取り組みは、この負荷を軽減し、より効率的なQAプロセスを構築することを目指しています。日々の改善活動を通じて開発をサポートしています。
今回ご紹介した内容は、あくまで当社の背景に即した改善活動の一例です。共感いただけた部分もあれば、違和感を覚えた点もあったかもしれません。
同様の課題に直面されている方々には、今回の記事を参考に、自社の状況に合わせた改善を検討してみてはいかがでしょうか。少しでも皆様の参考になれば幸いです。
また、本記事ではテスト自動化に焦点を当てていますが、マニュアルテストも不可欠で重要なテストプロセスです。QAチームの取り組みとして、自動化できるものは可能な限り自動化し、その結果としてマニュアルでしか行えない複雑で創造的なテストに、時間と労力を割けるようになることを目指しています。このバランスの取れたアプローチにより、効率性の向上と深度のあるテストの実現が可能となり、さらなる品質向上につながると確信しています。
最後までお読みいただき、ありがとうございました。