不具合を早く見つけたいというのは、テスト担当者に共通の悩みだろう。限られたスケジュールや工数の範囲内でシステムにとって重要な不具合を早期に検出するには、ターゲットを絞らないやみくもなテストではうまくいかない。不具合を狙い撃ちするテストが求められる。

 限られたスケジュールや工数の中で効果的なテストをするには、不具合が潜みやすい場所を狙ったテストを実施したい。今回は2つの方法を紹介する。

 1つめは、リリース後に発生する不具合に対して分析を行い、テスト方針に反映していく方法である。不具合の質と量を分析して製品の弱点を見つけ出す。弱点に応じてテストを手厚くしたりすれば、効率的に不具合を検出できる。

 2つめは、ユーザーによる想定外の操作に起因する不具合の検出を狙った「意地悪観点」のテストだ。開発者が設計時に想定していない使い方というのは、不具合が潜みやすい。思わぬ動作をしたり、最悪の場合にはシステムが異常終了したりする。そこで、開発者が想定していないであろう意地悪な観点のテストを実施して、システムの動作を確認する。

 ただ、不具合分析も意地悪観点テストも進め方を知らないと、意味のない作業になってしまう。今回はこれらの効果的な実施方法を解説しよう。

修正が終わらない
不具合の傾向を分析して狙い撃ち

 ようやく新しいパッケージ製品のリリースにこぎつけたが、エンドユーザーから「システムメッセージに誤字がある」「画面の出力値が文字切れしている」といった問い合わせやクレームが相次いでいる。改修を続けているものの、なかなか問い合わせやクレームが減らない。リリースしてから半年がたつが、不具合改修に多くの時間を取られ、終わりが見えない―。

 パッケージ製品やクラウドサービスの開発で起こりがちな光景だ。問い合わせやクレームがいつまでも収束せず、不具合改修、テスト、修正版のリリース予定日の交渉といった作業に忙殺される日々が続く。

 なぜこうした状態に陥るのか。製品やサービスのリリース後、場当たり的に不具合対応をしているからだ。不具合のクレームがあったら、テストと修正で不具合に対処してリリースをする。この際、本来ならば不具合の分析を実施して、それをテストに反映しなければならない(図1)。不具合分析をできていれば、テストで類似の不具合を効率よく見つけ出せる。

図1●リリース後の不具合修正では不具合分析が必須
[画像のクリックで拡大表示]

 だが、多くの現場は不具合の分析が不十分だ。製品の品質状況や弱点を把握しないまま、いつも同じようなテストを実施している。これでは、以前のテストで見つけられなかった不具合は、その先もずっと見逃し続けることになる。

 不具合の混入は上流工程で防げた方がよく、その方法を検討すべきだ。だが、いったん埋め込まれてしまった不具合はテストと改修で対応するしかない。そこで、深刻なクレームにつながる不具合をリリース後に減らす、不具合分析の方法と分析結果をテストに反映する方法について解説しよう。

リリース後の対応を効率化する3ステップ

 リリース後の不具合改修で問い合わせやクレームが止まらなくなる要因は大きく2つある。

 1つめはテストの優先順位の考慮不足だ。システム開発の中で実施するテストでは、機能に関わる不具合をつぶす方向に意識が傾く。時間、人員が限られていると、どうしてもユーザーインタフェース(UI)の確認は後回しになりがちだ。リリース後の不具合対応でも同じようなテストを実施していると、エンドユーザーの目に付きやすいUIに関わる不具合を素通りさせてしまう。

 画面上の文言の誤字脱字のようなUIに関わる不具合は、確かに機能には影響しない。だが、軽視すると痛い目に遭う。エンドユーザーの目に付きやすいからだ。エンドユーザーは「見ればすぐに分かるのになぜ直さないのか」という疑問を持つ。疑問は「この製品は大丈夫か」という不安につながり、製品への信頼を低下させる。ユーザーから見ると、信頼できない製品はどんな不具合も深刻な問題に見える。その結果、クレームがクレームを呼ぶ。

 2つめは問い合わせやクレームの傾向を、開発者やテスト担当者が把握できていないことだ。一般に、エンドユーザーからの問い合わせはコールセンターや営業部門が受ける。問い合わせを受けた部門が取りまとめ、改修してほしい不具合を整理して開発部門に依頼する。この業務フローは一見効率的だが、重要な情報が抜け落ちやすい。「UIに関する問い合わせが多数来ている」といった、問い合わせの傾向が開発部門に伝わらないケースが多いのだ。

 2つの要因をそのままにしておくと、製品のどの部分に品質上の問題があるのか、どの部分を優先して品質担保すべきかが明確にならない。こうした状態で不具合対応を続けると、冒頭のような不具合対応が収束しない状況に陥る。この課題に対する解決策として、筆者は次の3ステップの実施を推奨している。

STEP1 不具合の傾向を可視化する
STEP2 テスト観点とひも付ける
STEP3 結果を次のテスト方針に反映する

 STEP1ではエンドユーザーからの問い合わせ情報から不具合の傾向を分析する。STEP2では不具合とテスト観点のマッピングを実施する。STEP3では分析結果を次バージョンのテスト方針に反映して品質の改善を図る。以下、3つのステップを詳しく説明しよう。

この先は有料会員の登録が必要です。「日経SYSTEMS」定期購読者もログインしてお読みいただけます。有料会員(月額プラン)は初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら