ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

テストケースとAcceptance Criteriaの違いは何なのだろうか

アジャイル テスト設計・技法

ちょっと前に、テストケースとAcceptance Criteria*1（以下「AC」）の関係について、こんな疑問を抱きました。

ACが、「ユーザーストーリーが満たすべき必要条件」だとすれば、それはテストケースとどう違うのだろう。ACのあるべき記述粒度って？

この疑問にそのまま回答してくれそうな記事が公開されていました。
この記事を通しての現時点の自分の理解をメモしていきますが、なにぶんわたしはスクラム有識者ではないので、誤解があるようでしたらご指摘いただけると嬉しいです。
要はポエムです。

www.softwaretestingmagazine.com

記事の言っていること

テストケースとACのいくつかの定義から両者の類似性を指摘したうえで、以下のような比較表を提示しています*2。

特徴 テストケース Acceptance Criteria
詳細さ ある あるかも
明確性 あり あり
正確性 あり あり
具体性 あり あり
テスト可能性 あり あり
機能面の記述 あり あり
非機能面の記述 あり あるかも
作成のタイミング 事前・事後*3 事前

記事はこの後なぜか、テスト管理ツール（あるいはテストケース管理そのもの）批判にハンドルを切っていく*4のですが、主張のポイントは、「テストケースとACが本質的に同じものなのであれば、両者を一緒にすれば？」です。
ただし、「テストケースいらないじゃん」と言っているわけではありません。雑に要約すると、以下の通りです。

  • 「ACには明示されていないけれど、クリアしなければならないテストケース」があるのだとしたら、ACの定義上おかしいよね？ ACに載せるべき。
    • たとえば細かいエッジケースなど。
  • 逆に、「ACになく、ユーザーストーリーの受入れに影響しないテストケース」は、テストとして本来不要なのでは？
  • つまりテストケースとACは同一にできる。それなら一緒に管理すればいいでしょう。

@yattomさんに教えていただいたこと

テストケースとACの違いについてTwitterでつぶやいていたときに、@yattomさんが以下のように教えてくれました。

AC=テストケースでも別によくて、このプレゼンの話のように「チームがいい感じになる」のが程よい粒度だしそれはチームによる。場合による、というあまり意味のない回答になる気がする。ふわふわなACをみんなで読み合わせつつ手直ししたらほぼテストケースになる、なんてのもいいなあと思います

「どんな粒度がいいのか」という疑問は常に具体的なチームがあり、コンテキストの想定がある中で持つのがいいと思う。思うと言ってるのは、アジャイルコーチとしての立ち位置かな。そういう積み重ねで、こんなときはこんな粒度とか書きぶりとか観点だといいよみたいな情報のやりとりがあるとよさげ

たとえば、機能単位の完成に目が行きがちなチームは、シナリオ(ユースケース的な)をACとして意識すると考慮もれが減らせそうとか。POがみっちりAC(テストケース)を書けるんだけど、Devが飽きてもっと粗くていいよとか異常系はこっちでカバーするよと言うとか。

このご指摘は目から鱗が落ちるものでした。

わたしの疑問がそもそも、「プロジェクトやプロダクトやチームに依存しない、ACの適切な記述粒度というものが存在する」という暗黙の前提から始まっているんですよね。 このような発想がそもそもスクラム的ではないことに気づかされます。「常に具体的なチームがあり、コンテキストの想定がある」という言葉は、ACの話に限ったものではないなーと反省しました。

チームの状態やコンテキストが共有できていれば、そのチームに合ったACの書きっぷりが次第に定まってきて、「これは詳しく書くまでもない」「ここは明示的に書いておこう」というセンが見えてくる。そういうACになっていれば、「テストケースをpassしてないんだから、リリースできないでしょ？」「いや、ACは満たしているんで」という不毛な争いはない（はず）・・。

そう考えていくと、ACというのは「チーム内で共有されたコンテキストを前提にした、ユーザーストーリーの受け入れ条件」という感じなのかなーと捉えています。
「ユーザーストーリーが満たしているべき条件を、網羅的かつ詳細に記載したもの」ではないので、上の引用した記事のように「本質的には同じものだから、一緒にすればいいじゃん」というのはちょっと違うんだろうなと。結果的に両者が一致するのは別にいいのだけれど、そもそも位置づけが違うので、「一緒にすべき」とすると、おかしくなるように思います。

DoDに書いておくべきこともありそう

たとえばあるユーザーストーリーBを実装することによって、既存のユーザーストーリーAが正しく動かなくなる（リグレッション、いわゆる「デグレード」）リスクがあると思います。
かといって、ユーザーストーリーBのACに「他のユーザーストーリーを壊していないこと」なんて書かないですよね？ 書かないけれど、もし壊していたら、ユーザーストーリーBはリリースできないでしょう。

このような条件はユーザーストーリーごとに設定するものではなく、DoDに書くことになるのだと思います。
たとえばこのサイトでは、エピックのDoD例として、「リグレッションテストをパスしていること」があります。

www.leadingagile.com

おまけ

あるわけないよね。

*1:Acceptance Criteriaを「アクセプタンスクライテリア」とカタカナで書いていいのかもしれないけれど、カタカナにするには長すぎるし、AcceptanceもCriteriaもカタカナ語になっていないので、どうも違和感がある。

*2:ブログ記事に掲載された表に、記事本文の記述を追加・加工しています。

*3:元記事の著者は、テストケースは実装前にできるだけ書き下して開発者に伝えておき、QAは非機能テストや探索的テキストにより注力すべきとしています。

*4:わたし自身はテスト管理ツールが善であると信じているところがあるから、このような批判に向き合う必要はあると思っています。