テストをどこまでやればいいのか

Question

あるソフトウェアに手を加えたときにどこまでテストをやればいいのか、しっくり来ないので皆さんのご意見が聞きたいです。
単体テスト、結合テストが次のそれぞれの項目について必要かどうかご意見ください。

i)あるメソッドA(外部への参照等を一切せず、inputとoutputのみが外界との接触であるとする)をリファクタリング
ii)上述のメソッドAの機能に変更を加え、outputが変化する場合
iii)あるメソッドB(DBを変更するメソッドを含む。inputとoutputはない)をリファクタリング
iv)上述のメソッドBの機能に変更を加え、DBへの変更値に変化がある場合

また、おすすめのソフトフェアテストの書籍があればご紹介くださいm(__)m

Answer 1

基本的にはどんな場合でも、単体テスト・結合テスト、更には総合テストまで実施すべきです（理想ですけど）
例えば外部参照の例では、元々外部参照をしていないコードに対して外部参照以外の修正をしても、変わらずに外部参照をしていない、という保証ができないからです。
アウトプットが変わる例では、そのアウトプットを利用する処理に影響がないかは、当然結合テストで行う必要があります。
とはいっても現実的には厳しい場合もあるので、メンバー内でコードレビューを入念に行って、これは単体のみでいいね、とかアウトプットが変わるから結合までやりましょう、とか決めるしかないと思います。

Comments

[Takahiro310]

理想はやはり全部やることなんですね。勉強になります。

[ttyp03]

単体だけで済ませて、結果何事もなければいいんですけど、何かあったときが大変です。
開発側は「ちゃんと結合も総合もやっておけばよかった orz」となるし、お客さんからは「なんで単体しかやってないの？」と責められるしｗ
単体のみ、結合までなどは、お客さんがいるような現場では両者合意の上に進めるべきですね。

Answer 2

こんにちは。

ソフトウェアも商品の一つですから、お客様に対して何らかの「約束」をしていると思います。その「約束」を満たしていることを検証するのがテストの目的と思います。
かと言って、全てのケースのテストを行うことは現実的ではありませんので、省けるところはどんどん省かないとビジネスとして成り立ちません。

そして、経験的には何か1箇所でも変更したら、全て以前行ったのと同じテストを再度するべきと考えています。予想外の部分へ影響することは意外に少なくないですから。
しかし、それは現実的ではないとも思います。お客様へ迷惑をかけない範囲で如何に手を抜くかも重要ですね。

i)あるメソッドA(外部への参照等を一切せず、inputとoutputのみが外界との接触であるとする)をリファクタリング

以前、実施したテスト仕様書が残っているはずですから、メソッドＡと、メソッドＡを用いる部分について同じテストに通れば大丈夫と判断するでょう。（出荷後に見つかった不具合の再発防止テストも入っていれば確実です。）
メソッドＡを用いる部分のテストは広範囲かもしれないので、悩ましいです。
メソッドＡの単体テストを網羅的に行って、以前のメソッドＡと同じふるまいをすることを検証するもの１つと思います。

しかし、テストを自動化していない場合、リファクタリングのためだけにテスト費用をかけることを納得してくれる人は少ないと思います。
リファクタリングは他の網羅的テストが必要になる仕様変更に乗じて行うことが現実的なように感じます。

ii)上述のメソッドAの機能に変更を加え、outputが変化する場合

その影響がありうる部分について全てテストするのが理想です。
問題は影響がありうる部分の想定にミスがないかです。経験的には結構簡単に発生します。
それを考えると、全てのテストをやり直すべきと考えています。でも、正直多くの場合、現実的ではないと思います。

テストが必要な部分を最低限自分自身の中でレビューする（文書化する等）、もしくは、他のメンバとレビューして、テスト範囲を絞り込むのが落とし所ではないでしょうか。

iii)あるメソッドB(DBを変更するメソッドを含む。inputとoutputはない)をリファクタリング

i)と同様です。

iv)上述のメソッドBの機能に変更を加え、DBへの変更値に変化がある場合

ii)と同様です。DB変更もoutputの一種です。

Comments

[Takahiro310]

事前に自動化されていれば、それを使うのが楽で確実ですよね。ありがとうございます。

Answer 3

テストをどこまでやればいいのか

「少しでも変更があれば、必ずテストする」というのが一番確実です。
すなわち、質問文のi～ivのすべてをテストするということです。

直接参照してなくても、入出力を介してシステムを変化させるわけです。
まったく何の変化も及ぼさないなら、そもそも変更の意味がありません。

しかし一方で現実的には、そんな杓子定規にテストしていたら、
リソースが足りずに開発が破綻する場合もあることでしょう。
ですから、「テストをどこまでやればいいのか」は難しい問題です。

---

実務的には、どれくらいテストするかは分野によると思います。
ミッション・クリティカルなら厳重にテストしますし、
そうでないならそれなりにテストします。

金融や交通など社会インフラの分野なら、たったひとつのバグが、
ニュースで報道されるような大事件に発展する可能性があります。
銀行のATMが止まったとか、駅の改札が止まったとか。

ですから、テストを非常に慎重に行います。
コード一行の修正に、一週間や一ヶ月かけるとか。

一方、ソシャゲやSNSのように娯楽や交流の分野では、
多少のバグがあってもベータ版としてリリースすることは日常茶飯事です。
数打ちゃ当たる的な発想で、当たってから完成させた方がコストが安いわけです。

---

もう少し技術的に細かい話をすると、バグを発見したときに
バグ票（不具合票とか障害報告とも呼ぶ）を切るようにして、
テストの工程量とバグの量を比較して、統計的に決める手法があります。

つまり、どれくらいの粒度でテストすれば、コストと釣り合うのかを見積もります。
試行錯誤に長い時間はかかりますが、統計ですから確実なやり方ではあります。

ただし、そのデータ収集や見積もり自体にもコストがかかるわけなので、
基本的に大規模開発向きの手法で、小規模だとそこまでするのが苦しいでしょう。
現実的には、経験でザックリ決めてるところが多そうです。

ですから、質問者の方の職場の分野や規模に依存します。

Answer 4

ソフトウェアーが間違っているということは検証できますが、
合っているということは検証できないのですね。
普通テストは数件で行いますが、1000000件目に挙動がおかしくなるということがあるからです。

プログラム仕様書に従い、データのパターンを列挙しそのデータで実行して挙動を確認する。
作ったプログラムに従い、データのパターンを列挙しそのデータで実行して挙動を確認する。

基本は全パターンをテストするのですが、時間が途方もなくかかるとか、
ここまでテストしたらOKだろうというところで打ち切るのが普通ですかね。

そうやって打ち切るから銀行のオンラインが止まったとか、空港のシステムが止まったとか
そういったことが起こるんですけどね。