実践ソフトウェアエンジニアリング 20章で好きなところ

このエントリは実践ソフトウェアエンジニアリング第9版アドベントカレンダー の23日目（実質29日目）です。

https://www.amazon.co.jp/dp/4274227944

自分が担当した20章「ソフトウェアテストー統合レベルー」にに書かれている良いテストの特性を考えてみようと思います。

1. 良いテストは、高い確率でエラーを発見できるテストである

良いテストは、高い確率でエラーを発見できるテストである
この目標を達成するために、テスターはソフトウェアを理解し、どのようにソフトウェアが失敗するかを頭の中でイメージしなければならない。

個人的に良いと思うのは、「テスターはソフトウェアを理解する必要がある」ということと、「失敗をイメージしないといけない」ということです。「ボタンを連打してみた」ではなく、特定の狙い（イメージ）を持ってテストをするのが良いと思います。もちろんバグが出やすい操作はありますが、「イベントが短時間で連続で発生したときに制御されていないかもしれないので、ボタン連打をする」というところまでイメージしながらテストできると良いと思います。

テストはイメージの世界です。（葬送のフリーレン風）

2. 良いテストは、冗長ではない

良いテストは、冗長ではない
テストの時間とリソースは限られている。2つのテストケースを同じ目的で実行しても意味がない。すべてのテストは、たとえそれが微妙な違いであっても、それぞれが異なる目的をもつべきである。

試験書などに書き起こしても、テストの目的が書かれていないことがあります。これはとても勿体ないですし、レビューなどで重複を取ることが大変になるので常にテストの目的を書いておきたいところです。探索的テストなどでガリガリ動かすときも、テストの目的を考えておくのはいいですよね。一番最初に述べた「失敗のイメージ」にもつながる話だと思います。

3. 良いテストは、「ベストオブブリード（最高の品種）」であるべきである

良いテストは、「ベストオブブリード（最高の品種）」であるべきである
時間やリソースに限りがあるときは、目的の似たテスト群の中から特定種類のエラーすべてを発見できそうな「最高の品種」といえるテストのみを実行するのがよい。

テストというと「網羅網羅」というようなモウラ星人が多いのですが、早くフィードバックし、早くテストを終わらせてプロダクトをリリースするにはテストの網羅も考えつつ、数を減らさないといけないです。なので、ここでいうような良いテストをデザインする力が必要になります。

4. 良いテストは、単純すぎても、複雑すぎてもいけない

良いテストは、単純すぎても、複雑すぎてもいけない
複数のテストケースを1つのテストケースにまとめてることができる場合もあるが、副作用が発生してエラーの存在が隠れてしまうこともある。一般的には、各テストは独立して実行するのが良い。

3つ目からの続きになりますが、色々なエラーを取れるようなテストケースをデザインしてもそれによって隠れてしまうエラーがあっては本末転倒になります。また前のテストが後のテストに影響するようなこともありますので注意が必要です。

クリーンテストの５つの規則でF.I.R.S.T（Fast Independent Repeatable Self-Validating Timely）と言われるように、どのテストでも独立性は重要になってきます。

まとめ

こんな感じでチームの中で「自分達の考える良いテスト」って何だろう？って話ができれば良いと思っています。 ちょっとずつでもチーム全体で品質のことを考えていければよいですね！