私の最近の投稿では、テスターが実際に手に持っていた欠陥をどのように見逃すことができるか、いくつかの例を挙げました。 軽率、未経験、素朴、疲労、急いで-それは問題ではありません。 それ自体。 もちろん、プログラマーと一般的な開発文化は助けになります。これはバグではないと言いますが、それでも、説明されているケースでは、彼らの役割は補助的です。
mtikhonの記事「テストに合格する簡単な方法 」では、テスト結果に影響を与える「外部の」問題でそのリストを完全に補足しました。 外部-テスト部門からではなく、他のユニットから、さらに頻繁に-ユニットのジャンクションのどこかで、部門の相互作用で発生するという意味で。 （特別な部門が常に正式にテストに割り当てられているわけではないことを理解しています。しかし、これは見た目の違いであり、本質を変えるものではありません。
mtikhon 'uは、問題のリストが記載されているというコメントでわずかに批判されましたが、それらを回避する簡単な方法はそうではありませんでした。 彼は、順番に、「方法は通常大きく異なる」と正しく指摘しました。 この考えに基づいて、もう少し詳しく踏み込んでみたいと思います。
おそらく、私は同じポイントに直行するでしょう。
1.テスターは製品の変更を認識している必要があります
実際には、ソリューションはタイトル自体で概説されています。従業員に重要な変更を時間通りに通知する方法を見つけると、プロジェクトの生活が楽になります。 さらにテスターだけでなく、プログラマー、アナリスト、そして他のすべての人たちも-彼らも知っているべきです、そうです。 特に、あるチームの作業が別のチームの作業に大きな影響を与える分散プロジェクトの場合。
最初の問題は、このようなアラートの有効な方法を見つけることです。
一方では、すべての情報がすでにそこにあります-すべてがタスクトラッカーに記録されます。 さらに、バージョン管理システムは、最も正確で詳細な変更に関するメッセージも送信します。 一方、一般的に、大量のジャンクメッセージがタスクトラッカーを通過し、誰も自分の作品に属さないものを読むことはありません。 そして、バージョン管理システムからのメッセージは、非常に詳細でアトミックであり、完全に人間の言語ではありません。 最後に、1つの関連する変更を、いくつかの関連するタスクとコミットに関連付けることができます。
さて、通知するタイミングとビジネス変更（ビジネスロジック、アーキテクチャなど）に同意し、通知自体で詳細にこれらの変更を記述する方法を決定したとします（詳細に関心がある人-指定します）。
2番目の問題は、これらの通知を配信する方法です。
起きて声を出して言うことができます。 みんなに手紙を書くことができます。 Wikiまたはその他の内部リソースに配置できます。 あなたはまだエキゾチックな何かを思いつくことができます。 理想的には、もちろん、それはプロセスの参加者に脳の適切な部分にすぐに入れられるでしょうが、今のところ不可能です。 一般的に、どのようになるかを考えるのに数分の価値があります。 長く考える必要はありません。少なくとも何らかの形で始める方が良いです。 その後、調整できます。 さらに、3番目の問題もあります。
彼らが言うように、私たちは川にロバを連れて行くことができますが、アッラーでさえ彼に水を飲ませることはありません。 つまり、彼らがどのように変化について私に通知しても、常にそれらについて知らない機会があります：部屋を出る、このスパムを読まない、特に他の都市から到着するなど
つまり、何らかの方法で受信者にこれらのメッセージを読むことの利点を示す必要があります。 ちなみに、送信者もそうでなければ、通知するのを忘れます。
一般に、このような慣行を未実装にする多くの機会があります。 それがうまくいけば-初期段階でのクレイジーな変更を拒否するまで、メリットは膨大です。
2.外国のバグ
政治はそのような政策です。 正直なところ、「自分の」作品に誰かが追加の問題を見つけたという事実で人が罰せられるようなことはありませんでした。 しかし、どうやらこれも起こります。
おそらく私は元の記事で不明瞭になりました。 いずれにせよ、ポイントは突然誰かの仕事を引き受けたり、誰かの修道院に登ったりしないことです。 自分の仕事に取り組んでいるときに、別の都市が担当している地域で問題が発生した場合は、通常、それについて既に知っているかどうかを尋ねます。 特に、異なるテスト構成を使用していることがわかっている場合。 さらに、この機能のテストが既に完了していることを突然知った場合。 特に問題が私の作品に最良の方法で影響を与えない場合。
すぐにバグを開始する必要はありません-まず第一に、あなたはただ尋ねることができます：それはこのようにここにあります-故意に？ そして、答えを聞いて、もしそうなら、あなたの視点を説明してください。 そして、その側がバグを開始させてください、それが突然重要であるならば、私は気にしません。 同時に、水平方向の結びつきが強化されます。
ところで、重要なポイントは、コメントでRasckoによって強調されています：人は、それが彼でない場合、「それが誰であるか」を知るべきです。 これは大いに役立ちます。一般のメーリングリストに書き込んだり、マネージャーの階層を介して連絡したりすることなく、直接人に連絡することができます。
3. redjectで飛んでいるマイナーなバグとインターフェースのバグ/楽器
不快な、非常に、私は自分の経験から知っています。 一方で、問題を報告するのは私たちのビジネスであり、他方では、作業が無駄になるのは事実です。
ここに質問があります：誰がリダイレクトし、なぜですか？ プログラマーが1つの場合、プロジェクトマネージャーが別の場合（または他のいくつかの場合）、マネージャーはこの欠陥が今では重大ではない多くの理由を持っている可能性があります。このトピックに関する最近の発言は、記事「テスト： ）
また、ソリューションは異なる場合があります。 修正するかどうかにかかわらず、すべての欠陥についてプロジェクトマネージャー、または機能の責任を負うアナリストが決定を下すことに同意することができます。 単に問題を隠して、特定のプログラマーに提案することができます。 これらの特定の欠陥（使いやすさ、生産性、ローカリゼーション）はまだ修正されていないため、まだ特定の欠陥が発生していないという明確なシグナルを得ることができます。これは必ずしも災害ではありません。 おそらく現時点でこれが最善の解決策であり、努力に集中することができます。 そのような契約が有効なポイントまで決定し、期限が切れたときに明示的にそれを振り返る必要があるだけです。
何を選択しますか？ 特定の状況に依存します。 これが最も難しい部分の始まりです。問題を特定し、どのような状況にあるのかを見つけるためです。
4.実験室
テスト環境は重要であり、議論の余地はありません。 そして、一般的に正しい決断です。理想と残忍な現実の間の中間点を探すことです。
テスター自身がテスト環境の欠点とそれらを修正する方法について話す必要があることを強調したいだけです。 残りはこの環境、特にボスについて何も知らないからです。 彼らが来て、鉄に問題があると言うまで、問題はありません、そして、誰もそれを決して解決しません。
彼らは一度やって来て落ち着いた-彼らはそれを高い確率で忘れるか無視するだろう。
定期的なリマインダーのみが、リーダーシップから平和を奪い、問題が決して大げさではなく、解決策もあると信じさせます。 よく、まだ明確な例と数字を手にしています。
テストの一部を顧客/ユーザー（アルファ、ベータ）に渡すことはオプションですが、別の記事のために十分な水中レーキがあります。 しかし、あなたは試すことができます。
5.タイミングとレポート
永遠に関連する問題は、テスターの仕事を評価する方法であり、厳しい締め切りに取り組んでいる人でさえです。 ところで、プログラマーも。
バグの数、重要度、またはユーザーのレビューを見るか、覗き穴だけを見てください。 文学と人生には多くの選択肢があります。
製品の結果/作業条件について話す場合、プログラマーとテスター、およびチームの残りのメンバーの作業も一緒に評価してください。 私たちはすべて一緒に製品に取り組みました、結果も一般的です。
特定のテスターの評価について話している場合、すべてがシンプルに聞こえます。 私たちは彼にいくつかの仕事を与えます。 だから私たちは、あなたから、彼らは言う、これとあれが期待されていることを岸に同意します。 パフォーマンス基準-ここなど。 タイミング...さて、どれくらい必要ですか？ いいでしょう 問題を報告しますか？ それから-彼がしたことを見て、評価します。
実際には、特に慣れていない人からは、はるかに複雑になっています。 それが私たちが話していることです-これらの問題は簡単に解決できません。
締め切りに戻る：締め切りは非現実的であることがわかりますか？ それについて話してください。 必要なすべてをテストするには、多くの時間が必要です。 つまり、これだけテストできます。 より重要なものをテストする時間を確保するために、優先順位を設定しましょう。
6.フォームのバグはどうなりますか：再現性がない、観察されていないなど
ここで、一般に、すべてはパラグラフ3とほぼ同じです。または、何か不足していますか？
7.自動化と手動テスト
問題はよく説明されています。 この場合、決定は特定のプロジェクト/製品に強く結び付けられているため、一般的な推奨事項を提示することは困難です。
唯一のこと：自動化と手動テスト。 これらの概念は戦争状態であってはなりません。 むしろ、反対は互いに補完し、助け合うことです。 さらに、自動化は必ずしも直接的な製品テストに関するものではありません。 手動テストのいくつかのアクション/準備を自動化し、手動テストをより効率的に実行できます。 しかし、手で。
8.会社の全体構造におけるテスターの位置
そして、ここでもすべてがテスターの手にあります。
社内のテスターが高く評価されており、彼らがナンセンスに従事している場合、すぐに彼らはクリーナーのレベルになります。
テスターがプロジェクトとその参加者に真の利益をもたらすと、信頼性が高まります。
もちろん、上方への移動は長く、玉座から落ちるのはより困難ですが、これはどこでも当てはまります。
プログラマーの「ガベージ」からのコマンドセットについては、そのような人々はテスト部門が直面する複雑なタスクに適していないことを示します。 これらのタスクが複雑であり、高い資格が必要であることを証明します。 優秀なスタッフをgivingめ、プロジェクトが何を失っているのかを説明してください。
難しいです。