ソフトウェアテストのインタビューに関するよくある質問とその回答の概要

ソフトウェアライフサイクル（SLC）は、ソフトウェアの概念が登場した瞬間から始まり、ソフトウェアを使用できなくなった時点で終わる期間です。 通常、ソフトウェアライフサイクルには、概念、要件の説明、設計、実装、テスト、インストールと試運転、運用とサポート、および場合によっては試運転段階が含まれます。 これらのフェーズは、互いに重ね合わせたり、繰り返したりすることができます。

ソフトウェア開発ライフサイクル（SDLC）は、ソフトウェア開発の各段階（フェーズ）で実行される一連のアクティビティを記述する概念です。

• プロジェクトの基礎を提供する（方法論、活動...）;
• プロジェクトの進捗状況を視覚化する;
• プロジェクトの有効性と成功裏の完了を支援します（コストの削減、開発とテストの時間の短縮、最終製品の品質の向上）。
• ソフトウェア開発プロセスに関連するリスクの低減。
• プロジェクトの進捗を追跡するための特別なメカニズムを提供します。

1. ソフトウェアを作成する必要性に関する意思決定（アイデア）。
2. 要件の収集と分析。
3. 要件に基づいた設計（システムとソフトウェア）;
4. システム設計に基づいたコーディング。
5. テスト;
6. ユーザー環境での実装。
7. メンテナンス（ユーザー環境で見つかった修正エラーを含む）;
8. 廃止（まれに）;

品質保証（QA）は、ソフトウェア開発、生産、運用のすべての技術段階をカバーする一連の活動であり、ソフトウェアライフサイクルのさまざまな段階で行われ、製品の必要な品質レベルを確保します。



品質保証は、ISO 9000：2005、品質管理システムで定義されています。 キーポイントとボキャブラリーは、品質要件が満たされるという自信を生み出すことを目的とした品質管理の一部として。



同じ規格の品質管理は、「品質に関連する組織の管理と管理のための調整された活動」として提示され、「通常、品質、品質計画、品質管理、品質保証、品質改善の分野におけるポリシーと目標の開発が含まれています」と述べています「。

品質管理（QC）は、開発プロセスでソフトウェアで実行される一連のアクティビティであり、リリースの準備、規定の要件の順守、およびこのソフトウェアの規定の品質レベルの順守に関する現在のステータスに関する情報を取得します。

ソフトウェアテストは、ソフトウェア製品の計画、準備、評価、および関連する作業結果に関連する、動的および静的なライフサイクルのすべてのアクティビティを含むプロセスであり、記述された要件を満たしていることを示し、宣言された目的および欠陥判定に適しています。



この定義から、ソフトウェアテストには2つの異なるプロセスが含まれることが明らかになります。

検証：特定のアプリケーションの要件が満たされていることを確認する客観的研究の証明。 [ISO 9000]

検証：特定の要件が満たされているという研究の客観的な結果の確認。 [ISO 9000]

テストの目的（テストの目的、テストの対象）は、テストの開発と実行の理由または目的です。



主な目標：

• ソフトウェアでエラーが除去されていることを確認します（100％のカバレッジを提供することはできませんが、可能なすべてのことを実行し、明らかなエラーが修正されるようにする必要があります）
• ソフトウェアが元の要件と仕様を満たしていることを確信させる。
• ソフトウェア（ユーザー、顧客など）に自信を与えます。

簡単な答えは、できるだけ早くです！ より詳細に：

• 初期段階でソフトウェアをテストする場合、この段階でソフトウェアを変更することは後の段階よりもそれほど高価ではないため、設計に容易に影響を与えることができます。
• 同様に、エラーが早く検出されるほど、企業のコストは安くなります。
• テストは、実際のソフトウェアを受け取る前に開始することもできます（静的テスト）。これは、動的テスト段階の複雑さを軽減するため、非常に重要です。 動的テストの段階で見つかった多くのエラーは、静的テストの段階で修正できたはずであり、修正すべきだったという意見があります。
• 初期段階でのテスト（要件、仕様、ビジネスケースなどの調査）は、ソフトウェアに関するより多くの知識をテスターに​​提供し、ソフトウェア、最終設計、およびコストに影響する論理的および技術的エラーの検出に役立ちます。

簡単な答えは管理決定です。これは、次のことに基づいて行われる可能性が最も高いです。

• テストカバレッジ;
• リスク分析;
• テストの悪化。

この問題のより詳細な調査は、 Michael Boltonのブログで最もクールな記事で、「ピニャータ」と「デッドホース」のヒューリスティックが異なる点で役立ちます。

1. コンポーネント /ユニットテストは、個々のソフトウェアコンポーネントのテストです[IEEE 610]。
2. 統合テスト （統合テスト）-このテストは、統合されたコンポーネントまたはシステム間のインターフェースおよび相互作用の欠陥を検出するために実行されます。
   
   
   
   また、ビッグバンテスト、トップダウンテスト、アップストリームおよびインクリメンタルテストとは何かを理解する必要があります。
   
   
   
   
3. システムテスト （システムテスト）は、確立された要件を満たしていることを確認するために、システム全体をテストするプロセスです。
4. 受け入れテストは、システムが受け入れ基準を満たしているかどうかを判断するために実行される、ユーザーのニーズ、要件、およびビジネスプロセスに関する正式なテストです（ユーザー、顧客、または顧客が受け入れるためにコンポーネントまたはシステムが満たさなければならない出口基準）別の許可された人物による）[IEEE 610]、そこから忘れてはならないタイプがあります：
   
   
   • ユーザー受け入れテスト
   • 工場受け入れテストは、コンポーネントまたはシステムがソフトウェアとハ​​ードウェアの両方の要件を満たしているかどうかを判断するために、ソフトウェア製品開発者側で実施され、サプライヤー企業の従業員によって実施される受け入れテストです。
   • サードパーティの受け入れテスト（サイト受け入れテスト）は、ユーザーまたは顧客側の受け入れテストです。 これは、ビジネスプロセスへの準拠と、このシステムまたはコンポーネントがユーザーまたは顧客のニーズを満たしていることを確認することを目的として実行されます。 通常、ソフトウェアと技術ベースの両方をチェックします。
   • 運用受け入れテスト（運用受け入れテスト）は、受け入れテストフェーズでの運用テストであり、通常、作業環境（シミュレートされている場合もある）で管理アクセス権を持つユーザーおよび/または従業員によって実行され、機能的側面（回復性、リソースの動作、インストール性、技術コンプライアンス）。
   
   
   
5. アルファテストは、開発者側ではあるが開発中の組織外の潜在的なユーザー/顧客または独立したテストチームによるシミュレーションテストまたは実際の運用テストです。 アルファテストは、多くの場合、内部受け入れテストとしてボックス版ソフトウェアに適用されます。
6. ベータテストは、コンポーネントまたはシステムがクライアント/顧客の要件を実際に満たし、ビジネスプロセスに適合するかどうかを判断するために、開発者とは一切接続されていない外部の潜在的および/または既存のクライアント/顧客による運用テストです。 ベータテストは、市場からのフィードバックを得るために、完成したソフトウェアの外部受け入れテストの一形態としてしばしば実施されます。

エントリー基準は、テスト段階など、特定のタスクでプロセスを継続するための一般的および特定の条件のセットです。 エントリ基準の目的は、タスクの開始を防ぐことであり、失敗したエントリ基準を排除するよりも多くの（無駄な）努力が必要になる場合があります。



簡単に言えば、将来のテスターとして、エントリー基準は、あなたとあなたのチームがテストを開始する前に満たさなければならない基本条件として理解されるべきです。

• 初期段階（設計）に関連するすべての欠陥は閉じられ、チェックされます。
• 「ユニット」テストを使用して検証されたコード。
• 主なソフトウェア機能はテストの準備ができています。
• 要件を定義するドキュメントがあります。
• すべてのテスターはソフトウェアアーキテクチャに精通しています。
• すべてのテスターはプロジェクトの目的に精通しています。
• テスト環境の準備ができました。
• 使用可能なビルド
• テスト計画および/またはテストケースが承認されました。

終了基準は、プロセスが公式に完了したとみなされるように、関係者と事前に合意した一般的および特定の条件のセットです。 終了基準の目的は、タスクが完了したとみなされる可能性を防ぐことですが、タスクにはまだ不完全な部分があります。 終了基準は、レポートとテストの停止時期の計画に使用されます。



簡単に言えば、エントリの基準がテストの開始を決定し、終了の基準がテストの終了を決定し、ソフトウェアがライフサイクルの次のフェーズ（実装など）の準備ができたことになります。

• 「リスク」としてソフトウェアのすべての事前定義された領域がテストされ、このステータスが低下/削除されます。
• すべてのエラーは慎重に文書化され、経営陣/株主/顧客に伝えられます。
• 優先度の高いすべてのテストに合格し、それに応じて「合格」とマークされます。
• すべてのSRSドキュメント要件（ソフトウェア要件仕様）。
• プロジェクトオーナーによって承認されたSTR。
• テストされたソフトウェアアーキテクチャ。
• 深刻なエラーや重大なエラーは未解決のままです。
• 完了したすべてのテストの90〜95％。

• 内部自動化ツール。
• Seleniumシリーズのソフトウェア製品;
• MS VS ;
• JUnit ;
• テスト完了 ;
• ロードランナー ;
• どこでもテスト ;
• WinRunner 。

さらに-自動テストに関するクールな調査の結果 。

次の動作によって引き起こされるソフトウェアの問題/エラー：

• ソフトウェアの故障または無効な通知の表示。
• ソフトウェアは無効な結果を提供します。
• ソフトウェアは期待どおりに実行できませんでした（予想された結果からの逸脱）。

答えを探している本当の質問は、製品を正しく構築していますか？



検証プロセスは、ソフトウェア開発ライフサイクルの各段階（開発、テストなど）が、事前定義された要件（仕様）と仕様（仕様）に基づいて、それらから逸脱することなく構築されることを確認するために実行されます。 （No. 7を参照）

• テストのさまざまな側面（用語、リソース、スタッフ、コスト、テストツールなど）の分析。
• ステートメントカバレッジ-一連のテストによって実行されたステートメントの総数に対する割合。 条件カバレッジ-一連のテストによって検証された条件の結果の割合。 条件を100％網羅するためには、決定の各表現における個々の条件が、真偽として検証される必要があります。 代替のカバレッジ （意思決定カバレッジ）-一連のテストでテストされた代替結果の割合。 ソリューションの100％のカバレッジは、ブランチの100％のカバレッジとオペレーターの100％のカバレッジを意味します。
• ピアレビューは、計画された結果との不一致を確立し、改善のための提案を提示するための製品またはプロジェクトの状態の評価です。 ピアレビューの例には、管理ピアレビュー、非公式のピアレビュー、技術分析、検査およびレビューが含まれます。
• ウォークスルーは、情報を収集し、ドキュメントの内容を均一に理解するために、ドキュメントの作成者が実施する段階的な分析です。
• 検査は、エラーを見つけるためのドキュメントの目視検査に基づくピアレビューの一種です。 たとえば、開発基準の違反や、より高いレベルのドキュメントの非準拠。 最も正式な査読方法論であり、したがって、常に文書化された手順に基づいています。

1. 単体テスト：
   
   -ソフトウェア設計の実装を確認します。
2. 統合テスト
   
   -ソフトウェアが次のレベル（システム）に移行する前に、関連するすべてのコンポーネント間の統合をテストします。
3. システムテスト
   
   -事前に定義された要件と仕様にシステムが確実に準拠するようにします。
4. 受入試験
   
   -システムがクライアントの要件を満たしていることを確認してください。

答えを探している本当の質問： 適切な製品を構築していますか？



開発者がソフトウェアを顧客に転送する前に、開発者がソフトウェアを評価できるようにするプロセス。 このプロセスでは、ソフトウェアがユーザーのニーズに基づいて設計されていることを確認する必要があります。



検証には、テストの動的な側面が含まれており、特定のソフトウェアがSRSのドキュメントに反してテストおよび評価されます。

• 人的エラー（設計プロセスと実装プロセス）;
• テスト中のソフトウェアの要件の変更。
• 要件と仕様の理解不足。
• 時間の不足;
• テストの低い優先順位付け。
• ソフトウェアバージョンの方向性が悪い。
• ソフトウェア自体の複雑さ。

テストの実行に含まれるステップのシーケンスを説明するドキュメント。 手動テストスクリプトとも呼ばれます。

基本的に、ソフトウェアコンポーネントは、小さなユニットから構築されたソフトウェアの小さなアイテムであり、それらは順番に統合されます（クラス、メソッド、ストアドプロシージャ、バイナリツリーなど）。

コードカバレッジとは、ソフトウェアのどの部分が一連のテストでテスト（カバー）されており、たとえば、オペレーターの範囲、代替の範囲、条件の範囲ではないかを判断する分析方法です。

コード検査またはコードレビューは、開発の初期段階で気付かれなかったエラーを検出して修正するためのプログラムのソースコードの体系的なチェックです。 レビューの目的は、ソフトウェア製品の品質を向上させ、開発者のスキルを向上させることです。

検査プロセス中に、文字列のフォーマットエラー、競合状態、メモリリーク、バッファオーバーフローなどの問題を見つけて修正できるため、ソフトウェア製品のセキュリティが向上します。 バージョン管理システムにより、共同コード検査を実施できます。 さらに、協調コード検査のための特別なツールがあります。

自動コード検査用のソフトウェアは、大規模なコードを表示するタスクを簡素化し、最もよく知られている脆弱性を体系的にスキャンします。

特定のSDLCステップに関連した単純な用語。 「コードが完了した」と言うと、実際にはその実装が完了していることを意味します（すべてのソフトウェア機能が正常に実装されました）。 コードが完全に実装されていても、テスト中に常に新しいバグが発見されます。

ウォークスルーは、プログラマーとテストチームがコードの実装の進捗状況を確認するために使用されるテスト手法です。解析中に、コードはいくつかの簡単なテストを使用して実行され、その品質とロジックを決定します。

デバッグとは、ソフトウェアの障害とエラーの原因を見つけ、分析し、排除するプロセスです。



エラーが発生した場所を理解するには、以下を行う必要があります。

• 変数の現在の値を見つけます。
• プログラムの実行方法を調べます。

2つの補完的なデバッグテクノロジがあります。

• デバッガーの使用-プログラムの段階的な実行のためのユーザーインターフェイスを含むプログラム：オペレーターごと、関数ごと、ソースコードの特定の行での停止、または特定の条件に達したとき。
• 画面、プリンター、スピーカー、またはファイルへのプログラムの重要なポイントに配置された出力演算子を使用したプログラムの現在の状態の出力。 ファイルへのデバッグ情報の出力は、ロギングと呼ばれます。

エミュレーションとは、プログラムまたはシステムの作業を複製することであり、その重要な特性と作業の原則を維持したまま（その乏しい部分の複製ではありません）。 エミュレーションは、エミュレートされたオブジェクトと同じコンポーネントで構成される、このコードに馴染みのある環境でプログラムコードを実行します。



シミュレーションは、元のプログラムの作業を、特別なプログラム（コース開発ツールなど）のエンジンで純粋に仮想的に再現したものです。 シミュレーションはコードの実行をシミュレートするだけで、コピーは行いません。すべてが事実上100％仮想であり、すべてが「信じられる」ものです。



したがって：



ソフトウェアエミュレータは、元のソフトウェアまたはそのバージョンの完全に機能する類似物であり、ソフトウェアの機能、機能、および動作にいくつかの制限を設ける場合があります。



ソフトウェアシミュレーターは、このソフトウェアのロジックを（部分的または完全に）実装し、ソフトウェアの動作をシミュレートし、そのインターフェイスをコピーする元のソフトウェアのモデルです。



考慮される機能/パラメーターの完全性のためのシミュレーターは、エミュレーターよりも狭いです。 オブジェクトがエミュレートされ、そのプロパティ、機能、または動作がシミュレートされます。

仕様は、テストデータでテストする必要があるものを記述するテキストファイルです。 プログラムが受け取るべき結果を示します。 テストコードは、ライブコード結果で計算された実際のコードを見つけます。 テストエンジンは、仕様と計算結果を調整します。



開発チームが要件を使用する定性的に新しい、より詳細なレベルに要件を分析、調査し、移動することにより、お客様から仕様を受け取ります。

コーディング （コーディング）は、特定のプログラミング言語で特定のアルゴリズムを実装するために、プログラムコード、スクリプトを記述するプロセスです。



一部の人々は、プログラミングやコーディング自体などの概念を混同しています。 コーディングは、分析、設計、コンパイル、テストとデバッグ、保守とともにプログラミングの一部にすぎません（狭い円では、コーディングは「コーディング」とも呼ばれます。ただし、Wikiによると、この用語は文献ではほとんど使用されません。）

要件 （要件）-実装するソフトウェアシステムの属性、プロパティ、または品質に関する一連のステートメント。 これらは、要件分析の結果としてソフトウェア要件を開発するプロセスで作成されます。



要件は、テキストの記述とグラフィックモデルの形式で表現できます。



従来の技術的アプローチでは、ソフトウェア設計段階で一連の要件が使用されます。 テストは特定の要件に基づいているため、要件はソフトウェアテストプロセスでも使用されます。



要件開発フェーズの前に、実行可能性調査、またはプロジェクト分析の概念フェーズが行われた可能性があります。 要件開発フェーズは、要件の識別（利害関係者のニーズの収集、理解、検討、および明確化）、分析（整合性および完全性チェック）、仕様（要件の文書化）、および正当性の検証に分けることができます。

安定性 （安定性）/ 信頼性 （信頼性）をテストするタスクは、平均レベルの負荷で長時間（数時間）のテスト中にアプリケーションの状態を確認することです。 このタイプのテストでは、操作の実行時間が二次的な役割を果たします。 同時に、メモリリークがないこと、負荷がかかった状態でサーバーが再起動すること、および作業の安定性に影響するその他の側面が最初に現れます。

重大度は、コンポーネントまたはシステムの開発または動作に対する特定の欠陥の影響の重要性です。



エラーの重大度はバグを発見したテスターに​​よって決定されますが、その前にそのような質問に答えなければなりません。

• このエラーはテストプロセスにどのように影響しますか？
• このエラーはクライアントにどのように影響しますか？
• このエラーはシステムにどのように影響しますか？
• このエラーはテストのタイミングにどのように影響しますか？
• このエラーは他のテストをブロックしますか？
• 等

各企業は、重大度（重大度）について独自の規模を定義できますが、ほとんどすべてのチームで使用されるいくつかのレベルがあります。

• Blocker / show-stopper （blocking）-ソフトウェアまたは特定のコンポーネントは使用/テスト（完全な障害、システムクラッシュなど）に適していないため、回避策はありません。
  
  例：ユーザーが[開始]ボタンを押すとシステムがクラッシュします。 インストーラーが破損した後、システムは起動しません。 ハードウェア障害によるソフトウェアのシャットダウン。
• 重要 -主な機能が本来のように機能しないため、テストの整合性に影響を与える可能性のある回避策があります。
  
  例：ソフトウェアはさまざまな機能を使用してランダムにクラッシュする可能性があります。 ソフトウェアの結果が矛盾するため、基本的な要件を確認できません。
• メジャー （重要）-マイナー機能の無効化、他のコンポーネントへの影響はなく、迅速かつ効果的な回避策があります。
  
  例：ユーザーは特定の機能を直接使用することはできませんが、異なるモジュールからのアクセスを利用して使用することができます。
• マイナー （マイナー、マイナー）-特定の場所へのマイナーな影響、回避策を作成する必要はありません。ソフトウェアの整合性は影響を受けません。
  
  例：スペルミス、改善、変更要求

優先度は、バグに割り当てられた重要度です。 つまり、このエラーをどの程度緊急に修正するかが決定されます。



優先度は管理ツールであり、定義する前に、少なくとも次の質問に答える必要があります。

• バグはタイミングにどのように影響しますか？
• バグはテストプロセスにどのように影響しますか？
• バグは他のテスターの作業にどのように影響しますか？
• バグ修正の費用はいくらですか？
• ソフトウェア要件を変更する必要がありますか？

アセンブリ -使用のために準備された情報製品。 ほとんどの場合、実行可能ファイル（プログラムの実行可能コードを含むバイナリファイル）です。



ビルドバージョン番号が次のようになっているとします：1.35.6.2

1. 最初の識別子はメジャーバージョン番号です。
2. 2番目の識別子は、オプションのバージョン番号です。
3. 3番目の識別子はビルド番号です。
4. 4番目の識別子はリビジョン番号です。

もちろん-はい！ 結局、静的な方法を使用して作業アセンブリなしでテスターが作業を開始できるようにする2つのタイプのテスト方法論（静的および動的）があり、そのような方法は「動的」な方法よりも費用効率が高くなります。

静的分析は、要件やソフトウェアコードなどのソフトウェア成果物の分析であり、これらのソフトウェア成果物を実行せずに実行されます。

ドライバーは、コンポーネントまたはシステムの制御や呼び出しを提供するコンポーネントを置き換えるソフトウェアコンポーネントまたはテストツールです。



ハーネスは、テストに必要なスタブとドライバーを含むテスト環境です。

カバレッジ要件を測定するには、製品要件を分析し、それらをポイントに分解する必要があります。 オプションで、各アイテムは、それをテストするテストケースに関連付けられます。 これらの関係の組み合わせがトレーサビリティマトリックスです。 リンクをたどることで、テストケースがチェックする要件を正確に理解できます。



要件に関係しないテストは意味がありません。 非テスト要件は「ホワイトスポット」です。 作成されたすべてのテストケースを完了すると、この要件が製品に実装されているかどうかを答えることはできません。

エンドツーエンドテストは、ユーザーが持つ可能性が最も高い条件下で、テスターがソフトウェア（実行フロー全体を調べるスクリプト）を使用するテストの一種です。



さらに、実世界に関連するいくつかのシナリオを組み合わせることにより、テストが機能します。

• ネットワーク通信の遅延がある環境でのソフトウェアの起動。
• 低リソース環境でソフトウェアを実行する。
• 他のサーバーハードウェアでソフトウェアを実行します。
• サーバーリソースを消費する他のアプリケーションと同じ環境でソフトウェアを実行します。

機能テストは、コンポーネントまたはシステムの機能の仕様の分析に基づいたテストです。



機能テストは、機能や機能、および他のシステムとの相互作用に基づいており、すべてのレベルのテストで提示できます：コンポーネントまたはユニット（コンポーネント/ユニットテスト）、統合（統合テスト）、システム（システムテスト）および受け入れ（受け入れテスト） 。 テストの機能タイプは、システムの外部動作を考慮します。



:

1. , , (, , , ). , , (use cases). :
   
   
   • «» (requirement-based testing) (Test Cases). , , ; ( ), (test cases). .
   • «-» (business-process-based testing) -, . (test scripts), , (use cases).
   
   
   
2. T (security testing) — . :
   
   
   • ;
   • ;
   • ;
   :
   
   
   • xss (cross-site scripting) — (Web ), , , , ;
   • xsrf / csrf (request forgery) — , HTTP , : , , , (, ..), , , ;
   • code injections (sql, php, asp ..) — , , ;
   • server-side includes (ssi) injection — , HTML ;
   • authorization bypass — , .
   
   
   
3. (interoperability testing) — .
   
   

:

• , .
• ( 1 ) ( ), , .

(non-functional testing) — , , , , , , .. (, , ).

1. (portability testing) .
2. (interoperability testing) — .
3. (performance testing) — .
4. (reliability testing) — , .
5. (usability testing) — , , .
6. (safety testing) — .
7. (stress testing) — , , , .
8. (load testing) — , ( / ) .

— , .



, , , . .



:

• ;
• ;
• ;
• ;

— () , . .



:

• ;
• ;
• - ;
• ;

(onversion testing) — , , .

— , (IEEE, W3C ..) .