多くの人は、これが時間とリソースの無駄だと信じているため、研究テストに懐疑的です。 しかし、実際にはそうではありません。 この記事では、研究テストがいつプロジェクトに役立つかを説明します。 ロシア語の文献では、「研究テスト」という用語に対して多くの異なる定義が与えられています。 多くの場合、この概念はアドホックテストを意味し、その逆も同様です。 歴史的にそれが起こった理由はそこにあります- 研究テスト3.0 。 そのため、記事を読むときに混乱がないように、時計をチェックして定義を修正します。
研究テストとは
アドホックテスト
アドホックテストとは、仕様、計画、開発されたテストケースを使用せずにテストすることです。純粋な即興です。
研究テスト
アドホックのより正式なバージョン：テストケースの記述を必要としないが、後続の各テストが前のテストの結果に基づいて選択されることを意味するテスト。 「コンピューターソフトウェアのテスト」サムカナによると、「研究テスト」はアドホックテストに対する思慮深いアプローチです。
シナリオテスト
事前に作成および文書化されたスクリプトを使用した古典的なテスト。
シナリオのテストを支持して：
- 比較的容易な計画：テストケースは異なるテスターまたはチーム間で簡単に分割できます。
- 重要なケースは放置されません。
- テストでプロジェクトのカバレッジの割合を推定し、どの部分がすでにテストされているかを理解するのは簡単です。
- 新しい人をプロジェクトに簡単に導入できます。彼に期待されるアクションは、テストシナリオの一連の手順で既に構成されています。
- テストシナリオの十分に詳細な説明があれば、テスターの資格は最小限になります。
- 開発されたテストシナリオは、製品受け入れテストのために顧客に転送できます。
研究テストを支持して：
- 予測可能性と固定された一連のステップへの堅固なアタッチメントなしでは、より多くの欠陥が見つかります。 基本的に、これらは主要な機能に関連しない欠陥です。
- すべてのシナリオの予備的な完全な説明に時間を費やす必要はありません。
- テストケースのサポートは不要
- シナリオのテストに慣れることはなく、その通過は「見ないで」発生しません。
- 製品のビジョン全体が失われることはありません。
- 重大な欠陥はより高速です。
- テスト速度が向上します。
- 要件がまったくなくても、製品のテストをすぐに開始できます。 楽しいことに加えて、ドキュメントとその後のテストの個別の研究と比較して、それは大幅な時間の節約にもなります。
- より面白くて創造的。 テストは、通過する人の想像力と製品に関する知識の深さによってのみ制限されます。
これらのポイントをもう一度読み直してください。ただし、シナリオテストの利点が研究にとって不利になる可能性があり、その逆の理由も考えてください。
いつ純粋なテストを適用できますか？
時間が足りない
テストのドキュメントは書かれているが、テストに合格する時間がもうない場合は、利用可能な時間内に実際にテストできるアプリケーションの最も重要な領域を選択する必要があります。 アイデアを含むチェックリストを作成し、それらをテストします。
要件に関する課題
要件はなく、完全または最新ではなく、更新する方法もありません。
小さなプロジェクト
製品は小さく、テストシナリオの開発はテストプロセス自体よりも時間がかかります。
従来のテストに加えて、いつ研究テストを適用できますか？
テスターは常に同じテストスクリプトを渡します
たとえば、回帰テスト中に同じテストに繰り返し合格すると、テスターは集中力を失い、欠陥を見逃し始めます。 この場合、研究テストはプロジェクトを新しい角度から見て、欠落している欠陥を見つけるのに役立ちます。
テスターはテンプレートの操作から気をそらされ、より一般的なユーザーのように感じます。 これは、開発中の製品のエンドユーザーにより強い影響を与える欠陥を見つけるのに役立ちます。
ここでは、ツアーの概念を使用できます。 ロシア語でもっと読む- 人生は動きだ！ そして、テストは人生です:)ほとんどのテスターは直感的にツアーを使用し、残りはあまり利益をもたらしませんが、記事を読んだ後の士気と探求への欲求は確実に現れるはずです。
突然の変更リクエストが届きました
誰もが他の計画されたタスクで忙しいため、新しいシナリオを開発する時間はありません。変更すると、ほとんどのドキュメントを処理する必要があります。 この状況では、調査方法によるテストが最も最適な場合があります。
安全にプレイしたいとき
製品はすでにスクリプトに従ってテストされていますが、まだ見逃していないことを確認したいと思います。
研究テストが不可欠な場合：
標準化されたアプリケーション
標準とゲストによって機能するアプリケーション、およびわずかな逸脱が重要になる可能性のあるシステム。 これらは、ミサイルの飛行または金融業務の実施を担当するアプリケーションの場合があります。
統合テスト
この場合、たとえばAPIをテストするときなど、探索的テストが可能です。 ただし、通常、内部アプリケーションコンポーネントの相互作用をテストするために統合テストが実施されます。 この作業はドキュメントで十分にカバーされており、多くの場合自動化されています。
外部委託されたテストケース
アウトソーシングアウトソーシングは異なりますが、正式なシナリオに従ってタスクとその完了の割合を制御する方が簡単です。
長いプロジェクト
特定のフェーズでテスターをプロジェクトに接続し、開発者が新しい機能を実装している間、他のプロジェクトに参加できます。 特定の機能を長期間テストしない場合、その特異性は忘れられます。
神話を暴くか、探索的テストを適用する方法
神話1：
「研究テストは制御できません。制御できません。 停止する時期と、すべての機能がカバーされているかどうかを判断するのは困難です。
場合によっては、研究テストはスクリプトの反義語と見なされ、完全な混乱の中でテストとして扱われます。
実際、測定可能性とタスクの並列化の効果は非常に簡単に達成できます。 作業量を修正し、時間測定可能な部分に分割するだけで十分です。
神話2：
「あなたは先人をテストすることを信頼することはできません
これは部分的に真実です。 ただし、シナリオテストは「ランダム」な人には与えないでください。 実際には、事前に準備された手順のみに従って製品をテストすることは不可能です。 慎重に検証されたシナリオから一歩下がって詳細を処理したいという要望が常にあります。ネガティブチェックを追加したり、割り込み処理をチェックしたりするなどです。 また、製品をテストで完全にカバーすることは不可能であり、ヒューマンエラー要因を完全に排除することはできないため、これは良いことです。
一般に、QAチームのスキルを向上させることは、常にQAユニットの目標の1つです。 エンジニアは研究テストを使用して、以前に得た直感と経験を活用し、製品を絶えず分析することに慣れます。
神話3：
「調査テストを顧客に販売し、その必要性を説明するのは難しい」
実際、プロセスの結果と透明性は顧客にとって重要です。 この場合、結果は、品質に関する顧客の認識を満たす製品です。 そして、プロセスの必要な透明性は、有能なレポートの助けを借りて達成することができます。
シナリオテストの場合に、単純化されたレポートが結果を含むテストシナリオのリストである場合、調査テストレポートの場合、わずかに異なる形式を開発する必要があります。
「良い」研究テストレポートは次のようになります。
- テストされた製品の機能のリスト（テストカバレッジと追加の調査の必要性を大まかに評価するため）;
- 欠陥のリスト（レポートの作成者とテストの段階に応じて、すべてまたは最も重要なもののみが見つかります。また、製品全体の欠陥の総数によっても異なります）。
- 内部レポートは、問題、質問、および/または観察によって補足することができます。
- リスク。 ここで重要なのは、テストされていないことと発生したことに関連して、機能が作業範囲に含まれていなかったこと、サーバーが機能しなかったこと、適切なテストデータがなかったことなどです。
- テスト結果に関する簡潔な結論（テストの最初の目的に応じて-たとえば、レビューのために製品を顧客に転送することは可能ですか）。
当然、これらのポイントは、他の方法によるレポートのテストとの関連性を失わない。
結論
研究テストは、ドキュメンテーションと混乱の完全な欠如を意味するのではなく、強力なツールです。
完全な調査から完全なシナリオまでのテストタイプのランキング、構造化チェックリストの詳細を使用して、プロジェクトに最適なドキュメントのレベルを選択し、時間を節約できます。
シナリオと研究のテストは完全に互換性があり、互いの欠点を補います。 プロジェクトの詳細な技術的側面を詳細なテストでカバーし、ユーザーインターフェイスの表面チェックリストを作成できます。
柔軟に。 製品に最適な戦略を開発します。 あなたのための質の高いプロジェクト。