ソフトウェアテストの論争

責任あるソフトウェアテストとは何かについては、ソフトウェアテストのライターやコンサルタントの間でも意見が分かれています。コンテキスト駆動型アプローチ^[1]の支持者は、ソフトウェアテストに関する記述の多くを教義と見なしていますが、一方で、これはIEEE 829のドキュメント標準に反すると考える人もいます。^[2]

コンテキスト駆動型アプローチの支持者は、テストのベストプラクティスは存在せず、むしろテストは、テスト担当者がそれぞれの固有の状況に合わせてテストプラクティスを選択または考案できるようにする一連のスキルであると考えています。James Marcus Bach は、「コンテキストに関係なく、他のすべての可能なプラクティスよりも優れたプラクティスは存在しません」と書いています。^[3]しかし、一部のテスト実践者は、「ベストプラクティス」の概念に問題があるとは考えておらず、その用語がプラクティスが普遍的に適用可能であることを意味しているとは考えていません。^[4]

1990 年頃、テストに関する新しいスタイルの執筆が、従来のアプローチに挑戦し始めました。この分野での独創的な研究は、Cem Kaner による「Testing Computer Software」とよく言われます。^[5]テスターがソース コードと完全な仕様に完全にアクセスできるという前提の代わりに、Kaner やJames Bachを含むこれらの著者は、テスターは不確実性と絶え間ない変化の条件下で作業することを学ばなければならないと主張しました。一方、プロセスの「成熟」に向かう反対の傾向も、能力成熟度モデルの形で広まりました。アジャイル開発プロジェクトで実践されるテスト方法を含むがこれに限定されないアジャイル テストの動きは、主に商業界で人気があり、CMM は政府および軍事ソフトウェア プロバイダーによって採用されました。

しかし、CMM のような「成熟度モデル」がアジャイル テストに対抗して普及した、あるいはアジャイル テストに反対していると言うのは正しくないかもしれません。アジャイル運動は「作業方法」ですが、CMM はプロセス改善のアイデアです。

しかし、別の観点、つまり組織の運用文化も考慮する必要があります。テスト担当者は不確実な世界で働く能力がなければならないのは事実かもしれませんが、その柔軟性には方向性がなければならないことも事実です。多くの場合、テスト文化は自己主導型であり、その結果、実りのない非生産的な結果が生じる可能性があります。さらに、欠陥の肯定的な証拠を提供することは、はるかに大きな問題のヒントを見つけたか、すべての可能性を使い果たしたかのいずれかを示す可能性があります。フレームワークはテストのテストです。フレームワークは、作業の能力を測定 (検証) できる境界を提供します。双方ともアプローチのメリットについて議論を続けてきましたが、真の測定基準は配信品質を評価することにあります。より広い焦点を置かずに体系的にテストすることは効果的ではない可能性があり、多数のエラーが見つかったとしても、必ずしもアジャイル手法が原因であるとは限らず、単に初期作業が不十分であったことを示している可能性があります。

探索的テストとは、学習を重視したテスト設計とテスト実行の同時実行を意味します。スクリプト化されたテストとは、学習とテスト設計がテスト実行の前に行われ、多くの場合、テスト実行中に再度学習を行う必要があることを意味します。探索的テストは非常に一般的ですが、テストに関するほとんどの文書やトレーニングではほとんど言及されておらず、一般的に誤解されています。一部のライターは、探索的テストを基本的で不可欠なプラクティスであると考えています。構造化された探索的テストは、テスターがソフトウェアに精通している場合の妥協策です。テストチャーターと呼ばれる漠然としたテスト計画が作成され、テストする必要がある機能は説明されますが、その方法は説明されないため、個々のテスターがテストの方法と手順を選択できます。

主に探索的テスト アプローチに関連する主な欠点は 2 つあります。1 つ目は、欠陥を防ぐ機会がないことです。これは、事前にテストを設計すると、構造化された静的テストの形式となり、システム要件と設計の問題が明らかになることが多い場合に発生する可能性があります。2 つ目は、テスト チャーターを使用しても、純粋に探索的テスト アプローチを使用してテスト カバレッジを実証し、テストの再現性を実現することが難しいことです。このため、スクリプト テストと探索的テストを組み合わせたアプローチは、各アプローチの欠点を軽減しながらメリットを享受するためによく使用されます。

一部の著者は、テスト自動化はその価値に比べて非常に高価であるため、慎重に使用すべきだと考えています。^[6]アジャイル開発の支持者などの他の人は、すべてのテストを100％自動化することを推奨しています。自動化の課題は、自動テストには自動テストオラクル（オラクルとは、ソフトウェアの問題を認識できるメカニズムまたは原則）が必要になることです。このようなツールは、ソフトウェアの負荷テスト（数百または数千のインスタンスが同時に存在するアプリケーションにサインオンする）やソフトウェアの断続的なエラーのチェックに価値があります。

自動ソフトウェア テストの成功は、完全かつ包括的なテスト計画にかかっています。テスト駆動開発などのソフトウェア開発戦略は、組織のテスト リソースの大部分を自動テストに充てるという考え方に非常によく適合しています。多くの大規模なソフトウェア組織は自動テストを実行しています。中には、再販用ではなく、特に社内開発用に独自の自動テスト環境を開発している組織もあります。

^{[非論理的]}

ソフトウェア テストが利害関係者のために製品またはプログラムに関する情報を収集することである場合、実装テストと設計テストのどちらかを選択できるというわけではありません。つまり、これは誤った前提です。^{[説明が必要]} 理想的には、ソフトウェア テスターはソフトウェア実装テストだけでなく、ソフトウェア設計テストにも限定されるべきです。この前提では、テスターの役割と関与は劇的に変わります。このような環境では、テスト サイクルも変わります。ソフトウェア設計をテストするために、テスターは設計者とプログラマーと一緒に要件と設計仕様を確認し、ソフトウェア開発の早い段階でバグを特定するのに役立ちます。

ソフトウェアテストの原則の 1 つは、ユウェナリスが提起した古典的なラテン語の質問 Quis Custodiet Ipsos Custodes (誰が番人を監視するのか) に要約されています。または、非公式には「ハイゼンベルク」概念 (ハイゼンベルクの不確定性原理と観察者効果を混同するよくある誤解) とも呼ばれています。その考え方は、あらゆる形態の観察も相互作用であり、テスト行為はテスト対象にも影響を与える可能性があるというものです。^[7]

実際には、テスト エンジニアはソフトウェア (場合によってはハードウェアまたはファームウェア) を他のソフトウェア (場合によってはハードウェアとファームウェア) とともにテストします。プロセスが失敗する原因は、ターゲットの欠陥ではなく、テスト ツールの欠陥 (または意図された機能) にある場合があります。

テストの有効性を測定するための指標が開発されています。 1 つの方法は、コード カバレッジを分析することです(これは非常に議論の多い方法です)。これにより、まったくカバーされていない領域について全員が合意し、これらの領域のカバレッジを改善できます。

バグはコードに意図的に配置することもできます。また、意図的に配置されたバグのうち発見されたバグの割合に基づいて、発見されていないバグの数を予測できます。問題は、意図的なバグが意図的でないバグと同じ種類のバグであると想定していることです。

最後に、過去のバグ発見率の分析があります。発見されたバグの数を測定し、それを予測数 (類似プロジェクトの過去の経験に基づく) と比較することで、テストの有効性に関する一定の仮定を立てることができます。これは品質の絶対的な測定ではありませんが、プロジェクトが半分完了していても欠陥が見つかっていない場合は、QA で採用されている手順を変更する必要があるかもしれません。