2021.11.04

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

著者株式会社SHIFT　マーケティンググループ

Introduction

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

不具合が発生するケース～よくある不具合～

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

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

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

不具合が起きる主な5つの要因

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

1）仕様書の不備

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

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

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

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

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

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

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

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

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

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

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

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

1）仕様書のレビュー

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

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

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

3）テスト品質の向上

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

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

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

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

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

ソフトウェアテスト入門講座

※ご登録いただくとその場で無料動画の視聴が可能です。
株式会社SHIFTが運営するソフトウェアテスト・品質保証の人材育成を手掛けるヒンシツ大学のお試し講座「ソフトウェアテスト入門」をご視聴いただけます。ソフトウェアテストの目的、役割といった基礎知識を学びたい方におすすめの入門動画です。

ダウンロード

まとめ

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

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

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

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

ソフトウェアテスト入門動画

テスト計画入門動画

SHIFTサービス資料

テストサービス導入事例集

この記事を書いた人

著者株式会社SHIFT　マーケティンググループ

SHIFTは「売れるサービスづくり」を得意とし、お客様の事業成長を全力で支援します。無駄のないスマートな社会の実現に向けて、ITの総合ソリューションを提供する会社です。

サービスサイト：https://service.shiftinc.jp/
コーポレートサイト：https://www.shiftinc.jp/
X（旧Twitter）：https://twitter.com/SHIFT_cp

ご支援業種

製造、金融（銀行・証券・保険・決済）、情報・通信・メディア、流通・EC・運輸、ゲーム・エンターテイメント

など多数

前のページへ

次のページへ

コラム一覧に戻る

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

Introduction

不具合が発生するケース～よくある不具合～