はじめに
今回は2023年1月に株式会社ビットキーに入社しました、Software QAチーム所属のわんが担当します。
最近はありがたいことで、各プロダクトで新機能の実装が増えております。新機能の検証を従来の検証スケジュールに組み込むと、他の作業が圧迫されることがあり、また工数の不足による検証が不十分になったこともありました。
上記の課題を解決するために、新たな試みとして新機能の実装におけるQA検証を独立したプロジェクトとして取り扱うようにしました。またそれに合わせて、新たにアジャイルテストを取り入れることにし、手法としてはBDD（ビヘイビア駆動開発）を参考にすることにしました。
今回はそもそもBDDとは何かについて説明し、合わせてBitkeyではどのようにしてアジャイルテストを行っているのかについて紹介したいと思います。
対象読者
- アジャイル開発におけるQAのやり方を改善したい方
- アジャイルテストを経験したことのないQAチームに新たな知識を持たせたい方
BDDの概念
BDDとは
BDD（ビヘイビア駆動開発）はBehavior Driven Developmentの略であり、ソフトウェア開発の手法の一つでテスト駆動開発（TDD）の亜種とも言えます。BDDの最大の特徴は、「ユーザーの振る舞い（ビヘイビア）」に注目した開発であることです。
BDDでは、テスト自体がシステムの振る舞いを明文化したものとなり、開発者だけでなく、非技術者もこれを読むことによってシステムの振る舞いを理解することができます。したがって、BDDはコミュニケーションツールとしての役割も果たします。
また、BDDでは「Gherkin記法」がよく用いられます。これは自然言語に近い形でシステムの振る舞いやテストを記述するための言語で、非技術者でも理解しやすいという特徴があります。
Bitkeyでは
システムの振る舞いをビジネスサイドにも理解できるようBDDを参考にしながら、アジャイルテストを取り入れることにしています。
例えば、認識齟齬と設計漏れを防ぐために、定期的にビジネス要件の認識あわせ会議を開催しています。また、QAがビジネス要件を満たすシナリオを作成します。さらに、作成したシナリオ中のクリティカルパスを特定し、それを優先的に実装するよう提案しています。
やったこと
①プロジェクトのキックオフ時からQAがプロジェクトに参加
これにより、QAチームは仕様に対する理解を早期に得ることができ、仕様の考慮漏れがあっても早期に対応することが可能となります。
従来のアジャイル開発に合わせたQAでは、テスト設計は開発がある程度進行した時点で開始します。その時点で仕様の考慮漏れをQAチームが発見した場合、開発とQAの手戻りが発生してしまいます。
しかし、BDDでは、プロジェクトのキックオフ時にはQAが関与しておき、要件レベルから考慮漏れを指摘し、認識齟齬がないよう対話を積極的にやりました。それによって、後工程での手戻りが軽減されました。
②段階的なQA検証の導入
プロジェクト型QAでBDDを導入し、シナリオの検証だけでなく、単一機能のテストも行っております。
これにより、特定の機能が実装完了した時点でその部分の検証を開始できます。検証の開始が早くなることで、早期に不具合を検出することが可能になります。
従来のBitkeyの開発プロセスに合わせたQAでは、開発が完全に終了してから丸ごとSTG環境にマージされそこからQA検証が始まります。そのため、不具合を検知した時点で、プロジェクトの後工程という状況になります。また、手戻りが発生しているとともに、関連したテストケース群がブロックされ、QAチームの業務にも支障が出ることがあります。しかし、BDDの導入により、不具合が早期に発見され修正されることで、プロジェクトの後工程で計画外の対応が減り、ブロッカーとなるような不具合が軽減されることで、開発とQA工数の圧迫を軽減することができます。
③開発・ビジネスサイドと頻繁にコミュニケーションを行う
BDDの導入により、QAだけでなくビジネスサイドもプロジェクトの最初期からジョインしました。それにより、QAとビジネスサイドのコミュニケーションも増えています。
QAがシナリオを作成した時点で、その認識合わせのために会議を開催します。この会議で開発、ビジネスサイド、そしてQA間の認識のずれを解消し、QAによって作成されたシナリオがビジネス要件を満たすかを確認します。
ビジネスサイドはお客様に最も近い存在であるため、通常QAからは見落とされがちなユースケースを共有してもらうこともあります。逆に、この機会を通じてビジネスサイドもQAチームがどのような検証を行っているかを把握することができます。
プロジェクト期間中に頻繁にコミュニケーションを取り、認識のずれを解消することはもちろん、他部署とのコミュニケーションのパイプ作りにも役立ちます。
BitkeyにおいてBDDを参考にした取り組み
①QRDの作成
プロダクトマネージャー（PdM）が作成したProduct Requirements Document（PRD）を基に、QAチームがQuality Requirements Document（QRD）を作成します。
QRDは、PRDに記載されているビジネス要件に基づき、検証すべきシナリオ、プロダクトのリスク、テスト条件などをまとめたドキュメントです。QRDでは、クリティカルなパスを定義し、そのパスに関わる機能を優先的に実装するよう提案します。
さらに、QRDではシナリオを自然言語で表現します。これにより、非エンジニアのビジネスサイドも容易に理解し、ビジネス要件を満たしているかどうか確認できます。
②PRD読み合わせ
BDDを用いてプロジェクトを進行する際、各ステークホルダー間の仕様に対する認識のずれを防ぐため、「PRD読み合わせ」の会議を開催しています。
この会議は、案件が決まった以後可能な限り早期に開催します。当然、開発もまだ何も着手していない状態です。プロジェクトの規模によりますが、初期は認識を合わせるべき点や疑問質問などが多いため、開催頻度も高くなります。しかし、プロジェクトの工程が後工程になっていくことにつれ、そういった議論も減り、開催は週一回になるか又は中止されることもあります。
会議中には、まだ仕様が定められていない箇所を発見したり、ステークホルダー間で認識のずれがあることを明らかにすることが可能です。これらの問題を早期に解決することで、後続の開発と検証の手戻りが減ることを期待でき、プロジェクトがよりスムーズに進行します。
③検証の流れ
BDDを用いたプロジェクトの検証は、Bitkey従来のQA検証の流れとは異なります。通常の検証は、開発が完全に終了した後に、単機能の確認テストを行い、不具合が修正されたらリグレッションテストを実施します。しかし、BDDの検証では、クリティカルパスの実装が完了してから開始し、以下の手順で検証を行います。
- スモークテスト
a. 実装された機能の主要部分が正しく動作するかにフォーカスし、必要最低限のテストを行う - 単機能の確認テスト
a. 実装済みの機能ごとにフォーカスして、詳細なブラックボックステストを行う - 不具合の改修テスト
a. 単機能の確認テストで検出した不具合が修正されたら、再度関連箇所に関するテストを行う - シナリオテスト
a. 事前に作成したビジネス要件を満たすシナリオを用いてテストを行う - アドホックテスト
a. 特別な計画やドキュメントを依存しないで、特定の機能やシステム全体でテストを行う
終わりに
ビジネスサイドにも理解できて、かつお客様の体験に直結する仕組みとしてBDDを参考にしながら、アジャイルテストを取り入れることはチャレンジングな取り組みでした。何よりプロジェクトの管理や各ステークホルダーとの交渉がとても重要になります。
幸い、この取り組みによりQAだけでなく、開発の手戻りも軽減できかつ他部署からも支持を得ています。また、今回はQAがアジャイルテストとBDDを参考にプロジェクトを主導し、さまざまな横断的な連携を取ることに注力しました。各部署が個々に努力するだけでは、お客様により良いサービスを提供するという会社の目標を達成するのは困難です。アジャイルテストとBDDの導入により、各ステークホルダーが密にコミュニケーションを取り、共同で良質なサービスを提供するという文化を築いています。
Discussion