- 彼らは自信を持ってボタンを押す方法を知っている人なら誰でもテスターの役割を引き受ける準備ができています
- テスターはプロジェクトの運命にほとんど参加せず、要件と期限を決定します
- 「クリック」および「エラーの検索」が必要な場合、可能な限り遅くテスターを接続しようとします。
- 少数の食品会社を除き、ほとんどの雇用者はテスターに開発者よりも1.5〜2倍低い給与を提供しています。
これが起こる理由は非常に理解しやすいです。資格のあるテスターに実際に会った人はほとんどいません。テスターは有用な結果を出しません（製品を作成しません）。一般に、できることはすべて節約するのが慣例です。 別の質問は興味深いです： このアプローチのおかげで何が起こるのでしょうか？ 例を見てみましょう。
給与を節約しましょう
ここではすべてが明確です。 プロジェクトがより多くの利益をもたらすためには、より良く売られ、生産コストを削減する必要があります。
OK、ボタンを突いてシステムにエラーを登録する低コストのテストスペシャリスト（ほとんどの場合、学生または新卒者）を雇いましょう。 作業量が増え、彼が対処しなくなると、2番目の仕事を雇い、徐々にテスト部門全体を構築します。 一見したところ、すべてが非常に良いように見えますが、いくつかの小さなことはそうではありません。
- 熟練していないテスターは、詳細な分析なしでバグを取得します。 このようなエラーは、ローカライズおよび修正が困難です。 たとえば、開発者は1週間に50個のエラーが発生するたびに、分析に平均15分余分に費やします。 本当に目立たないささいなこと！ 年間わずか600人の開発者時間 -または3.5人月 ！
- 時間が経つにつれて、サポートされるコードのサイズが大きくなると、定期的な回帰テストが必要で、何も壊れていないことを確認する必要があります。 学生テスターは、リリースからリリースまで同じテストを意図的かつ系統的に実行し、ときどきエラーを見つけます（こんにちは、 農薬の影響 ！）誰かが自動化（ほとんどの場合、RM）のアイデアを思いつくと、これらの人はコピーアンドペーストを使用した数百のスクリプト-そして、手動テストの代わりに、自動テストが各リリースを更新します。 ある時点で、このすべての幸福を維持するために、 より多くのテスターが必要になります 。 そして、多くは常に高価です。
- 最終的に、テスターの数が増えているにもかかわらず、生産的な環境でエラーが発生します。 ユーザーをwearり、信頼を失い、時間を無駄にします。 一般に、 過剰なリソースを使い続けます 。
そして、ある時点で、遅かれ早かれ、すべてのRMはテスターがかなりの資格を持ち、より強力な人を見つける必要があることを理解するようになります（ただし、この混乱した荷物すべてを常に追いつくことができなくなります）それらは彼らのために蓄積しました）。 それにもかかわらず、テストを適切に設計する通常のテスターが存在し、自動化フレームワークが適切なテストを準備します。 そして、すべては順調ですが、テスターは単なるテスターです。 だから
テスターが製品にすぐにアクセスすることを許可しないでください。
「今、価値のあるバージョンのテストを作成し、すべてが正常であることを確認し、見つかったささいなものを見つけ始めるだけです！」
ここで、何らかの理由で、問題が再び始まります。
- プロセスに接続された後、テスターは環境を掘り下げる時間がありません。 ビジネスシナリオ、ユーザーの作業環境、および多くの設計、アーキテクチャ、設計の決定を下す理由についての理解が不足しています。 この段階で、「おろし金」は、どのように、何を実装すべきかについてのさまざまなビジョンのために始まります。 テスターは知識がないか、異なるビジョンを持っていますが、設計ソリューションの開発には参加しませんでした。 おめでとう、多くの変更が行われました。低品質のテスト、相互の不満、製品の重大な変更のための時間の不足があります 。
- プロジェクトに長い時間を費やした後（多くの適切なテスターはそのような条件下では単純にそれを行いません）、テスターは環境をよりよく理解し始めます。 要件の開発と顧客とのコミュニケーションに関与している場合、成功の可能性が高まります。 しかし、受け入れられているので、最後の段階でテストを接続し続けますか？ ほとんどの場合、次の2つのいずれかが待ち受けています。テストに十分な時間がない場合、エラーはスキップされます。 期限を変更できる場合は、大幅な変更を行う必要があります。 もちろん、これは単なるバグ修正であり、それで問題ありません...それまでは、特にリリースの最後の段階で、どうすれば回避できるのでしょうか？
さて、賢い人は、少なくとも自分で間違いから学ぶべきです。 このすべての幸せを見て、あなたは何かが間違っていることを理解しています。 初期段階でテスターをプロジェクトに接続し、統合ソリューションの準備が整うまでユニットテストを準備し、チームとの決定について話し合います。また、ホットなプレリリースシーズンでは、空のディスカッションや製品の遅延変更に時間を浪費しません。
そして、次の「しかし」のためでなければ、すべてがうまくいく可能性があります。
テスターは製品の品質に影響を与えることはできません。
適切な強さと欲求があれば、テスターはそれを評価できます。 コミュニケーションスキルが不足している-特定の変更の重要性を正当化する。 しかし、結果に影響しますか？
医学では、超音波検査機が何かを治したという事例はまだ知られておらず、検査は単なる診断に過ぎません。 そして、この段階で、テストチームにまだ十分な能力と切れ目のない従業員がいる場合、新しい「おろし金」が始まります。
- より有能な自動化のために、製品には簡単にサポートされるロケーターが必要です-pffff！ 「もう一度、テストに余分な時間を費やしてください！」とRMは言い、チームが何もすることがないときに近づくことのない時間までタスクを延期します。
- テストカバレッジとその弱点をより正確に評価するには、詳細な分解された要件が必要です-pffff！ 「官僚主義を育てるのに十分で、機敏です！」
- ユーザーをよりよく理解し、ビジネスシナリオを策定する段階でターゲットオーディエンスを引き付け、ユーザビリティを評価する必要があります-pfffff！ 「これにより、リリースは2週間延期されます。ユーザーのレビュー後にやり直すことをお勧めします！」
徐々に、すべての良い始まりが煙突から飛び出します。品質を確保する代わりに、テスターができることは、見つかったエラーを即座に報告することです。 RMの品質を改善する必要性を宣言すると、実際には、RMに投資する準備ができておらず、徐々に崩壊します。 古い機能のサポートには、ますます費用がかかります。 私が図に描いた2つのアプローチでのチームリソースの時間的分布の違い：
そして、品質と効率的なプロセスの確保にリソースを投入し始めると、最終的には、新しい機能の開発に取り残されます。 どんなに予想外であっても、それは聞こえるでしょう。
結論
要約すると：
- 自動テスト開発者は開発者です。 テストアナリストはアナリストです。 開発者やアナリストよりも少ない資格要件でテストのために人々を募集する場合、徐々にチーム全体に穴を掘ります。
- テストは開発の一部であり、次の段階ではありません。
- テスターのみがテストと品質保証に参加できません 。 製品とプロセスは、テストと改善の可能性に貢献する必要があります。最初から投資しない場合は、サポート、変更、テスト、顧客とのコミュニケーションの難しさについて、さらに多くを支払う必要があります。
それはまだまれですが、旧ソ連では賢明な品質保証プロセスが発生し始めています。 より良いものに変える準備はできていますか？