しかし、よく見ると、生産的な協力の外観は、開発者の理解の絶対的な不足を隠していることがよくあります。「これらのテスターはなぜですか??」 この誤解はしばしば相互的であり、明らかな平和性にもかかわらず、共同作業での生産性の出現のみを残します。
なぜこれが起こっているのですか？
1.資格のあるテスターはほとんどいません。
これは、「適格」と分類できない圧倒的多数のテスターに対する開発者側の非常に期待される否定的な態度を引き起こします。
2.テストは常に有益とはほど遠い。
一般に、テストの有効性を評価することは困難です。 すべてのプロジェクトが理解可能で測定可能なテスト目標を自慢できるわけではありません。 したがって、テスターは「バグが多いほど良い」と考えることがよくあります。 しかし、見つかった欠陥は良くありません！
3.テストはしばしば開発から「時間がかかります」。
製品とそのアーキテクチャを深く掘り下げるために、適切なテスターは必然的に開発者を掘り下げます。 さて、誰がこれを愛していますか？ :)
4. PMは、「バグがありますか？ 修正する必要があります！」
ただし、すべてを修正する必要はありません。特に、すべてを修正する必要はありません。 これを理解している多くの開発者は、RMと議論するよりも欠陥を隠すことを好みます。
5.一部の開発者は、バグがあることに腹を立てています。
また、原則として、論理的です。 試した、試した、そしてバム-間違い！ 私たちはこれが正しいこと、そしてこの方法でソフトウェアを改善することを意識的に理解していますが、無意識のうちに不快であり、繰り返しを防ぎたいと思います。
結果は何ですか？
結果は悪循環です。 上記の5つの理由（およびそれらだけでなく）により、開発者はテストが必要ないと考えています。 結果として、彼らはテストをサポートしていません。 その結果、テスターは最大限に活用できず、これはすべて同じ理由の繰り返しにつながります。
標準スキームでは、開発者が作成して作成し、テスターにテスト用の製品（製品！）を渡すと、大きな待ち伏せが発生します。 たとえば、カスタム製品のように見えるものが形になるまでに、開発の半年である3か月が経過しました。 この製品はテスターによってテストされています。 ローカライズの方法が明確ではないガスの欠陥を作ります（そして、開発者は、悪いバグと交尾し、何がどこで間違っているかを長い間見つけます）。 ローカライズするのが難しく、修正するのが難しく、最悪なのはバグが表示されて表示されることです。 明日リリース？ そして、ここにはさらに10人の批評家がいます！ 冷戦が始まります:)解放されましたか？ そして、バグはすべてあります。
そして、テストの無用性に関する意見が確認され、すべてが輪になります。
どのようなテストを行うと、このようなおいしくて健康的な開発ができますか？
実際、明確なテスト目標がない場合、上記のイベントの開発に驚くことはありません。 しかし、それは異なって起こります。 幸いなことに:)
どのプロジェクトも、できるだけ早くリリースし、成功し、可能な限り高品質でリリースしたいと考えています。 もちろん、製品の欠陥に関する情報は製品のステータスを評価するのに役立ちますが、発売はより速く、より成功しますか？ ほとんどない。
何が役立ちますか？
1.テスト目標の形式化。
なぜ必要なのですか？ 結果として何を得たいですか？
最初に「まあ、テストの恩恵はない」というアイデアを思いついたら、それはありません。 そして、掘り下げて、カブをひっかいて、ブレーンストーミングし、心を揺るがすように描くなら、いつそれがあなたにとって最も適切であるべきかを常に理解することができます。 しかし、ここで成功するための鍵は、構造の外観だけでなく、開発とテストの非常に緊密なコラボレーションです。
2.開発の最初の日からのテスト。
これは、ほとんどすべての開発者が実行するものです。 しかし、無駄に。 通常、開発者のロジックは次のとおりです。「完成品はまだないので、何もテストする必要はありません！」。 しかし、完成した製品のバグを見つけるのはより難しく、後で、より長くなり、それらを修正することもより難しくなります！ 最初のコンポーネントが少なくとも少しの安定したインターフェースで表示されたらすぐに、テストする必要があります！
コンポーネントテストは他に何を提供しますか？
- シンプルなバグ修正。 問題を長時間ローカライズする必要はありません。どこに問題があるかすぐにわかります。
- 隠れた欠陥を見つける。 複雑なアーキテクチャを持つ大規模な製品では、下位レベルの欠陥は常に簡単に隠すことができます。たとえば、UIに何かを入力させないでください。 しかし、下位レベルにバグが存在し、ユーザーには見えない場合、製品にはバグはありません！ しかし、彼が明日現れるリスクがあります:)彼が今日キャッチし、リスクを平準化することを妨げるものは何ですか？
- ソフトウェア安定化期間の短縮 。 通常、プロジェクトの欠陥収束のグラフとは何ですか？ 誘発された欠陥の重大度は、特定のポイントから減少し、その数は増加します。 これは、テストのために機能を「ロック解除」する期間です。 プログラムでウィンドウが開きませんか？ ブロッカー。 しかし、このフォームには10個の欠陥はありません。 修正しましたか？ ただし、入力フィールドは機能せず、ウィンドウ内でさらに9つの問題が発生します。 批評家。 修正しましたか？ テキストボックスに10個の小さなエラーが見つかりました。 等 再帰。 エラーは増えますが、エラーは少なくなります。 それまでの間、エラーはほとんどありませんが、それらは恐ろしく、テスターは修正を見込んで天井に吐き出します。 開発者の半分も天井に吐き出します。なぜなら、彼らにはバグがなく、「バグ修正」段階にあるからです。 コンポーネントのテストにより、すぐにそれらの半分を見つけることができます。 だから-バグ修正、便利なときに、あなたの計画を現実的に評価します。
3.情報共有。
つまり、情報を共有します。 最大限に。 ソフトウェアの動作を知らずにソフトウェアをテストする方が効率的であると誰かが言った場合、あなたはだまされました。 テスターは、操作の実行に影響するものを知りません。 UIオプション？ 問題ありません。 しかし、通常、それらに加えて、開発者だけが知っている多くの要素がまだあります。
どうする
共有し、喜んではいけません！
今日の隠れた小さな欠陥は、明日の大きなhemoのリスクです。
4.欠陥に対する一般的なアプローチを開発します。
もちろん、開発者が今日何らかのバグ修正に切り替えたくない場合は、バグを隠すためにあらゆることを行います。 昔ながらのように聞こえますが、彼らは今やっていませんか？ 真実ではありません。 これは自然なプロセスです:)
しかし、BTS（バグ追跡システム）のバグが単なる情報であり、常に行動へのシグナルではないことを開発者が知っている場合、その存在は混乱しません。
同時に、テストのために、時々いくつかのバグの修正が非常に重要です。 これらはブロッカーと呼ばれます（これらはユーザーの観点からはそれほど重大ではないかもしれませんが、機能の重要な部分のテストを妨げる欠陥です）。 ここで、それらは本当に修正され、重要であり、できれば迅速である必要があります。
5.オウムの結果を測定しないでください。
プロジェクト管理者は、リリースの数時間前に批評家を見つけたテスターを称賛することがあります。 たくさんのバグ？ よくできました。 開発者も、たとえばKLOCを使用して、リーダーシップを測定しようとすることがよくあります。 しかし、コードの量もバグの数も、リリースに近づくことはありません。 チームワークの指標とは実際には何ですか？
リリースのみ。 タイムリーで高品質。
そして、これは、欠陥、コード行、平均的な重要度、その他のがらくたが、管理者が実権を握ってチャートを見るのに役立つ形式主義であることを意味します。
ps私が働いていたある会社では、ある晴れた日、コードの記述行数による開発者の評価を紹介しました。 翌月、合計はコミットされたコードのほぼ2倍になりました。 その品質を想像してください:)
形式主義は数字に焦点を合わせ、結果から遠ざかります。
6.製品のテスト容易性の確保。
私たちにとっては非常に重要です（テスターだけでなくプロジェクト全体です！）ソフトウェアをすばやくテストできるようにすることです。 そして、このために、あなたは時々試さなければなりません。 ブロッカーをロックしますか？ テスト用の追加インターフェイスを作成しますか？ インターフェイスの安定化を約束し、あらゆる面で約束を守りますか？
これは重要です！ とても...
結論
すべてのプロジェクト参加者は、効果的なテストに興味を持っています。 開発コストとバグ修正を節約し、プロジェクトリスクを平準化し、製品の品質を向上させ、開発者を不要なタスクから救います...一般に、プロジェクトが正しくテストされると、発見される欠陥の総数は通常より少なくなります！
しかし！
テスターは、開発者やRMの支援、サポート、理解なしに、この「最も正確な」テストを常に提供できるとはほど遠い。
これを実現するには、より多くのコミュニケーションが必要です。 誰がテストの結果を期待し、どのような目標を設定するかを見つけます。 誰が助けを必要とし、誰が現在のプロセスにあるのが好きではありません。
このような問題を率直に議論することで、テストとプロジェクト全体をより効果的にすることができます。この道の主な障害は、顧客ではなく、ツールではなく、テクノロジーではなく、 誤解です。