この記事は、CYBOZU SUMMER BLOG FES '25の記事です。
目次
- はじめに
- kintoneの自動テストが抱える課題
- チーム内でのテスト改善への取り組み
- テストピラミッドによるテスト戦略の策定
- ガイドラインに基づくテスト設計と実装
- ガイドライン策定後の変化
- 今後の課題
- 終わりに
はじめに
こんにちは、kintone開発の堀越です。システム管理画面や外部連携の機能開発を担当しています。
kintone開発チームでは担当する機能毎にサブチームを作り、それぞれ独自で新規機能開発や改善活動を行っています。
この記事では、私たちのサブチームで取り組んだテストガイドライン作成と、実際の改善効果についてご紹介します。
kintoneの自動テストが抱える課題
kintoneチームでは、リリース当初より機能開発時に自動化されたリグレッションテストを追加しています。
これまで、Seleniumを用いて実際の画面操作を模擬するUIテストが追加されることが多くありました。しかし、年月を経るにつれてその数は増大し、現在では数千ケースに及んでいます。UIの操作を行うこともあり、不安定さやその実行時間も課題となっていました。
こういった状況を改善するための活動は過去に何度か行われており、新規で追加されるE2E-uiテストの数は減少に転じています。しかし、既に存在しているものについては多くが手つかずのまま残っていました。
チーム内でのテスト改善への取り組み
前述のような経緯を踏まえて、私の所属するチームではUIを用いたテストの削減ができないか、という話題が上がりました。
現在、フロントエンドの刷新によるテスタビリティの向上や、サーバーサイド・テストコードの機能断面での分割が進んだことで、実装面における懸念は大きく減少しています。
blog.cybozu.io
blog.cybozu.io
そこで、チームの中からメンバーをアサインし、集中してUIテストの削減を行っていくことになりました。
テストピラミッドによるテスト戦略の策定
テストの構成を変更するにあたって、テスト種類とそのテストのカバー範囲についてガイドライン化するための議論を行いました。
今回議論のベースとしたのはテストピラミッドの考え方です。
まず、チーム内で実装・管理しているテストの種類を洗い出し、各テストの役割について共通認識をまとめました。まとめた結果が以下の表です。
| 種類 | テスト範囲 | 役割・想定場面 |
|---|---|---|
| E2E-ui | Backend＋Frontend | 1. ビジネス的な要求度が高い主要機能のハッピーパスの疎通検証 2. サイボウズ内の他サービスとの連携テストなど |
| E2E-api | Backend | 1. RESTAPI、サービス内部のAPIの振る舞いの正しさを検証 2. 入力値の網羅やバリデーションなど |
| Integration | Backend | 1. 実装されているServiceレイヤーやDBを結合したテスト |
| Frontend | 1. フロントエンドのコンポーネントを結合した状態のテスト 2. ユーザー操作によるコンポーネントの振る舞いなど |
|
| Unit | Backend | 1. クラスやメソッドのロジックが正しく動作しているかどうかを検証 |
| Frontend | 1. 単一のコンポーネントやロジックなどが正しく表示・操作できるかを確認する | |
| VRT | Frontend | 1. レイアウトが崩れていないかを確認する |
この分類を元に、チームの状況に合わせた以下のようなテストピラミッドを作成しました。
実行コストに応じてテストケース数を調整し、実行時間の長いE2Eテストを最小限に抑え、実行速度の早いUnitテストを最大の割合とする構成にしています。
ガイドラインに基づくテスト設計と実装
ここまでの活動で、開発者とQAの持つ自動テストの分類や責務についての認識が揃いました。次に、実際にUIを用いたテストの分解を進めていきました。
まず、QAが対象の機能について既存のテストケースなどを参考にしつつ、改めて自動テストで担保したい観点を整理しました。この際、UIテストでカバーしていた機能要件を、より下位レイヤーのテストで代替できないかを検討しました。
整理された観点を元に開発者が、実装や依存関係などを調査して適切な分類となっているかを確認しました。
整理されたテストケースに合わせて自動テストを追加し、既存テストを削除していったのですが、中には実装中にテストレイヤーが正しいか迷うものも出ました。しかし、ガイドラインで共通の認識と言葉を持っていることで、スムーズに再分類などの判断が進められました。
ガイドライン策定後の変化
ガイドライン策定後にいくつかの機能において改善を実施し、以下のような効果が得られました。
- UIテストの削減: 94件 → 52件（約45%削減）
- テスト実行時間の短縮: 約5分短縮
- 不安定なテストの削減: 数十件のUI操作起因の不安定テストを削除
普段の機能開発においてもガイドラインが参照され、より小さい分類での自動テストを選択されることが増えています。新機能の開発時には、まず単体テストや統合テストでカバーできる範囲を検討し、UIテストは必ず担保したいハッピーパスなどに対するテスト手段として位置づけるようになりました。
また、副次的な効果ではあるのですが、実装スコープやテスト対象が明確になったこともあり、QAが自律的にテストの実装や修正を進められる状態になりました。
今後の課題
UIの操作で発生するAPIリクエストを叩くという点で移行後のテストケースの作成が容易だったこともあり、バックエンドに関わる多くのテストケースをE2E-apiに移行しています。これによって、フロントエンドとバックエンドで確認するべきテストをそれぞれ分離することができました。
しかしE2E-apiはE2E-uiと比較して軽量かつ安定性も向上するものの、実行時間は引き続き長く、実行環境のリソースも多く必要とします。
今後はバックエンドのテストをさらに小さい単位に分離し、開発者が素早いフィードバックを得られる環境を整えていきたいと考えています。以下のような取り組みも参考にしながら、改善を進めていく予定です。
終わりに
チームで行った自動テストガイドラインの策定と、その実践により得られた効果についてご紹介しました。現在は一部の機能への導入となっていますが、ポジティブな効果を実感できています。ガイドラインやテストピラミッドを協力して作成することで、開発者とQAでの共通認識や共通言語などが生まれ、既存テストの改善や機能開発での判断基準の明確化などのメリットが得られました。
