ソフトウェアテスト
決定表(デシジョンテーブルとも)とは、条件(入力)が複数のパラメータから構成されている場合に、 条件(入力)と動作(入出力)の関係を表形式で表したものである。 表の各列が規則(テストケース)を表している。
プログラムを実際に動かしてみて行うテストを動的テストと呼び、プログラムを実際に動かしてみることなくソースコードやオブジェクトコードを検証する作業を静的テストと呼ぶ。静的テストには、ツールを用いた静的コード解析の他に、人手で行うコードレビュー、ウォークスルー、インスペクションなどがある。多くの場合、意識されることはないが、コンパイラまたはプリコンパイラはソースコードを静的にテストする。
ソフトウェアが複雑になり、機能、関数の数が千以上になってくると、性能試験、機能試験の結果を統計的に処理し、どういう試験を実施するとよいかを統計的に検討することがある。また、テストでは、欠陥が存在することを示すことはできるが、欠陥が存在しないことは証明できないため、いつソフトウェアテストを終了すればよいかを決定するための基準として統計的手法として信頼度成長曲線等を利用する場合がある。信頼度成長曲線を利用する場合には、条件の変化を統計的にうまく扱わないと見落としが発生するか、無駄な作業を続けることがある。
プログラムを修正・変更した場合に、過去に実施したテストを再度実施することを回帰試験 (英: regression test) 又は退行テストという。修正前の試験に再度合格するかどうか、他の機能に影響与えていないかどうか、他の機能が動作するかどうかを確認する。過去のテスト資産を使い、実施する回数も多いことから、実施を省略することがないようにテスト自動化することにより効率化を図る。
回帰試験にて、テストする範囲を全テストケースとするか、(全テストケースを実施した場合に要する時間や工数と修正が及ぼす範囲を考慮して)部分テストケースとするか判断し、また、欠陥を検出する頻度を考慮して高い優先度で実施するテストケースを選択する方法がある。一方で、アジャイル開発手法を選択した場合、ソフトウェアの更新頻度も仕様変更頻度も共に高くなることが見込まれるため、特に開発期間が短いアジャイル開発手法においては、回帰試験が多くの不必要なオーバーヘッドになる可能性がある。回帰試験をサードパーティーに委託する場合、あるいは、ソフトウェアの一部がサードパーティーによって開発される場合、必ずしも修正が及ぼす範囲が判断できるわけではないので、テストする範囲は全テストケースと成らざるを得ない。
ソフトウェアテストは「変更への信頼」を生むことでソフトウェアの品質・提供速度を向上させる目的・効果を持つ。
ソフトウェアの変更(例: リファクタリング・機能追加)は既存コードの破壊によるバグ(リグレッション)を引き起こしうるため、ソフトウェアエンジニアに対し、コード変更への心理的ハードルとして作用する。このハードルは変更への躊躇いを生み、品質向上の機会を減少させてしまう。
リグレッションテストはコード変更によるバグを発見して欠陥の作りこみを防止し、品質に対する信頼を積み増す。この効果により、新たな変更が既存コンポーネントを破壊しないという信頼(confidence)・安心がエンジニアに生まれる。結果として良い変更の頻度があがり、ソフトウェアの品質・提供速度が向上する。
ただし、一度書かれたソフトウェアが「決して変更されない」場合にはこの効果が発揮されない。(参考: テスト駆動開発)
機能試験・性能試験の指標と分類にISO/IEC 9126 (ISO 9126) の枠組みを利用することがある。