これを考えないと、テストケースが不必要に複雑になります。(その名の通り)、本来実装時や実施時に検討し決定する事項です。テスト手順は、テスト観点以外にもたくさんのことを決めないと実行できません。決めることは、何となくテスト設計と混同してしまいがちだ、という点です。@YasuharuNishi例えば「テスト環境」を考えてみましょう。環境を変えることがテストの意図を満たすなら(例えばそういうバグを出したいのなら)、テスト環境はテスト観点です。これは極論すると、値は何でもいいんです、実行できれば。それによってテスト観点の漏れを防ぐ側面もあるからです。境界値を選んだり網羅しようとしたりします。したがって混同してしまいます。峻別できているからこそ、効果的に集約ができます。混同されていると、集約することによってテスト観点が変化してしまい、見つかるはずだったバグが出てこなくなってしまいます。@YasuharuNishiテスト観点として挙がっている、もしくはテストケースとして設計しているのにバグが出ないとなると、再現性の無い不具合だという誤った結論に至りやすくなります。多くの場合、タイミングやメモリの状態といった、コストや時間のかかる再現テストを伴ってしまいます。混同によって、バグを出すのに必要なテスト値がマスクされてしまっているだけです。テスト値を指定してテスト手順を実行すれば100%再現します。@YasuharuNishiさぁこのあたりで「事前条件」という概念の曖昧さと、一般的に意味するテストケースという概念の前提が分かってきましたね。@YasuharuNishi一般的にテストケースとは、ある操作や機能で一度に実行するなにがしかだという前提を置いています(違うものもあります)。その時テスト条件とは、ある操作や機能で一度に実行する条件である、という前提が付与されます。@YasuharuNishiそしてその時、事前条件とは、テストケースが一度に実行されたタイミングよりも前に実行されたり成立されているなにがしか、という意味しかありません。テスト条件と事前条件のように並列で語られるので誤解されやすいのですが、二つの「条件」という単語は異なる意味を持っています。@YasuharuNishiですからテスコンチュートリアルの「テストケース」は、暗黙の「一度に実行される」という前提を外しています。それによって、含まれるテスト観点が実行されたり成立されるタイミングはまちまちになります。@YasuharuNishiその代わり、テストケースに含まれるテスト観点は全て、テストの意図を満たす(例えばあるバグを見つける)ために必要ななにがしかになります。それ以外は考える必要がありません。@YasuharuNishiこのように考えておかないと、テストケースの意図を満たすために必要ななにがしかが、テスト開発のあらゆるところで様々な概念として出てきてしまうため、収集がつかなくなってしまいます。そのように考えるのです。@YasuharuNishiテスト開発ではないテスト準備は、テスト実行に主眼を置いています。したがって「一度に実行されるなにがしか」を特定することがとても重要になります。しないとテストケースが実行できませんから。トレードオフとして、テストケースの意図は満たしにくくなります。COVID1981コメントコメントがまだありません。