仕様から手を取り合う ―POとQAの早期協働で品質とチームを守るプラクティス―

はじめに

UPSIDERでPOをしているterryです！

このblogは、CfPで落選してしまったネタを供養するものです。

早速ですが、みなさんこんな経験はありませんか？

リリース間近となった時に、

「この挙動は期待通りですか？」
「追加のバグチケットが4件あります」
「テストスケジュールギリギリです」

という声が飛び交う。開発はバグ対応に追われ、QAもギリギリのスケジュールでやっている。乗り越えれば、お祭りのようですが、できれば避けたい状況かと思います。

そこで、QA・品質担保を「最後の砦」ではなく、開発の早期に持ってくることで、不確実性を低減し、開発前から品質を上げるプラクティスについて共有したいと思います。

テストケース作成はどこで行われるべきか

従来は、仕様と設計が概ね完了した時点で、QAチームに連携し、テストケースの作成を行なっていました。ただ、この状態だと冒頭の通り、テストでの発覚や仕様の考慮漏れが後工程に寄ってしまいます。下図のV字モデルでいうと、品質を確認するのは右側（テスト工程）が中心で、左側（要件・設計）で作り込まれた考慮漏れが、右側まで進んで初めて発覚しがちでした。

V字モデル

そこで、ユーザーストーリーをもとに、仕様とそれを満たすテストをQA・開発が一緒に構造化して書き下し、実装前にすり合わせを行います。いわば、V字の右側（テスト工程）で見ていた品質を、左側（実装前）に倒していく取り組みです。（ = シフトレフト）

すると、QAから「この条件抜けてませんか？」「このユースケースは具体的にどういうことですか？」と仕様段階で指摘を吸収できるようになります。開発としても、リリース間際に発覚していたはずの考慮漏れを、コードを書く前に潰せます。

開発/QA双方で確認しながら進めることで、仕様・スケジュールの不確実性を低減し、納得感を持ってプロジェクトを進めることができます。

では次に、開発・QAそれぞれがどのような視点で仕様を深ぼるかを見ていきましょう。

開発目線でのレビュー

開発目線では、

シーケンス図
EP設計
データモデル
インフラアーキテクチャ

を設計の段階で決めていくので、そこから仕様の抜け漏れをレビューしていきます。

開発レビュー

QA目線でのレビュー

一方QA目線では、

ユーザーストーリーを満たす仕様か
権限や境界値テストなど、よく漏れやすいケースが考慮されているか

の視点で仕様をレビューしていきます。

QAレビュー

抜け漏れのないレビューを行うには

上記のように言っても言うは易しで、実際どのように仕様を書いていけば良いのでしょうか。ここでは、BDD形式を紹介したいと思います。

BDD形式

BDDとは、Behavior Driven Developmentの略で、「振る舞い駆動開発」のことを指します。

元々TDDを実践することに対して、「テストは何を書けばいいのか」「どんな粒度で書くのが良いのか」と詰まってしまう問題があり、「テストを振る舞いの仕様として書く」ことがDan Northによって提案されました。"振る舞い"（誰が・どういう状況で・何をしたら・どうなる）を共通の言葉で書くことで、PO・開発・QAの3者が同じ仕様で認識を揃えることができます。

具体的な書き方は、受け入れ条件を「シナリオ」として、

GIVEN : 前提条件は？（どういう状況か）
WHEN : どのような操作・イベントが起きたか？
THEN : その結果、何が保証されるべきか？

の3つで記述します。

ここで「誰が」を表すために、本記事ではユーザーストーリーの形式（As a [役割] / I want [機能] / so that [価値]）を組み合わせ、シナリオの先頭に AS（誰が）を加えた形で書いています。

AS : 誰が？（ユーザーストーリー由来）
GIVEN : 前提条件は？
WHEN : どのような操作を行なったか？
THEN : その結果は？

補足：標準的なBDD（CucumberのGherkin構文）では AS というキーワードは使わず、「誰が」はシナリオ名やユーザーストーリー側に記述します。本記事では「権限（誰が）」がパターン分けの主要な軸になるため、あえて AS を明示する独自の書き方を採用しています。

銀行連携での例

私のチームは、与信算出のための銀行連携をしており、例を紹介したいと思います。銀行連携のために、金融機関のサイトにログインして認可をするケースを考えてみましょう。

項目	内容
AS（誰が）	UPSIDERユーザー
GIVEN（前提）	新規連携
WHEN（操作）	銀行連携を行う
THEN（結果）	銀行連携成功表示が出る

一見良さそうですが、ユーザーストーリーや振る舞いの観点として、「UPSIDERのユーザーは誰でもいいの？」「銀行連携は初回なの？削除した上で再連携なの？」と言った点が気になります。また、シーケンスやEP設計をしているエンジニアからすると「認可が失敗した時はどんなパターンがあるの？」と言った点が気になります。

これを反映すると、以下のようにパターン分けできます。

	AS（誰が）	GIVEN（前提）	WHEN（操作）	THEN（結果）
パターン1	UPSIDER管理者ユーザー	連携実績なしの新規連携	銀行連携を行う	銀行連携成功表示が出る
パターン2	UPSIDER管理者ユーザー	連携銀行を削除した上で、新規連携	銀行連携を行う	銀行連携成功表示が出る
パターン3	UPSIDER一般ユーザー	（問わない）	銀行連携を行う	権限エラーが出る
パターン4	UPSIDER管理者ユーザー	連携実績なしの新規連携	銀行連携を行う（認可画面で同意せずキャンセル）	銀行連携失敗表示が出る

※ パターン3の権限エラーは連携状態によらずAS（誰が）で決まるため、GIVENは問いません。

特に4に関しては、認可画面でキャンセルするパターン以外にも、銀行がメンテナンス中だった、銀行側のサイトで認証リトライ回数の上限まで間違えた（これは前述の「境界値」の観点にあたります）、などさまざまなパターンが考えられます。また、失敗した場合にユーザーは何をするのかを、銀行側と開発前に仕様を洗い出すきっかけにもなります。

シフトレフトが実現できたその先は？

最後にここで1つ疑問が上がってきます。「いい感じにシフトレフトできたが、シフトした分、QAとしては何をするのが良いのだろうか」です。機能テストケース作成が早く終わる（または不要になる）ため、その時間を有効に活用したいですね。

シフトレフト

ここに関しては私は2つのアプローチがあると考えています。

横方向（リグレッションテスト）

まずは、横方向への広がりです。シフトレフトにより仕様の早期合意ができたことで、開発の実装と並行して自動テストの拡充やE2Eの設計に投資でき、リリース時点から運用品質を担保する方法です。

横方向への進出

縦方向（開発に寄り添ってユニットテストの観点やカバレッジ）

そしてもう1つが、縦方向への広がりです。仕様の合意の後に待っているのは、設計および実装・テストのフェーズです。ここにQAが関わり、インフラ設計の品質のレビューやユニットテストのテストパターンの洗い出しを、開発と一緒に行います。こちらはより開発と並行して実装の深い部分まで入り込んで、QAがコードレベルの品質にもコミットしていく方法です。

縦方向への進出