多くの人は、ソフトウェアのテストはバグの検索だと考えています。 私はテスターに「できるだけ多くの間違いを見つけようとせず、できるだけ少なく見逃そうとしましょう！」と言います。そして彼らは私を理解していません。違いは何ですか？
そして、違いは大きいです！ この記事では、それが何で構成され、実際に有用なテストに使用する必要があるツールについて説明します。
エラー検索とは何ですか？
製品をテストしています。
私の仕事は、できるだけ多くのバグを取得することです。 論理的です！ テスターは常にバグを開始できることを喜んでいます。これは目に見える測定可能な作業の結果であり、彼らが多いほど、テスターとして高く評価されます。
この場合、どの領域をテストしますか？ まず第一に、最も不安定です。 多くの場合、優先順位が低いため不安定です。しかし、問題ではなく、バグの数がはるかに重要です。
再現が難しいバグに遭遇した場合はどうなりますか？ 彼の研究のROIは、頭の中ですぐに考慮されます。 同時に重要度が3つ低くなりますが、簡単に確立できるのに、なぜ彼に迷惑をかける必要がありますか？
そもそもどのようなテストを実施しますか？ 最も標準的でないKoneno。 ログインフィールドに「戦争と平和」と入力し、ゼロで割って、プロファイルに.exe形式のプロファイル写真を挿入します。
秘密をお伝えします-面接で「電卓をテストする」という要求に応えてテスターに面白くて実用的なテストをリストしますが、最初の30 のテストには「チェックの追加」などの基本的な操作はありません 。これは、エラー検索の外観とまったく同じです-テストとは関係ありません。
テストとは何ですか？
製品をテストしています。
私の仕事は、ユーザー優先のバグを可能な限りスキップすることです。 逃したバグが少なければ少ないほど、顧客の不満の表明は少なくなります。仕事の有効性を高く評価します。
この場合、どの領域をテストしますか？ 当然、ユーザーにとって最も高い優先度から始めます。 安定して正常に動作していても、重大な問題を見逃さないように、メインユーザーシナリオを引き続きチェックします。
問題が発生した場合はどうなりますか？ たとえば、再現が困難な欠陥、ユーザーのビジネスプロセスの理解不足、要件の欠如など。 これが重要な機能である場合、「何が間違っているか」、「どのように正しくするか」を見つけます。 その結果、欠陥を確立するのに多くの時間がかかる可能性があり、バグ/時間の観点からすると、テスト効率の結果はそれほど高くありませんが、製品、アーキテクチャ、ユーザーに関するより深い知識があります。
そもそもどのようなテストを実施しますか？ もちろん、最も標準的です。 最も基本的な条件で最も基本的なシナリオを実行して、最も重要な機能が機能することを確認します。 そして、その後のみ、あまり標準的でないシナリオに進みます。
テストおよびエラー検索結果
エラーを検索する場合、短期的には結果が高くなります。より多くのバグがすぐに開始されます。
しかし、長期的には物事はそれほどバラ色ではありません。
- 製品に関する詳細な知識が不足しているため、見逃した欠陥の割合が徐々に増加し始めます
- 開発チームは、満月のIEで同じボタンを144回クリックして取得した、恐ろしく恐ろしい想像できないバグの修正に忙しい
- このリリースは、ユーザーのバグにとって非常に不快で明白なものになります。
- 長期で見つかったエラーの数は減少しています
バグの発見からテストまでの方法は？
テストを長期的に効果的かつ有用にするには、簡単なルールに従って、主要な
テストツールを使用する必要があり
ます。1.製品分析とテスト文書
ボタンをクリックすると、多くのバグを取得できますが、チェックした内容を言うことはできません。 唯一の解決策は、テストを文書化することです。 詳細なテストケース、テスターの意気消沈、多くの時間の消費はほとんど必要ありません。 ただし、「チェックする必要があるもの」の
リストを含む
チェックリストが必要です。
彼らは何を与えます：
- 製品を分析し、主な機能、アクション、それらのパラメーターを書きます。 したがって、何かを忘れるリスクが大幅に削減されます。
- チェックリストは、「ここでさらに深く掘り下げる必要がある」ことを思い出させてくれます。 説明が不十分な不明瞭な機能があります。 それをテストするには？ テストなしのテストで最も簡単な方法は、「後でこれに戻ります」と言い、決して戻らないことです。 また、テストでは、どのように何をチェックするかが明確ではないテストがハングアップします。そのようなテストが表示され、調べる必要があることを忘れないでください。
- チェックリストに同意する必要があります。 開発者、アナリストと。 チーム全体がテストプロセスに含まれ、テスターは製品について多くのことを学び、集合的な心はテストの質を向上させます。 また、1つのチェックリストの品質が1回向上するだけでなく、一般にテストの品質も向上します。テスターはテスト、開発においてより多くのことを考慮し始めます。
テスト実施の成功の鍵は、従うマップを作成することです。 目標は、製品全体をカバーすることです。 ひどいリソース消費について言い訳はありません。1か月半で数百万行のコードでプロジェクトをカバーしました。 そして、そのようなテストを作成する過程で、予期せぬ質問が提起され、重大なエラーが表面化しました。不幸なテスターの存在にもかかわらず、何年もの間製品にぶらついていました。
2.テスト評価
盲目の子猫にならないためには、テストの有効性を評価する必要があります。 見逃したエラーと見逃した理由を分析します。 テストによる機能とコードカバレッジ。 アンケートとフィードバック収集によるユーザー満足度。 開発者に質問することによる間違いの品質。
常に改善すべきものがあり、継続的な改善プロセスの欠如は避けられない沼です。
3.テスト目標のチームとの議論
多くの人は、テストには神話上の目標があると考えています。 そして、それらは常に同じであること。
どんなに！
各プロジェクト、会社、チーム、目標はそれぞれ独自のものです。 誰もが同じように理解していますか？ 大声で話しましたか？
最大限のメリットを得るには、このメリットが何であるかをよく理解する必要があります。 RMと開発者の意見があなたの意見と一致していなくても驚かないでください。 納得させる必要はありませんが、現在の設計目標に適応する必要があります！
4.ユーザーとそのビジネスプロセスを理解する
私にとって、謎はこれがどのように可能であるかですが、それでも事実です。多くの場合、テスターはユーザーについて何も知らずに製品をテストします。
- この製品はどのように使用されますか？
- 彼はなぜ必要なのでしょうか、彼はどのような問題を解決しますか？
- ユーザーの平均的な資格は何ですか？
- ユーザーはどのような条件下で働いていますか？ どのような環境、機器ですか？
当て推量や「平均的な産業」について考える必要はありません！ テスターはユーザーを完全に知っている必要があります。 多くの場合、彼らはこの情報をアナリストに提供しません。 考え直してください！ ユーザーを知らないと、通常の方法で製品をテストすることはできません。
5.アーキテクチャの技術的な資格と理解
説明のために、最近バグトラッカーに持ち込まれたバグを示します。
Firefoxブラウザで、テスト済みの製品http：//****.ruのWebサイトにアクセスします
ユーザー名とパスワードを入力してください
同じコンピューターからOperaにログインします
ユーザー名とパスワードの再入力を要求しますが、自動的にはログインしません。このようなバグは役に立たないだけでなく、テスターを傷つけ、業界全体の信用を傷つけます！ 欠陥を正しく開始するには、テスト対象の製品が書かれているプラットフォームを理解する必要があります。 Webテストについて話している場合、少なくともサーバーから返されたエラーコードをバグレポートで示し、firebugで詳細を確認し、詳細な情報を提供して、開発時間を大幅に節約できます。
結論
多くの開発者はテスターが好きではありません。 そして彼らはそれを正しくやっている！
しかし、優秀なテスターは誰もが愛し、感謝しています。 しかし、クリッカーやバゴダーではなくテスターです！
何が間違っているのか、開発チームの他のメンバーが嫌いなものを見つける方法を学びます。 見逃したエラーを調査し、見逃さないようにすべてを行ってください。 バグを追いかけないでください-あなたのマントラは「ユーザーの幸福」、「高品質の製品」、および「成功したプロジェクト」であり、「できるだけ多くのバグを取得する」べきではありません。
そして、力があなたと共にありますように！