この混乱を解くために、 アレクセイ・バランツェフ （ソフトウェアテストの実践者、トレーナー、コンサルタント、ロシア科学アカデミーのシステムプログラミング研究所のネイティブ）は、テストの主要なポイントに関する紹介ビデオのテストのトレーニングに先立ちます。
このレポートでは、講師は科学者とプログラマーの観点から「テストとは何か」を最も適切かつ合理的に説明できたようです。 このテキストがまだハブに表示されていないのは奇妙です
ここで、このレポートについて簡単に説明します。 本文の最後に、フルバージョンへのリンクと言及されたビデオへのリンクがあります。
キーポイントのテスト
親愛なる同僚、
最初に、テストではないものを理解しようとします。
テストは開発ではなく 、
テスト担当者がテスト（自動化テスト=プログラミング）を含めてプログラムできる場合でも、補助プログラム（自分用）を開発できます。
ただし、テストはソフトウェア開発作業ではありません。
テストは分析ではなく 、
要件の収集と分析ではありません。
ただし、テストプロセスでは、要件を明確にする必要がある場合と、要件を分析する必要がある場合があります。 しかし、このアクティビティは基本的なものではなく、単に必要に応じて実行する必要があります。
テストは管理ではありません
多くの組織には「テストマネージャー」のような役割があるという事実にもかかわらず。 もちろん、テスターを管理する必要があります。 しかし、テスト自体はコントロールではありません。
テストはテクニカルライティングではありません 。
ただし、テスターはテストとその作業を文書化する必要があります。
開発プロセス（または要件の分析、テストのドキュメントの作成）で、テスターはすべての作業を自分自身で行い、他の人ではないため、テストはこれらのアクティビティのいずれかと見なすことはできません。
アクティビティは、需要がある場合にのみ重要です。つまり、テスターは「エクスポート用」の何かを作成する必要があります。 彼らは「輸出」のために何をしますか？
欠陥、欠陥の説明、またはテストレポート？ これは部分的に真実です。
しかし、これは完全な真実ではありません。
テスターの主な活動
ソフトウェア開発プロジェクトの参加者にソフトウェア製品の品質に関する否定的なフィードバックを提供するという事実にあります。
「ネガティブフィードバック」はネガティブな意味合いを持たず、テスターが何か悪いことをしたり、悪いことをしたという意味ではありません。 これは単なる技術用語であり、かなり単純なことを意味します。
しかし、このことは非常に重要であり、おそらくテスターの活動の最も重要なコンポーネントです。
科学があります -「 システム理論 」。 このようなことを「フィードバック」と定義しています。
「フィードバック」とは、出力から入力に戻るデータ、または出力から入力に戻るデータの一部です。 このフィードバックは正と負になります。
どちらのタイプのフィードバックも等しく重要です。
ソフトウェアシステムの開発において、もちろん、正のフィードバックはエンドユーザーから受け取る情報です。 これらはいくつかの新しい機能のリクエストであり、これは売上の増加です（高品質の製品をリリースする場合）。
ネガティブフィードバックは、エンドユーザーから何らかのネガティブフィードバックの形で提供されることもあります。 または、テスターから来る場合があります。
ネガティブフィードバックが早く提供されると、この信号を変更するために必要なエネルギーが少なくなります。 そのため、プロジェクトのごく初期の段階でできるだけ早くテストを開始し、設計段階と、おそらく要件の収集と分析の段階の両方でこのフィードバックを提供する必要があります。
ところで、テスターは品質に責任を負わないという理解が深まります。 彼らはそれに対して責任がある人々を助けます。
「テスト」という用語の同義語
テストは否定的なフィードバックの提供であるという観点から、世界的に有名な略語QA（英語品質保証-品質保証）は、「テスト」という用語の同義語ではありません。
アシュアランスは何らかのポジティブな手段であるため、単にネガティブフィードバックを提供するために品質保証を検討することは不可能です。 この場合、品質を正確に確保し、ソフトウェア開発の品質が向上するようにタイムリーな対策を講じることが理解されています。
しかし、「品質管理」-品質管理は、広義では「テスト」という用語の同義語と考えることができます。品質管理とは、ソフトウェアプロジェクトのさまざまな段階で最も多様な形でフィードバックを提供するためです。
テストは、品質管理の別の形式として暗示される場合があります。
混乱はテストの歴史から来ています。 さまざまな時点で、「テスト」という用語は、外部と内部の2つの大きなクラスに分類できるさまざまなアクションを意味していました。
外部定義
Myers、Beiser、Kanerがさまざまな時に与えた定義は、その外部の重要性の観点からテストを正確に説明しています。 つまり、彼らの観点からすると、テストは何かのために設計されたアクティビティであり、何かで構成されているわけではありません。 これら3つの定義はすべて、負のフィードバックを提供するものとして要約できます。
内部定義
これらは、ソフトウェアエンジニアリングで使用される標準用語、たとえばSWEBOKと呼ばれる事実上の標準で提供される定義です。
このような定義は、WHATテストアクティビティが建設的に説明するものですが、プログラムの実際の動作と期待される動作との対応を確認するすべての結果が使用される、WHATテストの目的を少しでも説明するものではありません。
だから
テストは
- プログラムの要件への準拠を確認し、
- 彼女の仕事を観察して実施
- 特定の方法で選択された特別な人工的に作成された状況。
ここからは、これを「テスト」の実用的な定義と見なします。
一般的なテストスキームは、およそ次のとおりです。
- 入力テスターはプログラムおよび/または要件を受け取ります。
- 彼は彼らと一緒に何かをし、彼によって人工的に作成された特定の状況でプログラムの仕事を監督します。
- 出力では、適合性と不整合に関する情報を受け取ります。
- この情報は、既存のプログラムを改善するために使用されます。 または、まだ開発中のプログラムの要件を変更するため。
テストとは何ですか？
- これは、特定の方法で選択された、人為的に作成された特別な状況です。
- また、プログラムをどのように監視する必要があるかについての説明
- 特定の要件へのコンプライアンスを検証する。
状況がすぐに何かであると考える必要はありません。 テストは非常に長くなる場合があります。たとえば、パフォーマンスをテストする場合、この人為的に作成された状況は、システムに長時間かかることがあります。 そして、同時に行う必要のある観測は、このテストを実行する過程で測定するさまざまなグラフまたはメトリックのセットです。
テスト開発者は、膨大な、潜在的に無限のテストセットから限られたテストセットを選択することを約束します。
このようにして、テスターはテストプロセスで2つのことを行うと結論付けることができます。
1.最初に、彼はプログラムの実行を制御し、これらの非常に人工的な状況を作り出し、プログラムの動作を確認します。
2.次に、彼はプログラムの動作を観察し、自分が見ているものと予想されるものを比較します。
テスターがテストを自動化する場合、彼はプログラムの動作を自分で観察しません。彼はこのタスクを特別なツールまたは彼自身が書いた特別なプログラムに委任します。 観察するのは彼女であり、観察された行動と予想された行動を比較し、テスターは、観察された行動が予想された行動と一致するか一致しないかという最終結果のみを提供します。
プログラムは、情報を処理するためのメカニズムです。 入力は1つの形式で情報を受け取り、出力情報は他の形式で受け取ります。 同時に、プログラムは多くの入力と出力を持つことができ、それらは異なる場合があります。つまり、プログラムはいくつかの異なるインターフェースを持つことができ、これらのインターフェースは異なるタイプを持つことができます。
- ユーザーインターフェース（UI）
- プログラミングインターフェイス（API）
- ネットワークプロトコル
- ファイルシステム
- 環境
- イベント
最も一般的なインターフェイスは
- 習慣
- グラフィック
- テキスト
- カンチレバー
- とスピーチ。
これらすべてのインターフェイスを使用して、テスターは次のことを行います。
- どういうわけか人工的な状況を作成します
- これらの状況で、プログラムの動作を確認します。
これはテスト中です。
テストの種類のその他の分類
最も一般的に使用される3つのレベルの区分、これ
- 単体テスト
- 統合テスト
- システムテスト。
ユニットテストは通常、かなり低いレベルでのテスト、つまり個々の操作、メソッド、機能のテストを意味します。
システムテストとは、ユーザーインターフェイステストのことです。
「コンポーネントテスト」など、他の用語も使用される場合がありますが、ユニットテストとシステムテストの技術的な分離はあまり意味がないため、これら3つを選択することを好みます。 さまざまなレベルで、同じツールを同じ手法で使用できます。 分離は条件付きです。
実践では、製造元が単体テストツールとして位置付けているツールを、アプリケーション全体のテストレベルで同様に適用できることを示しています。
また、ユーザーインターフェイスレベルでアプリケーション全体をテストするツールは、たとえばデータベースを調べたり、データベースで別のストアドプロシージャを呼び出したりする場合があります。
つまり、技術的観点から言えば、システムとユニットのテストへの分割は一般的に純粋に条件付きです。
同じツールが使用され、これは正常であり、同じ技術が使用され、各レベルで異なる種類のテストについて話すことができます。
私たちは結合します：
つまり、機能の単体テストについて話すことができます。
システムテスト機能について話すことができます。
効率などの単体テストについて話すことができます。
有効性の体系的なテストについて話すことができます。
特定のアルゴリズムの有効性を検討するか、システム全体の有効性を検討します。 つまり、ユニットテストとシステムテストの技術的な分離はあまり意味がありません。 異なるレベルでは同じツールであるため、同じ手法を使用できます。
最後に、統合テスト中に、あるシステム内でモジュールが相互に正しく相互作用するかどうかを確認します。 つまり、システムテストと同じテストを実際に実行します。モジュールが相互にどのように相互作用するかについてのみ注意を払います。 追加のチェックをいくつか実施します。 それが唯一の違いです。
システムテストと単体テストの違いをもう一度理解してみましょう。 この分離は十分に一般的であるため、この違いがあるはずです。
そして、この違いは、技術的な分類ではなく、テストの目的に応じた分類を行ったときに明らかになります。
目的別分類は、元々ブライアン・マリクによって発明され、その後エリ・テネンによって改良された「魔方陣」を使用して便利に実行されます。
この魔方陣では、すべてのタイプのテストが4つの象限に配置されますが、これらのテストで何に注意を払うかによって異なります。
垂直-テストの種類が高ければ高いほど、プログラムの動作の外部の兆候に注意が向けられ、それが低ければ低いほど、プログラムの内部の技術構造に注意が向けられます。
水平-テストが左にあるほど、彼らのプログラミングに注意を払うほど、彼らはより適切になり、人によるプログラムの手動テストおよび研究により多くの注意を払います。
特に、受け入れテスト、受け入れテスト、単体テストなどの正方形は、文献で最も頻繁に使用されている意味で、この正方形に簡単に入力できます。 これは、大規模な低レベルのテストであり、プログラミングの圧倒的な割合を占めています。 つまり、すべてのテストがプログラムされ、完全に自動的に実行され、主にプログラムの内部構造、およびその技術的特徴に正確に注意が払われます。
右上隅には、プログラムの何らかの外部動作、特にユーザビリティテストを目的とした手動テストがあり、右下隅には、パフォーマンス、セキュリティなどのさまざまな非機能プロパティのチェックがあります。
したがって、目標による分類に基づいて、ユニットテストは左下の象限にあり、他のすべての象限はシステムテストです。
ご清聴ありがとうございました。