ソフトウェアのバグの家はどこだと思いますか？ 正しい、ソフトウェアで。 しかし、正確にはどこですか？
プログラムが正しく動作しないのはなぜですか？ それは非常に簡単です–彼らは人々によって作成され、使用されます。 ユーザーが間違いを犯した場合、これはプログラムの動作に問題を引き起こす可能性があります–それは誤って使用されます。
ヒューマンエラー
エラー–誤った結果を生成する人間の行動です。
しかし、ソフトウェアは間違いを犯すことができる（そして行う）人々によって設計され、作成されています。 これは、ソフトウェア自体に欠陥があることを意味します。 これらは欠陥またはバグと呼ばれます（両方の名称は同等です）。 覚えておいてください–ソフトウェアは単なるコード以上のものです。
ソフトウェアの欠陥またはバグ
欠陥、バグ–特定の機能の障害につながる可能性のあるコンポーネントまたはシステムの欠陥。 プログラムの実行中に発見された欠陥は、個々のコンポーネントまたはシステム全体の障害を引き起こす可能性があります。
プログラムコードの実行中に、書き込み中でも埋め込まれた欠陥が表示されることがあります：プログラムは、それがすべきことをしないことがあり、その逆もあります–それがすべきではないことをし、クラッシュが発生します。
ソフトウェアの障害またはクラッシュ
障害またはクラッシュは、コンポーネントまたはシステムの操作の実際の結果と予想される結果との間の不一致
プログラムの障害は、その中に欠陥があることを示す指標となり得る。
したがって、三つの条件が同時に満たされたときにバグが存在します:
- 期待される結果は既知です。
- 実際の結果は既知です。
- 実際の結果は予想される結果とは異なります。
すべてのバグがクラッシュを引き起こすわけではないことを理解することが重要です。
障害は、欠陥だけでなく、環境条件によっても引き起こされる可能性があります。
合計で、いくつかの欠陥の原因があり、それに応じて失敗します:
- ソフトウェアシステムの仕様、設計または実装におけるエラー;
- システム使用エラー;
- 不利な環境条件;
- 意図的な害;
- 以前のエラー、条件、または意図的な
欠陥はさまざまなレベルで発生する可能性があり、システムの品質は修正されたかどうか、いつ修正されたかによって直接異なります。
品質–固有の特性のセットが要件を満たす程度。
ソフトウェア品質は、明示的および黙示的なニーズを満たす能力を反映したソフトウェアの特性のコレクションです。 要件は、確立された必要性または期待です。 通常は想定または必要です。
最初のケースでは、すべてが正しく行われ、お客様の期待を完全に満たし、品質基準を満たした製品を受け取りました。
後者のケースでは、コーディング中にすでにエラーが発生し、完成品に欠陥が現れました。 しかし、このレベルでは、バグを見つけて修正するのは非常に簡単です。
第三の選択肢は悪いです–ここではシステムの設計段階で間違いがありました。 これは、仕様を徹底的にチェックすることによってのみ気付くことができます。 このような欠陥を修正することも容易ではありません–あなたは製品設計を再設計する必要があります。
第四のケースでは、欠陥は、要件形成の段階で敷設されました; すべてのさらなる開発、さらにはテストは、最初は間違った道を下って行きました。 テスト中、バグは見つかりません–プログラムはすべてのテストに合格しますが、顧客によって拒否される可能性があります。 これについての詳細は、オンラインQAクラスと認定で学ぶことができます。
従来、プログラムコードに欠陥が出現する理由は五つあります。
- チームコミュニケーションの欠如。 多くの場合、ビジネス要件は単に開発チームに到達しません。 顧客は完成した製品をどのように見たいかを理解していますが、彼らのアイデアが開発者やテスターに適切に説明されていないと、結果が期待どおり 要件は、ソフトウェア開発プロセスのすべての参加者が利用可能で理解できるものでなければなりません。
- 現代のソフトウェアは、複雑なソフトウェアシステムに結合された多くのコンポーネントで構成されています。 マルチスレッドアプリケーション、クライアントサーバー、分散アーキテクチャ、多層データベース-プログラムの作成と保守がより困難になり、プログラマの仕事がより困難になってきています。 そして、より困難な作業、それを実行する人が作ることができるより多くの間違い。
- 要件の変更。 開発の後半に要件を少し変更しても、システムに変更を加えるには多くの作業が必要です。 アプリケーションの設計とアーキテクチャは変化しており、ソースコードとソフトウェアモジュールの相互作用の原則を変更する必要があります。 これらの進行中の変更は、多くの場合、微妙な欠陥の原因です。 それにもかかわらず、現代ビジネスの頻繁に変更の条件は例外より規則である、従ってそのような条件の連続的なテストそして危険管理は品質保証部の直接責任である。
- 文書化されていないコード。 不十分に書かれ、不十分に文書化されたコードを維持し、変更することは困難です。 多くの企業は、プログラマによるコードの記述と文書化のための特別なルールを持っています。 実際には、開発者が最初にプログラムをすばやく書くことを余儀なくされることがよくありますが、これは製品の品質に影響します。
- ソフトウェア開発ツール。 レンダラー、ライブラリ、コンパイラ、スクリプトジェネレータ、およびその他の開発支援も、完成した製品の欠陥の原因となる可能性のあるプログラムの
