認証グループのストーリーチケットに対するテストフローの更なる改善

こんにちは。認証グループのいまひろです。

前回、チーム内のテスト管理のフロー改善についてという記事で、認証グループ内でのJiraのストーリーチケットに対するテストフロー改善についてお話しさせていただきました。

簡単にまとめると、認証グループのストーリーチケットに対するテストは、前回執筆時点で下記のようなフローになっていました。

Gherkin記法でテストを作成
GitHubのプルリクエストのレビューを経てTestRailのテストケースを自動作成
Jiraの拡張アプリでJiraとTestRailのTest Runとを紐付け
テストを実施しTestRail上で結果を入力
Jira上でテスト実施の進捗を確認

今回、上記フローを更に改善し、Jira上で完結できることを増やすことができましたので、それについてお話しさせていただきます。

前回フローに至るまで

実は、認証グループのストーリーチケットに対するテストについては、前回フローに至るまで、下記の3つのステップを踏んでいました。

Step 1. ストーリーチケットに対してTestRailを利用して受け入れテストを行うという意思決定

Step 2. Jira上でテスト実施の進捗を確認できるJiraの拡張アプリTestRail Extension for Jiraの導入

Step 3. Gherkin記法のファイルからTestRailのテストケースを作成する仕組みの導入

各ステップでの課題と改善点

Step 1のみの運用では、TestRailのTest Runの実施結果がJiraと連動していないため、Test Runが全てパスしていないにも関わらず、Jiraのストーリーチケットが完了してしまうという事例が散発するという課題がありました。

Step 2でJiraの拡張アプリを導入することにより、TestRailのTest Runの実施結果がJira上で参照できるようになりました。またJiraのワークフローで強制することにより、テストが完了していない状態でチケットを完了することができないようになりました。

そして、Step 3でテスト作成がTestRailからGherkin記法でのテスト記述起点に移行されることにより、テスト作成時に生成AIによる補完を受けることができるようになり、属人化していたテストの粒度やフォーマットが安定することになりました。

さらに、Gherkin記法のテストファイルをGitHubで管理することで、必ずレビューのフェーズを挟むことができ、ストーリーチケットに対して、実装に着手する前に、複数の視座で仕様を抜け漏れ等を事前にチェックすることができるようになりました。

新しいフローの導入

課題を解決するために新しいステップを実施していったのですが、Step 3の時点で全体を振り返ってみると、認証グループのストーリーチケットに対するテストという観点においては、冗長なフローがあることに気づきました。

これまでテストケースはTestRailがマスター情報を持っていたのですが、Step 3の実施の結果、GitHubで管理されているGherkin記法のテストファイル群がテストケースのマスターになり、TestRail側はそれを同期するだけの位置付けに変化していました。

また、認証グループではストーリーチケット単位でテストを作成しています。そのため、基本的にテストの再利用やリグレッション的にテストを回す運用は行なっておらず、TestRailのテストケースとTest Runのような再利用を前提とした構成は必ずしも必要ではありませんでした。

現状としては、テスト実施の結果入力のためにTestRailを利用しているような状態で、高機能なTestRailの機能を十全に使いこなしているような状態ではありませんでした。

そこで、Step 4として、下記を実施しました。

Step 4. Jira上でGherkinフォーマットのファイルを読み込みテスト実施を記録できるJiraの拡張アプリAcceptance Test Management for Jiraの導入

これにより、認証グループのストーリーチケットに対するテストは、TestRailを利用しない下記のような新しいフローになりました。

Gherkin記法でテストを作成
GitHubのプルリクエストのレビュー
Jiraの拡張アプリでGitHub上のテストケースをインポート
テストを実施しJira上で結果を入力
Jira上でテスト実施の進捗を確認

新しいフローのメリット・デメリット

メリット

やはりテストの実施結果の入力をJira上で行うことができるようになった点が大きいかと思います。

認証グループでは、テスト以外にもストーリーチケット上で他のチェックリストも管理しているため、他のアプリに移動せずにJira上で完結できるのはありがたいです。

デメリット

TestRailの高機能な部分が利用できなくなることで、例えば、テスト結果のエビデンスを画像で貼る場合などに、Jiraのコメント欄に貼り付けてその旨を記述するような運用に変更する必要がありました。

ただ、それ以外の高機能な部分は、そもそも認証グループのストーリーチケットに対するテストとしてはオーバースペック気味であったため、運用に支障は出ていない感じです。

まとめ

認証グループでは、現状、開発メンバーがストーリーチケットの完了条件を満たすテストを作成していますが、Gherkin記法であれば、本来通り、プロダクトオーナー側で、完了条件としての受け入れテストを作成してもらうことも可能かと思います。

Gherkin記法であれば、実装やテストの自動化等でも活用しやすく、ATDD（受け入れテスト駆動開発）やBDD（振る舞い駆動開発）をより進めていくためにも、Jiraのストーリーチケットに対して、最初にGherkin記法のテスト作成から始めるフローは良いのではないかと思いました。

※ Gherkinについての補足

GherkinはGiven-When-Thenというシンプルな自然言語を使った構文で記述するため、技術的な知識がなくてもテスト内容を理解しやすく、開発者と非技術者が共通の言語でテストについて議論できるため、要件のすり合わせがスムーズに行えます。

また、Gherkinはビジネスロジックに焦点を当てた記述が得意であり、システムが満たすべきビジネス要件を直接表現することができます。

さらに、Gherkinの構造化された記述方式により、テストケースが読みやすく、テストの意図を明確にすることができます。

Gherkinを用いることで、テストファーストな開発を促進することができ、品質に対する意識をチーム全体に浸透させることが期待できます。

kubell Creator's Note

ビジネスチャット「Chatwork」のエンジニアのブログです。