テストについて知っておくべきこと
テストはテストの実装と言われることがありますが、これはソフトウェアとテストの実行のことを意味しています。テストの実装には、作ったソフトウェアを実際に動かして動作を確認するテストだけでなく、要件定義書、機能仕様書、ソースコードのレビューなど、様々なテストがあります。 テストの主な目的には以下のようなものがあります ・テストエラーを見つけること ・品質管理 ・製品の決定をサポートするための情報 (リリースされたかどうかなど) を提供すること ・エラーの発生を防ぐこと テストとデバッグの違いとはなんでしょうか。テストはエラーを見つけることです。デバッグはエラーの原因を見つけて修正することです。テストの責任は一般的にテスターにありますが、デバッグの責任は開発側にあります。 A> テストの７原則 原則1：テストは欠陥があることしか示せない テストを通じて、ソフトウェアにエラーを見つけることはできますが、完全にエラーが起きないということを示すことはできません。テストをして故障が起きなかった場合、本当にそのソフトウェアに欠陥がなかったのかもしれませんが、偶然エラーが起きなかっただけの可能性があります。テストではソフトウェアのエラーを減らすことはできますが、エラーがなかった場合でも、そのソフトウェアが欠陥が無いということは証明できないのです。 原則２：全数テストは不可能である 全数テストとは、ソフトウェアに入力する可能性のある全てのパターンをテストすることです。データが膨大になり過ぎてしまう為、非常にシンプルなソフトウェアを除いてこれは一般的に不可能です。実際のテストでは、全てのケースをテストする代わりに、ポイントを絞ってテストが行われています。 原則３：できるだけ早くテストする バグの発生を防ぎ、バグを早く発見する為に、ソフトウェアの開発の段階からテストを進めるべきです。 原則４：エラーの偏在 ソフトウェアのエラーは特定のモジュールに集中していることが多いことから、過去の分析結果などを参考にしながら、テストの焦点を絞るのが良いとされています。 原則５：農薬のパラドクス 農薬を使っていると、そのうち害虫が耐性を持ち、効かなくなってくるのと同じように、ソフトウェアテストにおいても、同じテストを繰り返している中で、そのテストでは新たなエラーが見つからなくなってきます。これを回避する為に、定期的にテストケースを見直して、変更していく必要があります。 原則６：テストは要件次第 違う要件の下では、テストのやり方は変わってきます。例えば、銀行のシステムとウェブサイトでは、テストのやり方は完全に違います。ソフトウェアが使用される状況や目的に合わせてテストのやり方は変える必要があります。 原則７：「バグゼロ」の落とし穴 システムのテストエラーが起きないようにすることに集中しすぎて安心してはいけません。テストの工程の中で、欠陥を修正したことによる影響範囲や、新たな欠陥が無いか確認しないといけないからです。 B> 基本的なテスト段階 １、テスト設計とコントロール テスト設計は、テストの目的と仕様の決定作業です。 テスト制御とは、テスト中の計画と進捗を比較する作業です。 ２、テスト分析と設計 抽象的な要件を特定のテスト条件またはテスト設計に変換します。 具体例： ・リスク分析レポート、インターフェース仕様などのテストベースのレビューなど ・優先度を指定してテストケースを設計する ・必要なテストデータを分類する ３、テスト実装とテスト実行 この段階では、テストケースやその他の必要な情報に基づいてスクリプトまたはテストの順番を作成し、環境を構築してテストを実行します。 ４、成果とレポートの評価 テスト実装がテストの目的を満たしているかどうかの評価です。 具体例： ・テスト計画段階で指定されたテスト終了基準とテスト結果を比較する ・追加のテストが必要か、出力の基準を変更する必要があるかを判断します ・テストレポートを書く C> テストの心理学 テスターと開発者はいつも、クライアントのニーズを満たす完璧なソリューションを作成する、という同じゴールを目指しています。しかし彼らの仕事と考え方は異なっています。開発者が適切な意見を持っている場合は、自分でテストできます。しかし、開発者とテスターの環境を分けた方がテストは効果的です。十分に訓練されたプロテスターによる、開発とは完全に独立した観点からのテストは、開発とテスターの双方向のフィードバックを得られるので、有益です。…
