アジャイルテストの描写

作者 Dan Puckett , 翻訳者 馬場 彩子 投稿日 2011年5月1日

セクション

プロセス/プラクティス,

設計/アーキテクチャ,

デベロップメント

トピック

User Stories ,

品質 ,

ソフトウェアテスト ,

アジャイル技術 ,

Agile ,

テスト

共有 |

原文(投稿日：2011/04/25)へのリンク

アジャイルコミュニティの何人かのメンバが、ユーザストーリーテストやテーマ全体に関するテストをどう表現するか、いくつかの方式を提案している。

ストーリーテストを表現する方法についてCharles Bradley氏は以下のように述べた。

箇条書き

期待する具体的なシステムの振舞を箇条書きにし、ストーリーカードやwikiに記述する。このテクニックは小さく単純なストーリーのときにうまくいく

「...でテストする」

テストしなければならないすべてのシナリオやデータを記述する。例えば 「正しくない/正しい/空白のパスワードでテストする」と記述する。上と同様に、このテクニックは小さく単純なシナリオではかなりうまくいく

「...をテストする」

「...をテストする」で終わるような文をまず書き、 その後にシステムの振舞を評価するために必要な文を書き足していく方法である。習得しやすい上、前の２つの方法でうまく表現できないようなテストでもシンプルなものであればうまく表現できるかもしれない。

前提(-の場合)/処理(ーしたら)/結果(ーになる)

前提(ーの場合)、処理(ーしたら)、結果(ーになる)という3つの章だてで記述する。 「前提（-の場合)」 の章では、前提条件やテストの構成、テストで入力するものやシステムの状態についてリストアップする。「処理(ーしたら)」 の章では、トリガまたは状態がかわるきっかけとなるイベントをリストアップする。「結果(-になる)」の章では、システムの振舞や期待する出力、そして／あるいは次のシステムの状態を記述する。この方法は前提条件が複数あったり、特定のトリガがあるテストを表現するのに適している。

実例による仕様書—コンセプト形式

テストの入力と期待する出力を、表形式で記述する。コンセプトを表現できるよう、入力／出力するデータは、特定の値ではなくその意味について説明する。表形式で簡単に表現できるテストは、この方法が機能する可能性がある。

混合と組み合わせ

対象のテストを様々な側面からみた場合に最も適した表現になるように、異なる方法をいろいろ組み合わせてストーリを描く

「デモ手順書」というテスト形式をPeter Stevens 氏は勧めた。完全なユーザストーリーをプロダクトオーナにどのようにデモするか、シンプルなワークフローを作成してみよう、というものである。彼はこのように書き込んでいる。

「デモ手順書」を作成するのは、プロダクトバックログを整える作業の一環として行います。ですから、見積／リリース計画ミーティングや１番最初のスプリント内などのどこかで実施できます。これは「対話」を通して作り上げていくもので、あまり初期に前もって実施しない方がいいでしょう。

また、テーマ全体を通して必要なテストの計画をたてる場合、マインドマップを使用してはどうか、とLisa Crispin氏は言う。 彼女があげた例では、一つのテーマをチームが完成させるのに５回のイテレーション、つまり10週間ほど必要だった。 Crispin氏と他のテスタはホワイトボードにテストすべきことを表すマインドマップを描き始めた。その後マインドマップをみながら、開発チーム、プロダクトオーナ、監査やその他のステークホルダと議論を重ねた。

テーマの実装をしている間、テスタはマインドマップを何回も参照した。Crispin は以下のように記述している。

最終的に私たちは、処理のあらゆる側面とシステムの他の部分への潜在的な影響について、考慮し議論し尽くした、と自信を持って言えるようになりました。すべてのステークホルダと個々の要求や関心ごとに関して対話を実施し、機能レベルだけではなく、パフォーマンスやユーザビリティについても適切なテストを実施することができました。