デグレードを検出するには?

キットワークスの木下です。

 

ソフトウェアテストでは、新規プロダクトよりもバージョンアップや不具合修正などによるアップデーターのテストをすることが多くなります。

そこで大きな問題となるのが「デグレード」

簡単に説明すると、今まで動いていたものが動かなくなってしまうということです。

ソフトウェアの規模にもよりますが、致命的な問題が紛れ込みやすいのがこのケースで、会社員時代の経験ではメニューから基本的な機能を実行するだけで強制終了するような問題を残したまま出荷したことも……

 

ソフトウェアテストの作業量を考えるとき、「変更内容に対していくら」という見積もりをします。このため、小さな変更では少ない作業量しか与えられないのが通例。可能な限り既存の機能を一通り動かすテストは行いますが、条件を網羅するような編集データを組み合わせたりすることは自動化でもされていない限りできないでしょう。

実際には、変更によって無効になったテスト結果を全て網羅すべきなのですが、費用対効果を考えると現実的ではないのです。

 

では、どのようにしてデグレードを検出するのか?

当社では以下のような方法がベストと考えています。

  • 変更内容から分析する
    • 利用する値の種類を網羅:プログラム修正時に仕様を把握していない関数呼び出しを追加した場合、その引数がヌルだったケースや大きすぎる場合のケースをテストする
    • 関連する操作の種類を網羅:プログラム修正時にクラス構造(引数など)を変更した場合、その構造を期待する他の機能をテストする
  • 全体傾向からアプリ固有の特徴を見つめ直す
    • 表示処理の発生するケースを網羅:画面と印刷の違いや、保存したファイルの読み込みなどをプログラムの修正される前と後で比較し、修正内容の意図通りかを第三者の目で確認する
    • 基本編集操作の網羅:コピー・貼り付け・移動など、関連する編集操作を別の目的に切り替えて実施する(属性コピーを修正した>>データコピー動作が正しいか?)
    • 機能要件の再確認:ソフトウェアが本来どういう目的で作られるものだったかを、不具合修正内容に近い内容で1行程度の要約にしてすべて並べ、俯瞰し、修正度合いの大きい機能を基本テストから見直す

上記すべて実施してもデグレードを100%検出できるわけではありませんが、やみくもに作業するよりは確率が高くなります。

実際の現場ではプログラム修正の影響範囲が想定困難になると「全体的にテストしてくれ」などといわれることもありますが、そんな指示で問題点を見つけ出す可能性は極めて低いです。

そもそも、開発者が修正内容に不安を抱くようなものではデグレードチェックはできていることが多く、逆に修正内容に自信を持っている場合の方がデグレードしていることが多いのです。

 

テスター側でのデグレードの発見は困難を極めるため、プログラムを実装する側がリスクをよく理解して実装することが一番のデグレード防止になります。

このため、テストを重視するよりもしっかりとした変更管理が重要です。検索が遅かったり目的のチケットが見つけにくいバグトラッカーとかはもう最悪…

 

キットワークスでは開発現場に応じた最適なシステム提案などノウハウもご提供します。まずはお問い合わせください

 

コメントを残す