テストはどこまで行うか | システムエンジニアライフ

テストはどこまで行うか

ヘッダー広告
スポンサードリンク
テストケースを作成していて、どこまでのテストを行うか迷うことが多々あります。

ノンデグレードテストについて、どのパターンをどこまで行うか。

結合テストとシステムテストで、どこまでが結合テストで、どこまでがシステムテストなのかを迷うことが最近多いです。

テスト範囲はどう決めるのか

軽微な修正でのテストケース


私はWebアプリケーション保守を行なっております。

私の現場での保守案件は、機能追加も多々ありますが、やはりバグ対応が多いです。

バグも影響範囲の大きなバグから、1クラスファイルの1行だけ直せば済むようなものまで様々です。

私がケースを作成する際に困るのは、影響範囲の小さい軽微な修正です。

機能追加や大きなバグの場合には、基本的には考えられる全てのデータバリエーション、業務パターンのテストケースを作成し、十分に品質を担保するようにテストします。

(実際には全てのパターンをやっていると思っても、漏れたり出来ないことはままあります)

しかしこれが軽微な修正だと途端に迷ってしまいます。

例えば、『小数点の扱いを四捨五入で計算していたものを、小数点以下切り捨てに直す』というような軽微な改修の場合に、単体テストでは小数点の扱いが合っているかのテストを行うと思います。

具体的には、四捨五入の場合と切り捨ての場合で値が異なるようなケースです。

と同時に、その計算を行なっている画面の他の処理も単体テストのケースとして、いくつか確認するかもしれません。

単体テストはこんな感じで軽微な改修にはそれに適したケースを考えてテストをします。

これが結合テストとなるとどうでしょうか?

単体テストが修正箇所の画面をテストするなら、結合テストは修正箇所の画面が存在する機能内の他の画面も含めて(結合させて)テストしていきます。

例えば、商品を購入するという機能の消費税計算を、今まで四捨五入していたものから切り捨て処理を行うよう修正する場合には、「商品選択画面」→「クレジット入力画面」→「商品確認画面」→「購入完了画面」の画面遷移が商品購入の機能だと考えて上記の流れでテストを行います。

この時に、例えばAの商品は20%offのキャンペーンが適用中のため、購入時に20%オフで計算して、その結果に消費税を掛ける。Bの商品の場合はキャンペーン対象外のため、そのままの金額で消費税計算をする。というような処理が存在するとします。

ロジックを確認してみても、今回の修正によりキャンペーンの計算には影響がないことが明白である場合、ここをノンデグレードテストとしてケースとして行うのかが私はすごく難しい判断です。

その機能を最初に作成した際にはテストしたであろう部分を、今回の対応に当てはめた場合にテストするべきかそれともしなくて良いのかが迷います。

次にシステムテストですが、結合テストで商品購入機能がテスト対象の場合、システムテストではより業務的に考えてテストを行います。

具体的には、「商品の入庫機能」、「在庫管理機能」、「商品購入機能(修正箇所)」、「商品の出庫機能」、「商品購入履歴確認機能」などがシステムテストでのテスト範囲になると考えています。

この時にも最初に開発したときのテストでは、同時に購入する人がいて片方の人が購入できないケースや在庫管理機能で金額を変更したうえで購入した際に、変更された金額で購入されるか等をテストしていたとします。

しかしこちらも今回の修正内容とはあまり関係がなく、問題は起こらないであろうと思われます。

この場合に、システムテストでどこまでやるべきなのかが悩みます。

結合テストでもシステムテストでも今回修正した内容を確認するために、購入する金額を変更して四捨五入が正しいかを確認すればよいという意見もありますが、それだと単体テストと同じことをやっているだけで、有効なテストであるとは言えないと思うのです。

この場合、私は上記で挙げたような関係ないと思われるノンデグレードテストは必要だと考えています。

確かに普通に考えたら関係ないと考えられて影響が出ないと思っても、実は何かが問題となって違う機能まで影響してしまうということも稀にあると思います。

そういった場合に、ノンデグレードテストを行っていればバグを検知できる可能性も上がると思います。

ただ全てのノンデグレードテストを行うのは違うと思います。

軽微な修正の度に以前に実施した全てのケースを実施していたのでは、大変な時間がかかりますし、お金もそこまでの余裕はないことがほとんどだと思います。

そこでどこまでテストを行うのかの判断が難しいのです。

一つの考え方としては、テスト密度を参考にして、STEP数に応じてテストすべきケース数に収まる範囲までのケースを行うというものです。

テスト密度とは、過去に開発した際にどのくらいのSTEP数に対してどのくらいのケース数を実施していたかを確認し、今回の開発(STEP数)の場合には、ケース数はどの程度の範囲であれば適切であるかを判断するために使用されます。

これを参考にすることで、開発内容に対して過剰なテスト数であったり、逆にケース数が足りない(低品質)といった問題を解消することが出来るのです。

そのため、1クラスの1行だけを修正するような開発の場合には、過去の開発を参考にしたうえで、どの程度のケース数が適切なのかを判断し、以前に実施したテストの中から、なるべく一通りのテストが出来るようにピックアップして、ノンデグレードテストのケースを作成することがポイントになると思います。

テストケースを作成するのは私にとっては設計を行うよりも難しく(どちらかといえば好きではない)、何をどこまでテストすればいいのか迷ってしまいますが、測定したテスト密度等を参考にして、適切な量のケースを作成しましょう。

※今回の記事でテスト密度を推しましたが、私的にはSTEP数で開発規模を判断するのはあまり好きではありません。が、今の現場ではそれ以外の基準がないのが現状で、今後何かもっと適切な(FP等組み合わせたもの?)尺度が作成できればと考えております。
フッター広告

スポンサードリンク



シェアする

  • このエントリーをはてなブックマークに追加

フォローする