Software Testing - Columns: テストの「設計」（１）

テストケースの粒度の話を覚えていますか。「○○というユーザ名、××というパスワードでログインする」というテストケースに対して、「ログインする」というテストケースは粒度が粗い、という話でしたね。 仮に自分の組織のテストケースが前者の粒度だったとしましょう。もしユーザ権限が4つあった場合は、それぞれの権限に合わせたアカウントで、最低でも4種類のテストケースを作成することになります。では逆に、権限の異なる4つのテストケースをレビューすることになったら、皆さんはどうしますか？ まず4つのテストケースの違いを考えますね。ふむふむ、ユーザ名が違うなぁ、なぜ違うんだろう、と考えながら仕様を思い出したり、仕様書をめくったりします。なるほど、ユーザ権限が異なるわけか、では必要な権限は網羅されているかな、なんて考えながらレビューしていくと思います。面倒ですね。 では、4つのテストケースに対して「すべての権限の

[somat]

「粒度の粗いテストケース（ry をまず考えて、制約条件（ry を挙げ、粒度の細かいテストケース（ry に詳細化すると便利です。これを私はテストの「設計」と呼んでいます」/ 粒度の荒いものをテストアイデアと呼んで区別

[PoohKid]

テスト設計のコツ、粒度の粗いもの（テストアイテム）→粒度の細かいもの（テストケース）の流れで考える