デジタル化推進マネージャーの長田です。
前回記事では「デジタルガバメント・ジャーニー (5)」では、

• 最小の要件定義書

として、受入テスト仕様書作成の対となる要件定義書の作成方法について独自の視点で書かせていただきました。

今回は第６弾として、受入テスト仕様書をどのように作成していくか、「テスト駆動開発」について触れていきたいと思います！

1. テスト駆動開発（TDD）とは

システム開発でテストというと、テスターによる品質保証活動をイメージされるかもしれません。
しかし、近年のアジャイル型開発のような短いサイクルの開発プロセスにおいては、テスターのみで品質を担保することは困難であり、開発者とテスターが一体となった開発プロセスを歩んでいく必要があります。
これがテスト駆動開発（Test-Driven Development: TDD）です。

発注者にとっては「テストは難しい」というイメージがあるかもしれませんが、デジタルガバメント・ジャーニー(4)でも記載したように、自らが示した要件通りにシステムが実現されたかを確認できるのは要件を示した者にしか分かり得ません。
そのため、受入テストにおいては発注者こそがテスターとなって対応していく必要があります。

では、テスターが関わるテストについて、もう少し切り分けをして具体的なテスト内容を見極めてみましょう。

2. アジャイルテストの四象限

テストには複数の段階があり、開発プロセスにおいては下図のようなテストピラミッドを登っていく必要があります。

当然下流工程は技術的な要素が多くなり、専門知識が求められるフェーズとなります。一方、上流工程はビジネス的な要素が多くなるため、発注者側の視点が強く求められてきます。

具体的に象限を分けて記載すると、下図のように分類できます。

• Q1. コードレベルのテスト

  • いわゆる単体テスト

  • 技術面を中心に品質確認をしていく
    

• Q2. 顧客視点のテスト【今回の対象】

  • いわゆる受入テスト（業務レベルのテスト）

  • ユーザーストーリー（業務フロー FL2:詳細事業機能）をベースに画面の動きなど、システムの振る舞いを確認していく

• Q3. 探索的テスト

  • いわゆる総合テスト（業務面）

  • 業務フローFL3:業務機能～FL4:詳細業務機能をベースに業務全体の連結を確認していく

  • 使い勝手も合わせて確認していく（アクセシビリティや動線等）

• Q4. パフォーマンステスト

  • いわゆる総合テスト（システム面）

  • システム性能やシステム運用の妥当性を評価していく

本記事では発注者の視点にフォーカスするため、Q2つまりテスト駆動開発のうちでも「受入テスト駆動開発（Acceptance Test-Driven Development: ATDD）」の具体的なやり方を記載していきます。

3. 実践ATDD

3.1 Step1: 発注者と受注者で振る舞いを正確に描写する

まずは業務フローの中で最もシンプルなハッピーパス（正常系）を正確に共通認識化します。具体的な事例をもって発注者が1段1段説明をしていくことが必要でしょう。

多くの場合「あれ？この場合はどうなる？」という疑問が生まれると思いますが、これが非常に大切です。もしかしたら前提条件の認識不足で発生しない事柄かもしれませんが、そこまで理解することも目的の1つです。

次に発注者視点で起こって欲しくないことを、つぶさに伝えることです。いわゆる業務上の異常系を明確にする作業です。
例えば、受付期限を過ぎても申請画面が開いてしまい申請ができてしまう、などです。
特に、パターンは膨大になることが予想されますが、入力値のアンチパターンも是非明確にしておくと良いと思います。

これらの作業を、デジタルガバメント・ジャーニー(5)で記載した業務フローの1段1段で出し切るのが良いでしょう。

このステップで大切なのは、洗い出された1つ1つがユーザーストーリーになるわけなので、受入テスト仕様書として発注者がきちんとまとめておくことです。

3.2 STEP2: ユーザーインターフェース（UI）を描写する

入力操作は利用者にとって非常に重要な視点であることは言うまでもありませんが、利用者が何を求めているかを理解しているのは発注者以外いません。

ハッピーパスを中心に（最低でもハッピーパスだけは）、どういった画面構成にしておきたいかをラフスケッチでも伝えることが重要です。
例えば、選択項目を検索ダイアログにするのかプルダウンにするのかだけでも、実装上の作りは大きく変わります。

ただし、アクセシビリティに関してはベストプラクティスがあるのも事実ですので、この段階においても受注者から適切なアドバイスを得ながらユーザーインターフェースを描写していくことが肝要となります。

4. 次工程へ

私の考えにおいては、次工程は「要件定義工程」と「総合テスト工程」となります。

要件には業務的な要件だけでなく、システム的な要件（システム性能やシステム運用などの非機能要件）も含まれるため、これを描くことが次の工程です。
言い放った/聞き取った振る舞いとその際の周辺状況を基に同時アクセス数や稼働率などを明確化していき、それらを要件定義書にまとめ、合わせて総合テスト仕様書（アジャイルテストの四象限でいうとQ3とQ4）を作成してしまいましょう。

あくまで最短コースを意識して、小さいイテレーションに落とし込む。
その入り口としてATDD（受入テスト駆動開発）を実践してみてください。

5. 本記事の最後に

アジャイル型開発は常にテストを続けることが求められます。
そもそもアジャイル型開発を行う目的は成果の最大化であることから、発注者と受注者の関係は良きパートナーであるべきです。
そこには忖度もお膳立てはなく、明確な意思表示と協働・協調のみがあるべきです。
最良なパートナーと作り出す価値を最大化するために、テクニックを駆使していけると、スピード感をもったバリュー創出が可能になると思います。