彼らの主な情報源（または触媒）は、 シリコンバレーにあるSQA Testing School Webサイトのテストエリアの説明でした 。 この説明では、テストは基本的なフィールドとして提示されます。これは非常に迅速に学習でき、そのための知識は最低限必要であり、その中で非常に良いお金を稼ぐことができます。
最初の正しい考えは、「 気分を害するテスト」です。
最初のものは、よりバランスのとれた2番目のものに置き換えられました。 説明は完全に真実です。 テスターの取得は簡単です。 悪いテスターであって、解雇されないのは簡単です。 プロジェクトにわずかな利益ももたらさず、同時に通常のお金を稼ぐことは簡単です。
しかし、彼らの分野には有益な真の天才がいます。そして、テストの分野の「湿った」労働市場にもかかわらず、彼らは非常に有能な専門家です！
彼らは誰ですか？
本物のジェダイと偽のテスターを区別する方法は？
考えの結果は、 現在の試験官と偽りの10の相違点のリストでした。
1.プロジェクトと同時に本物のテスター。
本物のテスターはプログラマーの敵ではありません。 これらのテスターは、「製品を壊す」ことを意図しておらず、その後は手をこすります。 通常、実際のテスターは問題、バグ、欠陥、エラーの存在に満足していません！
プロジェクトにメリットをもたらすには、テストはサービスとして機能する必要があります。 バグはリリースできる製品ではありません。 バグは役に立ちません。 共通の目標を達成することを目的とした活動のみが恩恵を受けます。
このために必要なもの：
*プロジェクトの目的を考慮に入れる
*外部条件（優先度、期限、目標、トップレベルのタスク）に適応する
*見つけることができる：プロジェクトが目標を達成するために、今何をする必要がありますか？
テストが非効率的で、エラーが遅れ、低品質のエラーが発生した場合、欠陥のローカリゼーションのローカリゼーションには開発者から時間がかかり、非優先順位の機関は修正が困難になります。
したがって、実際のテスターは、「多くのバグやDDOSを開発者向けにどのように見つけるか」というタスクの代わりに、「プロジェクトに今必要なもの、フォーマット、優先順位は？」と考えます。
2.実際のテスターはテストを設計できます。
面倒な作業や迅速なテストは不要です！
実際のテスターはテストを設計できます。 これを行うために、彼らは少なくともLee Copelandのテスト設計バイブルを記憶し、最低限でも品質リスク管理を習得しました。
条件に応じて、テストは探索的またはテストケースに応じて実行できますが、テストは「プッシュボタン」ボタンを使用して行われず、分析結果にのみ基づいて行われます：テストする必要があるもの、優先度、および最も効果的に行う方法？
これを行うために、すべてのテストは、製品、その動作に影響を与える要因、およびその後の同等クラスへの分割の調査から始まります 。
最初に考え、次にテストします！
3.実際のテスターは、テスト対象のソフトウェアのアーキテクチャを理解しています。
真のテスターになるためには、高度な開発者である必要はありません。 しかし、アプリケーションを効果的にテストする方法を理解するには、単にそのアーキテクチャを知っている必要があります！
ブラックボックステストでは、製品の詳細な調査はできません。「ユーザー側」でのみテストすると、ソフトウェアの動作に影響する多くの要因が考慮されないという事実につながります。
ブラックボックステストは、窓と目を閉じないブラックボックスでのテストです。 タッチして、製品のある種の粗さにつまずき、「左隅のどこかで何かが間違っている」と間違えます。
目を開けてライトをつけてください！ テスト対象を確認してください！
ソフトウェアの仕組みを学習すると、次のことができます。
*設計テストをより効率的に
*ソフトウェアの動作に影響する要因を把握し、より高いカバレッジを提供します
*エラーをより正確かつ適切にローカライズします。つまり、開発者とプロジェクト全体の時間を節約できます。
4.本物のテスターはコミュニケーションの達人です。
テスターでない場合、誰が悪いニュースを伝えなければなりませんか？ 欠陥を見つけた場合にできる最悪のことは、開発者に「まあ、めちゃくちゃだ！」と言うことです。
欠陥を見つけて登録するだけではありません。 簡単かつ快適に修正できるように、すべてを行う必要があります。
ソフトウェアで修正されたすべてのバグはクールであり、開発者はこれを理解しています。
彼らが以前に彼が「草刈り」、「バジット」、「バギー」であると言われていなかった場合にのみ ！
欠陥について開発者と通信する方法について- モスクワクラブオブ テスターズの会議でのAlexei Barantsevのスピーチの録音 。
5.実際のテスターは、アプリケーションの分野に精通しています。
かつて、会計ソフトウェアの開発に携わるモスクワの会社でテストプロセスの監査を実施しました。 会社の経営陣によると、テスターは多くの欠陥を見逃していました。 その理由は簡単でした。会社のアナリスト（2個）。会社のテスター向けのテストケースを作成しました（15個まで）。 テスターはそれらに合格し、テストケースで文書化されたものからのソフトウェアの動作のすべての逸脱を記録しました。
同時に、彼らは、バランスとは何か、どのような原則のレポートが生成されるのかさえ理解していませんでした！
当然、これは高品質のテストをもたらすことはできませんでした。 テストを設計するためのアプローチを知らないアナリストは（これが彼らの仕事ではないため）、テストカバレッジを最適化できませんでした。 また、悲惨なテスターは、継続的なエージングテストとプログラムの動作の違いのみを探しました。 何かが「間違った」状態になり、この「間違った」状態がテストで文書化されていなかった場合、彼らは欠陥に直面していることにさえ気づきませんでした。
これを防ぐには、実際のテスターが製品の仕組みを知る必要があります。 彼らは、ユーザー、彼の精神モデルを知っている必要があります：製品はどのように使用されていますか？ どのような条件で？ どうやって？
6.本物のテスターは専門家ではありません。
「私は本当の専門家です！」という言葉を聞いたら、偽のテスターがいます。 かろうじて新興産業の専門家になることは不可能だからです。 方法論的基盤はごくわずかであり、さらには継続的に変化するためです。
容赦ないスピードで、新しい技術とアプローチが出現しています。 あらゆる方向の上級テスターが作成し、今すぐ作成します！
そして、まだ形成されていない分野の専門家になるにはどうすればよいですか？ その中で「正しい」と呼ばれるには柔軟すぎるものはどれですか？
「私は専門家です！」=「もう開発しません。」 そして、これは実際のテスターに関するものではありません。
7.本物のテスターは手段ではなく目標を選択します。
自動化が「クール」で手動テストが「退屈」 だからといって、ROIがマイナスのテストはどれくらいの頻度で自動化されますか？ どのくらいの頻度でテストが文書化され、「堅実」であるという理由だけで、役に立たず不器用な紙片の山になりますか？
テストでは（おそらく、他の分野で？）、「クール」、「興味深い」、「試してみましょう」から多くの決定が下されます。
しかし、「クール」の概念は絶対ではありません！ 各プロジェクト、各チームには独自の作業条件があり、効果的なテストは常にコンテキストによって決定されます ！
実際のテスターが何かを実装することに決めたとき、彼らはこう言います。 そして、これらの言葉は本当のテスターと偽物を他の何よりも区別します。
8,9,10。 本当のテスターは仕事が大好きで、製品が大好きで、常に進化しています。
宣言された10個のポイントを一致させるために、さらに3つのポイントを簡単に説明します。
*本物のテスターは自分の仕事を愛し、常に創造性を見つけます。そして、彼らはルーチンを持つことはできません！ 新しいタスクはそれぞれ、より良く、より良く、より効率的に実行されるため、より面白く、より面白くなるからです！
*本物のテスターは製品が大好きです。 ソフトウェアをテストして破壊主義者になることは不可能です。 このテスターのタスクは、重大な欠陥がまったく現れないように、欠陥の数を減らし、予防措置を講じ、初期段階でテストを実施することです。 そして、これらの目標は破壊主義と相容れません;それらを達成するために、製品は壊れてはならず、愛されなければなりません。
*本物のテスターは常に進化しています。 そして、彼らは若い脆弱な産業を開発しています！
結論
本当のテスター自身が結論を導き出します:-)
そして、レッドブックに登録できるこれらの希少な人々に「ありがとう」と言いたいだけです。
じっと立ってくれてありがとう。
プロジェクトの利益をありがとう。
業界を発展させてくれてありがとう！