PMマガジン

「デグレードとサヨナラ」～ようこそ！ノンデグの世界へ～

2014年11月号 品質 OCP－プロジェクトマネジャー(L5)　　 横満　仁

皆さんはWebアプリやスマホアプリを開発した際や利用した際、以前の方が使い勝手が良かった、バグが多くなったというデグレード直面経験はありませんか。
『デグレード』とサヨナラをしたいのがＰＭの本望。私もそのうちの一人です。

===============================================
『デグレード』を起こすと・・・
===============================================
アプリのバージョンアップに伴い、機能向上・品質向上が期待されますが、その期待に反して修正部分以外の既存機能に不具合が出るため、利用者側の心証をより悪くします。
「今までちゃんと動いていたのに、全く関係のないこの機能がなぜバグるんだ！」とお叱りを受けることになります。

===============================================
『デグレード』は厄介モノである
===============================================
自分の施した修正が自担当以外の箇所に悪影響を及ぼしていないことを自分で検証することすら難しいのに、他人の施した修正が自担当変更箇所や既存部分に悪影響を及ぼしていないことを自分やアプリ保守担当者が検証することはなお難しく、マルチベンダー開発体制の場合はよく発生する問題です。

開発時のコーダーやテスターが引き続き保守しているのであれば、自担当のコードが今回の改修によって潰されていないか？という観点でチェックできますが、そのような恵まれた環境が長期間継続することは稀です。

===============================================
『デグレード』とサヨナラ
～デグレード撲滅対策（退行テスト工数削減対策）～
===============================================
この厄介モノを撲滅するため、膨大なプログラム全てに対し、退行テストを手当たり次第にテストするには時間的な限界があります。
ではどうしたら良いでしょうか。

Ａ）標準テストケースと標準データ、想定結果の３点セットを用意しておく

退行テスト開始時に標準データをインポートし、標準テストケースを消化していきます。改修の度に標準テストケースと標準データの更新が必要となりますが、それでも都度、イチからバリデーションを考え、テストケースを練り、データを準備する方法と比べると格段に少ない工数で済みます。
使い捨てを止め、蓄積、再利用を繰り返すことで、ナレッジとして共有し、チーム資産にまで成長させるのです。

問題点もあります。既に保守フェーズに入っているシステムの場合、まずは３点セットを作る必要がありますが、一度作ってしまえば、その先は改修が入るタイミングが３点セットの更新タイミングと見做せるので、構成管理対象に含めてしまえばよいのです。
法改正やH/W・S/Wリプレースなどの定期的に手が入る案件に限定し、中長期的視点で全社を挙げて取組めば、初期の費用捻出の問題はありますが、その後は長期に渡って相当なリターン(品質向上と工数削減)が見込めます。

Ｂ）退行テストツールを利用する

テストスクリプトを作成し、テスト実施作業を自動化し、前回実行時の結果と比較します。結果差異が検出されれば、デグレード発生箇所を特定できたことになりますし、他にも以下のメリットが存在します。
・テストユニークである入力ミスや結果検証ミスを抑制　⇒人為的ミスの排除
・テスト実施時間の短縮　⇒テストの効率化
・OSバージョンアップ、ミドルバージョンアップ、マルチブラウザ対応、ブラウザバージョンアップ対応後の動作確認にもツールの使い回しが可能

Ａ＋Ｂの合わせ技＝デグレードとサヨナラ（理想論ですが）

===============================================
デグレードしていないという最後の太鼓判がほしい
===============================================
アプリ開発の世界に絶対は存在しませんが、フェーズ完了判定会議にて次フェーズへ移行を認める際の判断材料を増やしたり、リリース判定会議や品質報告書において、第３者への説得力を持った主張をしたいのはＰＭなら誰もが抱く思いです。「絶対にデグレードしてません」と自信を持って言い切れるＰＭは数少ないのではないでしょうか。

そうであれば、指標を作ってはどうかというのが私の提案です。
例えば、
システムテスト項目数に占める『退行テスト』項目数の割合を指標化するのです。その割合がこのスパンに入っていればよしという１つの判断基準を作るのです。

言語や要員スキル、改修するソースのボリュームといった一概には決められない変動要素は沢山あるのは頷けます。しかし、「テストケース密度」や「バグ検出密度」と同じように指標化することによって、多かれ少なかれ品質向上に寄与でき、デグレード発生数を減らしていけるのではないでしょうか。
複数のプロジェクトの計測結果を収集し、品質指標として定量化する。そしてＰＭは定量化された数値が、判断基準をクリアしていることを確認することでデグレードしていないという太鼓判を得ることができ、安心感を得られます。

皆さんなら『デグレード』とサヨナラする日をいかなる方法でＧＥＴしますか？
退行テストを侮るなかれ。

＜用語の定義＞
１．『デグレード』とは
以前修正した不具合やバグが再発・復活したり、ある部分に施した修正が既存部分に影響を与えることで新しいバージョンのソフトウェアの品質が、以前より悪くなること。
『退行テスト』とはデグレードしていないかをテストすることと同義である。

２．『退行テスト』とは
ある部分に施した修正が既存部分に予期しない悪影響を及ぼしていないこと、つまり、修正を施していない既存機能がそれをリリースした当時と全く同じように動作するかを確認するテストのこと。

なお、以下のテストも同義語として扱われます。
・回帰テスト、再帰テスト、リグレッションテスト、レグレッションテスト、ノンデグテスト、無影響確認テスト

＜退行テストツールのご紹介＞
・Rational Functional Tester(IBM)
・anyWarp Capture/Replay(Hitachi)
・Selenium（OSS）

PMマガジン一覧へ