この記事は、CYBOZU SUMMER BLOG FES '25の記事です。
こんにちは。kintone拡張基盤チームの massan です。今回は、cli-kintoneの自動テストで使用しているテストツールおよびレポートツールと、それらの運用中に加えた改善の話をご紹介します。
拡張基盤チームとテスト対象の紹介
拡張基盤チームではkintoneをコマンドライン操作できるcli-kintoneというツールをOSS公開しています。
QAと開発者が連携しやすいテストフレームワーク
cli-kintoneではE2Eテストの実装にCucumber、テストレポートにAllure reportを使用しています。いずれも開発メンバーが構築・整備してくれました（感謝）。
- Cucumber：featureファイルとstepsファイルでテストを書く自動化ツール
- featureファイル：自然言語のGherkin形式（Given-When-Thenで記述するテストシナリオの書式）でテストシナリオ、テスト手順、確認する期待結果を書く
- stepsファイル：featureファイルの手順に基づいて実装する
- Allure report：テスト結果を視覚的に見やすく表示するレポートツール
- テストケース一覧や最近の実行結果などがまとめて確認できる
- Cucumberのfeatureファイルに書いたテスト手順一つひとつやテストデータ、実行結果がわかるように設定できる
現在のチームではE2Eテストに関してはQAがテストケースを作成し、開発者がテストコードを実装するという運用です。ここでCucumberを使っていると、たとえばテストシナリオをQAがfeatureファイルに書き、開発者がstepsを書く、といった連携ができます。これによってQAがテストシナリオや手順の言い回しに責任とオーナーシップを持ち続けることができ、開発者としてはテストに関する情報がコード内で完結するというメリットがあります。
現在のcli-kintoneのテストレポートはこちら：https://kintone.github.io/cli-kintone/index.html
使用感レポート
テストに関する情報がコード内で完結するありがたさ
- コード内にテストシナリオを残せる
- 詳しい仕様書がないプロダクトでは、これらテストが仕様書と同等の情報源になることも
- シナリオだけでなく、テストデータやテストコード、自然言語のテスト手順もまとめて探せる
- テスト設計までを担っているQAにとっても検索しやすい
- 別途テスト管理ツールをもつ必要性が省ける
- テストケースを一元管理でき、別のツールにまとめたテストケースの情報が実際のコードに比べて古いということが起こらない
テストコードを書いていないQAにとってもレポートが見やすい
- テスト手順や期待結果も確認できるので、実装内容を見たい時以外はレポート上でテストケースを探すのが楽
- ※自動テストが意図した通りに実行されている場合に限る
- 実行に時間がかかるケースや手順なども手軽に把握でき、改善につなげやすい
- cli-kintoneのE2Eテストは現状4ファイル、計130件程度で、後述の改善を経て現在は見やすく収まっている
運用中に行った改善
CucumberとAllure reportの運用中に加えた改善を紹介します。改善といっても大きく工数をとるものではなく、テストシナリオの書き方をシンプルなものに統一したというものです。
テストシナリオ例：コマンドに仕様外の引数を指定するとエラーになることのテスト
改善前：CliKintoneTest-1 Should return the error message when specifying unknown option
改善後：Unknown option
シナリオの書き方変更方針
- 期待結果をシナリオ内に書かない
- テストレポート内での視認性が保てる文字数にする
- なるべく簡潔に
- 確認したい項目の単語をなるべく文頭に
- 統一できる表現は統一して、テストファイル名とテストシナリオを見ればなるべく一意にテストケースが再現できるように
- コマンドに含まれていない、など存在するべき場所/階層が同じならwith/without、権限がない、など内包的な関係ならhas/does not haveをつかう、など
- ※あとでテストケースを見直した際、背景知識を忘れていてもテストの目的を手軽に把握できるようにするため
- テストケースのIDはコード外のテスト管理ツール（kintoneアプリ）で使用していたもので、これまで検索にもテストケース共有にも使っていなかったので削除
英文法にはどうしても未熟さが残りますが、ある程度の質を担保できるよう、改善には日本語スタイルガイド通称緑の本及び、社内の英語スタイルガイドを参考にしました。
改善後のメリット
テストレポートの視認性があがり、多重管理で使っていたkintoneやExcelの利用を廃止し、テストコードとレポートのみでテストを管理できるようになりました。
cli-kintoneのE2Eテストは130件強程度であるのに対し、QAがExcelやkintoneアプリに書いたテストケースをエンジニアがテストコードに書き写す、としていた時期もありコストが高いと感じていました。この改善で管理がシンプルになり手順の最適化ができたように思います。
余談：AIとのテスト設計も捗る
テストに関する情報がコード内でまとめられると、テスト分析やシナリオ、featureファイルの作成もAIにほとんど依頼できます。探究として下記の方法でAIにテストシナリオを作成させ、cli-kintoneのレコード書き出しコマンドに関して現行とほぼ過不足ないテストケースを作成させることができました。
- AIに例としてrecord exportの適当なコマンドを実行させる
- AIにcli-kintoneのrecord exportのヘルプを参照させ、使える引数や機能を認識させる
- AIにE2Eテストのテストケースを洗い出させる
- 手順3のテストケースを人間のQAがレビューする
- （必要であれば）テスト戦略など関連ドキュメントを読み込ませる
- AIにE2Eテストケースのブラッシュアップをさせる
最近ではcursorやClaudeなど高度なAIも開発に利用できるので、cli-kintoneにテストを追加する際は積極的に活用できればと思っています。
終わりに
テストをQAが設計してエンジニアが実装する、というようにテスト追加の工程が1人（または1職能）で完結しないという状況はよくあるのではないでしょうか。自然言語でテストシナリオを残しつつテスト管理をコード内で完結させるのに、CucumberとAllure reportはおすすめです。この記事がご参考になれば幸いです💐
