ソフトウェアを開発するうえでバグはつきものです。
しかし、バグが頻繁に発生していては利用者の満足度が下がります。バグを防ぐためにテストをおこなうのですが、バグには複数の種類があり、それぞれの特徴や対策法を把握することが重要です。
この記事では、バグの種類や発生する原因、対策などを詳しく説明していきます。
【一覧】ソフトウェアの「バグ」とは？
ソフトウェア開発において、予定通りの動きをしない場合バグとよばれることが一般的です。バグにも複数の種類があり、次のようにそれぞれ特徴によって違う言葉で使いわけるケースがあります。
ソフトウェアのバグには次のような種類があります。
- エラー
- フォールト
- 欠陥
この章では、それぞれバグの種類における特徴を説明していきます。
1.エラー
JSTQB（Japan Software Testing Qualifications Board、認定テスト技術者資格）の定義によれば、エラーとは間違った結果を生み出す人間の行為を表しています。つまり、エラーとは設計者や開発者といった人間がおこなった判断が間違っていることが対象です。
例えば、書かれた仕様書が十分でなかったり、例外処理をし忘れていたりするなどヒューマンエラーによるバグなどがエラーにあてはまります。
2.フォールト
IEEE（Institute of Electrical and Electronics Engineers）において、フォールトは「ソースコードのなかで生じる、人為的エラーのコード化」と表記されています。
そのため、欠陥が設定であるのに対して、フォールトは特にソースコードになんらかの問題があるといえるでしょう。また、フォールトは欠陥やバグと同じように使われる場合もあります。
3欠陥
欠陥とは、JSTQBにおいては「コンポーネントまたはシステムに要求された機能が実現できない原因となる、コンポーネントまたはシステムに含まれる不備」と表記されています。つまり設定や環境が原因であるといえるでしょう。
バグが起こる5つの原因
ソフトウェア開発においてバグはつきものです。バグが全くなくなることはないでしょう。
バグを出来る限り防ぐためにも、原因を把握することが重要です。バグにはさまざまな原因が挙げられますが、原因がわかっていれば対処しやすくなります。
バグが起こる原因として、主に次の5つの原因が挙げられます。
- 仕様書に不備があった
- 改修後の影響範囲が異なった
- テストの品質が低かった
- リグレッションテストを実施しなかった
- 環境の差異
1.仕様書に不備があった
仕様書に不備があるとバグの原因になる可能性があります。ソフトウェア開発は設計書や要件定義書といった仕様書を基準として進めることが一般的です。
しかし、仕様書に必要なテスト内容が含まれていないと、開発要件からも漏れてしまいます。仕様書に書いてあっても表現が曖昧で開発者に通じない場合、認識がずれることからテストケースが十分でなくバグにつながる可能性があるといっていいでしょう。
2.改修後の影響範囲が異なった
改修をしたあと影響範囲が異なりバグに繋がる可能性があります。つまり改修範囲が間違っていれば、仕様書に不備がある状態のまま開発を進めているのと同じような状況となってしまいます。
しかし、すべての影響範囲を見つけ出すことは難しいため、下記で説明するリグレッションテストをすることで解決につなげやすくなるといっていいでしょう。
3.テストの品質が低かった
テストそのものの品質が低いとバグが発生しやすくなります。テストを担当する人のスキルが足りていないことが原因で、テストの企画から観点、設計といったプロセスにおいて不備があれば十分なテストをできているとはいえません。
担当者に十分な技術があったとしても、十分な予算やスケジュール、ヒューマンリソースがとれず十分なテストケースをとれない可能性もあります。
4.リグレッションテストを実施しなかった
バグの発生を防ぐためには リグレッションテストの実施が重要です。リグレッションテストとは、テスト開発において一部分を変更したことによって、他の部分に影響がでないかどうかを確認することです。
改修部分の修正をおこなって対応できたとしても、他の部分においてバグが発生するケースは少なくありません。そのため、リグレッションテストはソフトウェアテストにおいて必要不可欠だといえるでしょう。
5.環境の差異
環境が異なることによってバグが発生する場合があります。本番環境においては、想定していなかったようなデータが登録されるなど、さまざまなバグが発生すると考えていいでしょう。
そのため、できる限り本番環境に近い状態でテストを行うことが重要です。実際にユーザーが利用してから大きなバグが発生すると顧客満足度の低下につながるため、テスト環境には注意するようにしましょう。
バグを発生させない5つの対策
バグが発生するとユーザーの評価が落ちてしまいます。ソフトウェア開発においてバグはつきものとはいえ、少しでもバグを減らすことが求められます。
バグを発生させないために次の 対策方法があります。
- 仕様書レビューの実施する
- 影響範囲の分析・レビューを行う
- テスト品質を向上させる
- リグレッションテストを実施する
- 本番環境にテスト環境を近づける
1.仕様書レビューの実施する
仕様書は必ずレビューを実施するようにしましょう。ソフトウェア開発は、仕様書を基にして進められます。そのため、仕様書にて漏れがあるとバグが発生しやすくなるのです。
前もってテスト担当者が仕様書レビューを確認して、開発担当者とあいまいな点や不明な点を認識合わせするとよいでしょう。仕様書レビューをすることで、テスト品質の向上につながります。
2.影響範囲の分析・レビューを行う
影響範囲が異なるとバグが発生する可能性があります。そのため 影響範囲の分析や レビューが重要です。仕様書レビューと同じように、テスト担当者と開発担当者が影響範囲について前もって認識合わせをするべきです。
しかし、すべての影響を確認することはできないため、リグレッションテストを随時おこなうことで、既存機能への影響を確認するようにしましょう。
3.テスト品質を向上させる
バグを発生させないためには テスト 品質そのものの向上が大切です。テスト品質を高めるためには、テスト方針から、体制、予定、観点、環境などテストに関連する必要事項を計画書にまとめます。
さらに、テスト設計において、デシジョンテーブルや境界線分析、同値分割などといった適切なテスト技能を活用することが重要です。
予定の都合に合わせてテストケースを間引きする場合もありますが、これまでの不具合実績などを確認して、発生時のリスクを確認するようにしましょう。また、リグレッションテストをすることでテスト品質の向上につながります。
4.リグレッションテストを実施する
バグを防ぐためにも リグレッションテストは効果的です。リグレッションテストとは、改修をおこなった時点でほかの部分において不具合が発生していないか確認をすることです。
近年のシステムやプログラムは複雑な構造であるため、前もってプログラムを改変したことによって、どのような影響があるのかを把握することは困難です。そのため、改変した時点でリグレッションテストをおこなうことが効果的といえるでしょう。
5.本番環境にテスト環境を近づける
システムを利用するにあたって環境が異なればバグが発生する可能性があります。そのため テスト環境を作る上で実際に本番で利用する環境に近づけることが重要です。
しかし、テスト環境で本番データを使ったり、テスト実行を本番環境でおこなうことはおすすめできません。必ず本番環境に近い状態でテスト環境をおこなうようにしましょう、
バグ発生時に復旧する4つの手順
バグが発生した場合に次の手順に置いて復旧させることが一般的です。
- 現状把握・問題検出
- 仮設立て
- コードを記載する
- 修正箇所の確認
1.現状把握・問題検出
バグが発生したらまず現状把握や現状検出が必要です。現状把握をする段階では、問題があったとしてもまだソフトウェアのバグとは限りません。
また、バグにもさまざまな種類があり、開発においてどのプロセスが対象であるかもわかりません。状況を明確にしないと対応ができないため、できるだけ詳細に事実確認をすることが重要です。
2.仮設立て
バグの現状把握ができたら次に復旧するための仮説を立てていきます。
仮説とは、このような状態になっているといった想定のことです。仮説を基にバグを修正できそうなソースコードを見つけたり、再現プログラムを書いたりするなどの対策を進めていきます。
仮説が間違っている場合があるため、仮説→検証といった流れを何度も繰り返すことが一般的です。
3.コードを記載する
バグを見つけた時点でコードを書いていきます。ここで注意をしたいのは、バグを修正したあとにバグが再発生しないようにテストカードを書くことが重要です。
この時、再現プログラムだけでなくユニットテストまで書くようにしましょう。また、影響範囲を最小限にすることも重要です。別のバグを仕込まないように気をつけましょう。
4.修正箇所の確認
修正が終わったら必ず確認をするようにしましょう。確認をする際に出来る限り検出者の感情に修正バチを当てただけの状況でおこなうことが重要です。
この時点で修正があったら対応する必要がありますが、再現をするのに負荷がかかりすぎたり、重要なシステムの場合は修正しない可能性もあります。この時点で修正がなければ、ソフトウェアテストの終了となります。
ソフトウェアバグの原因についてよくある3つの質問
ソフトウェアバグが起きる原因にはさまざまな種類があります。種類がわかっていても不明な点が残る場合もあるのではないでしょうか。
ソフトウェアバグの原因においてよくある次のような質問をまとめました。ぜひ参考にしてください。
- バグとエラーの違いは？
- バグの検出タイミングはいつ頃に行う？
- バグをなくすことはできますか？
質問1.バグとエラーの違いは？
バグとエラーは同じように説明されることがありますが、同じ意味ではありません。エラーとは開発者やテスト担当者などが、判断ミスをすることで起きます。ミスが発生するとバグにつながります。
例えばテスト設計をするときに、プログラムの動作を想定できていなかった場合バグが起こりやすくなるといっていいでしょう。ヒューマンエラーをエラー、システムやプログラムが欠陥していることをバグといいます。
質問2.バグの検出タイミングはいつ頃に行う？
バグの検出プログラムは、ソフトウェア開発において最終フェーズ、もしくは近い段階でおこなうことが一般的です。
また、リリースしたあともバグが発生する可能性があるため、運用後もバグの検出プログラムが必要です。開発時においては、バグの検出プログラムをおこない修正が不要になるまで修正を続けるようにしましょう。
質問3.バグをなくすことはできますか？
ソフトウェア開発においてバグはつきものであり、バグをなくすことはできません。
しかし、出来る限りのテストをおこないゼロに近づけることが重要です。バグを減らすためには、次に3点に力を入れるようにしましょう。
- ソフトウェアの質を挙げる
- 人材育成
- CI(継続的インテグレーション)
バグを減らすためにテストをおこない、質の高いテストをするための人材育成が重要です。
まとめ
バグとは、人間のミスにより起こったエラーが原因で発生する場合があります。ほかにも、想定できないようなバグが起きる可能性もあり、その都度対処が必要です。
ソフトウェアテストにおいてバグが見つからない状態になるまでリリースはできないことが一般的です。また、リリース後もバグが発生する場合があります。
