高速テスト？ これは機能しません

時々、何かを「すばやく」テストしたいことがあります。 ほとんどの場合、これは、自分が何をしているのか、そしてその理由を正確に知らない限り、うまく機能しません。

1。

あなたは小さな会社で製品開発をリードしています。 開発プロセスは2週間の繰り返しに基づいており、顧客向けに既製のスナックのデモを定期的に実施しています。 開発者は非常に強力で経験豊富で、製品はあまり複雑に見えなかったため、最初はプロジェクトにテスターがいませんでしたが、現在はありません。
開始から6か月間、あなたは良い仕事をしました。顧客は一般的に作業の進捗に満足していますが、もちろん、デモ中の製品の転倒や不適切な動作は彼を混乱させます。 最後のデモは特に成功しました。技術的な問題が発生したため、新しい機能を表示することはできませんでした。 顧客は、製品の安定性と品質にもっと注意を払うことを要求しました。
計画によると、プロジェクトが完了する前に3回半の反復が残り、開発者はすでに時間を計画しているため、テスターを雇って、すべてをすばやくテストし、少なくとも主要な問題を取り除き、それによってかなり良い製品を作成できるようにすることにします。
ねえ、それは動作しません！

テスターを雇うと決めた瞬間に、当番のブラウニーが適切な候補者のリストをテーブルに置いたと仮定しても、それぞれに連絡して自分で電話をかける必要があります。 そのため、現在の職場を辞める必要があります。職場に来たら、1日をかけて職場を設定します。 要するに、決定からプロジェクトへのテスターの登場までに2週間半がかかります。 2つの反復が残ります。
テスターの最初のイテレーションでは、製品と理解に慣れるために時間がかかりますが、ここで何をしているのでしょうか？ 繰り返しの半分にも関わらず-1週間はまだかなりたくさんあります。
つまり、割り当てられた時間内に、テスターは最後の3週間だけで少なくともある程度の利益をもたらすことができます。 そして-状況を分析し、期待を明確にする時間を彼らに与えることはほとんどないので、むしろ混oticとした利益になります。 優先順位を決められるといいです。
だから、3週間。 しかし、テスターは問題を見つけて、他の人にそれについて話すだけです。 開発者は問題を修正する必要があり、その時間は1か月前に計画されていました。
発見された問題の一部は、製品の誤解が原因です。6か月間開発されたロジックのニュアンスが1週間で新しい人に明らかになるとは思わないでしょうか。 そして、確かに微妙な違いがあります。そうでなければ、顧客への製品デモで問題はないでしょう。 要するに、問題の一部はごみです。 しかし、誰かが時間をかけて、ここにバグがあるかどうかを理解する必要があります。
ところで、テスターが掘り下げたすべてを修復するつもりはありませんか？ また、発見されたバグに優先順位を付ける必要があります。
繰り返しになりますが、製品の知識が乏しいため、ささいなことを見つける機会はありますが、2日目に顧客が来る深刻な問題を見つけることはできません。

一般に、未知の結果をもたらす未知の人々の3週間の作業には、あまりにも多くの質問と大騒ぎがあります。

2。

最初のデータは同じですが、違いは1つだけです。対象分野に精通した経験豊富なテスターを雇うことに決めました。彼らは作業に迅速に関与し、より多くの利益をもたらすことができます。
いいえ、機能しません。

今回、私はまだ尋ねます：あなたはそれらをどこで探すのですか、とても経験豊富で便利ですか？ そして、あなたが見つけたとき-あなたは自分にどのように電話しますか？
テストでは、プログラミング（およびその他の職業）のように、経験豊富で適切な専門家に感謝します。 ほとんどの場合、彼らは現在の職場で優れています。 労働市場（特にオープン）では、これらの専門家はそれほど頻繁に登場しません。
彼らがあなたに行くために何を提供できますか？ 燃えているプロジェクトと漠然とした見通しでの作業の1か月半、それから彼らは、まだ仕事があるのでしょうか？ テスト部門の責任者になりましたか（同じ月半）？ ところで、昨日、以前は一流だがエンジニアだった経験の浅いリーダーが必要ですか？

しかし、これはほんの始まりに過ぎません。採用されたテスターの下では、開発プロセスを再構築し、テスターとプログラマーの間の通信を確立し、稼働中のマシンとテストラボのハードウェアを探す必要があります。

いいえ、1か月半ではありません:)。

3。

別の状況。
テスターは既に働いており、働いています。 プロセスはデバッグされます（まあ、多かれ少なかれ）、別のテスト環境などがあります。 基本的なニーズはいわば満たされています。
仕事は本格的であり、プロジェクトは順調に進んでおり、一般的にはすべてが整然としています。
本当にもう1つの機能だけが必要です。 まあ、彼女は正しい、そしてただ一人です。 そしてプロジェクトの完了-それはすでに見えており、収まるようです。 さて、これもやってみましょう-私たちはそれをやります。
プログラマーは、最後から2番目の反復でそれを行うことを約束します。 そして-すぐにテストします。

しないでください！ 動作しません！

いずれにしても、「すべてがまったく同じになるという形ではなく、この機能はもう1つプラスです」という形ではありません。 同じではありません。
になります-要件の少しあいまいさ。 プログラマはもう少し長くなります。 製品内の不明な依存関係がいくつか表示されます。 テスト領域がわずかに増加し、テストに使用できる時間が減少します。 若いテスターは病気になります。 誰もが急いで何かを逃します。
クラシック
そして、あなたの小さな機能が製品に深く根付いていない場合、非常に良い結果が得られます。 そうしないと（ほとんどの場合）、問題はどこか別の場所に現れ、少し脇に出て、どこかを見ることを忘れます。
適切なカバレッジを備えた適切な自動テストが役立ちますが、残念ながら、保存できません。最終段階でテストを開始しました。修正するのに十分な時間がありませんが、後で修正を確認する必要もあります...
一般的に、製品の品質が最終的に低下することに備えてください。 そして、もし機能がそれだけの価値があったなら。 そしてさらに良い-あなたはそのような素晴らしい機能のために放棄する意思があるものを事前に決定し、そして-事前に切断します。
そして、ある種の私たち自身の欺ceptionは違ったものになるでしょう。

あの しかし、一般的に-少なくともいつかテストは機能しますか？

もちろん、この問題には多くの質問やニュアンスがありますが、実際にはい。
「迅速に」テストすることでさえ、非常に合理的な決定になる可能性があります。実際には、優先順位とタスクにすべて依存します。
しかし、この混oticとしたシステムに不安定性を導入しない方が良いです。

最後になりましたが、テストだけではだれも役に立たないことを忘れてはなりません。 テスターは問題を見つけるかもしれませんが、他の人はそれを修正しなければなりません。 テスターを引き付けても、真空球の世界に住んでいれば何も変わりません。 強さは、プロセスのすべての参加者（プログラマー、テスター、マネージャー、その他のアナリスト）の効果的な相互作用にあります。