リリース後に不具合が発生するケースや要因とは 不具合を多発させない方法もご紹介

  • ソフトウェアテスト・品質保証

リリース後に不具合が発生するケースや要因とは 不具合を多発させない方法もご紹介

お役立ち資料

Introduction

ソフトウェアは社会生活にとって必要不可欠なものとなっており、リリース後に不具合が発生することはユーザーへの影響のみならず、ビジネスや社会にも大きな影響を与えてしまいます。そのため、ソフトウェア開発にとっては、リリース後の不具合をいかに防ぐかが重要な視点の一つといえます。一方、ソフトウェアの規模が大きくなるとより複雑な機能が組み込まれるため、不具合の発見が難しく、結果として不具合が混入したままリリースされるリスクは高まります。
リリース後に不具合が多発するのを防ぐ方法として、本来は、上流工程から品質のつくり込みを行い、ソフトウェアの品質を高めることが重要ですが、予算や納期の都合で十分な工程を設けることができない場合も多いのではないでしょうか。そこで、今回は、最終的なテスト工程でいかに不具合を防ぐかという観点に絞って解説したいと思います。

目次

不具合が発生するケース

まず、不具合が発生するよくあるケースを紹介しておきます。

●リリース前に必要な各種テストを行い、未然に不具合を防いだつもりだったが、テストでの抜け漏れが存在し不具合が発生した。
●改修範囲外において、想定外の不具合が発生した。
●デグレードによる不具合が継続的に発生している。
●テスト環境では問題なかったが、本番環境では不具合が発生した。

不具合が発生するケースはほかにもさまざまあるかと思いますが、今回はテスト工程で不具合をいかに防ぐのかを解説することを目的としていますので、早速これらが起きる要因について探っていきます。

不具合が起きる要因

上記の問題の背景には、おもに以下のような要因が想定されます。

1)仕様書の不備

ソフトウェア開発は、仕様書(要件定義書、設計書など)をもとに行われますが、その仕様書自体に記述すべき内容の抜け漏れがあると、当然開発要件から漏れてしまいます。また、仕様書におけるあいまいな表現は、開発担当者とテスト担当者の認識のずれを生み、結果として、テストケースに漏れが出てしまう要因ともなります。

2)改修による影響範囲の考慮漏れ

改修時には当該改修による影響範囲を分析し、プログラムの改変を行いますが、影響範囲に含めるべき部分を漏らしてしまうと、上記1)と同じ現象が発生してしまいます。一方で、すべての影響を洗い出すことも不可能なため、下記4)で述べるリグレッションテストの活用が必要となります。

3)テスト自体の品質が低い(または粒度不足)

テスト担当者のスキル不足により、テスト計画、テスト観点、テスト設計などに漏れや不備があり、十分なテストが行われていない可能性があります。また、テスト担当者に一定のスキルがあっても、リリースまでのスケジュール、要員、予算などの都合でテストケースを間引き過ぎてしまい、結果として、必要な粒度でのテストが実施できていない場合もあるかと思います。

4)リグレッションテストが未実施(または不十分)

改修部分のテストを入念に行って問題がないことを確認したのに、改修の影響でこれまで正常に動作していた機能に不具合が出ること(デグレード)には、気をつける必要があります。上記2)で影響範囲を分析しても、すべての影響を把握するのは不可能です。リグレッションテストを行わないのは、大きなリスクになるといえます。

5)テスト環境と本番環境の差異

テスト環境と本番環境にはどうしても差異が生じがちです。特にデータにおいて、本番環境には、想定外のデータが登録されることによる不具合などが発生することがあるため注意が必要です。

 

以上のような要因によって、不具合は発生しがちだといえます。気をつけたつもりでも、どうしても不具合が起きてしまうという方も多いかと思いますので、次にここで紹介した要因への対策について解説していきます。

不具合を起こさないための対策

上記それぞれの要因への対策としては、以下の内容が考えられます。

1)仕様書のレビュー

テスト担当者が仕様書のチェックを行い、開発担当者(できればシステム全体を把握している有識者を含め)と、不明点やあいまいな記述に関してQ&Aなどを行い、仕様書の抜け漏れの確認や認識合わせを行っておくといいでしょう。それにより、テスト計画やテスト設計などの品質の向上にもつながります。

2)影響範囲分析のレビューとリグレッションテストの実施

影響範囲に漏れがないか、という観点でのレビューや開発担当者(できればシステム全体を把握している有識者を含め)との認識合わせについては、上記1)と同様ですが、すべての影響を把握することは不可能なため、既存機能への影響についてリグレッションテストで確認することが有効です。

3)テスト品質の向上

まずは、テスト計画において、テスト方針、テスト観点、スケジュール、体制、テスト環境、不具合管理など、テストを行ううえでの必要事項をテスト計画書にまとめておきます。次に、テスト設計においては、「同値分割」、「境界値分析」「デシジョンテーブル」などのテスト技法を適切に使用することが重要です。特に、「デシジョンテーブル」は、複雑な条件や複数の条件の組み合わせを整理することができ、網羅性を可視化して抜け漏れのないテスト設計に有用です。
効率的なテスト実施やスケジュールの都合などでテストケースの間引きも必要ですが、まずは、網羅的にテストケースを作成し、不具合発生時のリスクや、機能の重要度、過去の不具合実績などを勘案して間引いていきましょう。また、アドホックテストによるテストケース以外での不自然な挙動の確認や、下記4)のリグレッションテストによる既存機能の確認も実施したいところです。
最後に、テスト計画書、テスト設計書などに関しても、開発担当者(できればシステム全体を把握している有識者を含め)にレビューを行い、テスト担当者との認識を合わせておくのは、上記の1)、2)と同様に重要です。

4)リグレッションテストの実施

昨今のプログラムやシステムは、一つ一つの機能が複雑に絡み合っているため、開発担当者でもプログラム改変によるすべての影響を把握するのは困難というのは前述の通りです。テスト計画において、必要なリグレッションテストの工数を確保しておきましょう。

5)可能な限り本番環境に近い環境でテスト

テスト環境を可能な限り本番環境に近い状態(データも含め)でのテストをおすすめします。ただし、テスト環境への本番データの投入や本番環境でのテスト実行はおすすめできません。

まとめ

今回は、リリース後の不具合の多発をテストによって防ぐ、という実践的な観点で下記の5項目に絞って解説しました。

1)仕様書のレビュー
2)改修による影響範囲分析のレビュー
3)テスト品質の向上
4)リグレッションテストの実施
5)本番環境に近い環境でのテスト実施

もちろんこれをやれば、十分という訳ではありませんが、もし解説した項目のなかに現状で対応が不足しているところがあればぜひ試してみてください。
一方で、不具合をすべて防ぐのは難しいというのが実情です。しかも、それをテストだけで防ごうとするのも本質的な対応とはいえません。やはり、冒頭に述べたように、上流工程からの品質のつくり込みによるソフトウェアの品質向上は重要だということを忘れないようにしましょう。

資料ダウンロード/動画視聴

関連コラム

Top
緊急アイコン

緊急対応が必要な方

お客様からクレームが発生している、不具合が頻発しているなど、緊急で対策が必要な方はすぐにご連絡ください。

TEL 0120-142-117

受付時間 平日9:00 - 18:00

TEL 03-6809-2979

フリーダイヤルをご利用できない場合は、
上記電話番号におかけください。