11月の「テスターカレンダー」の著者は、Kontur.EkternaのテスターであるOlya Fazulzyanovaと、Kontur.BillingのテスターであるOlya Izyuryevaであり、テスターのコースのオーガナイザーです。 少女たちはペアテストについて、それが解決するのに役立つタスクについて話し、練習の失敗した使用の例を与えました。
XP方法論には実践があります-ペアプログラミングです。 多くのソースが、その利点の大部分について書いています：コードの高品質、開発者の互換性など。
ペアプログラミングが非常に効果的な場合、テストで同様の原則を適用してみませんか？ はい、これを行うことができ、ペアテストは長い間存在し、それ自体が十分に証明されています。 しかし、練習は問題を解決するための単なるツールであることを忘れないでください。
ウィキペディアには「ペアテスト」という用語はありませんが、ペアプログラミングには定義があり、これを基礎として使用できます。 そして、私たちの意見では、次のようになります。
ペアテストは、同じ職場の2人で1つの機能のテストを実行する手法です。 1人のテスター（「リード」）がコンピューターを制御し、2番目（「ナビゲーター」）が最初のテスターの作業を継続的に監視します。 さらに、タスクの作業を通して、彼らはアイデアを交換し、議論します。
練習は単なるツールです。 私たちは顕微鏡で釘を打ちたくないので、常にタスクから始めます。 「ペアテスト」の実践の使用が関連するタスクを見てみましょう。
タスク：メンタリング
いつでも、新しい人がチームに来ることがあります。 彼からのチームへの期待-チームとプロジェクトの詳細、そしてもちろん彼らの仕事の質にかなり素早く浸ること。 期待を急速に現実のものにするために、多くの企業に指導プロセスがあります。 しかし、ペアテストを通じてメンタリングが実装されるとどうなりますか？
例：
新しいテスターがプロジェクトに来ましたが、経験があるかどうかは関係ありません。 メンターとして、あなたは作業コンピューターで彼と一緒に座って、次のようにプロセスの構築を開始します。最初の段階では、主な役割があり、主な目標は、初心者にプロジェクトプロセスとサブジェクトエリアを紹介することです。 知り合いは、ストーリー、プレゼンテーション、またはタスクの共同テストを通じてすぐに知ることができます。
問題の本質について話し合い、質問の答えを見つけ、テスト計画を作成することから始めます。 すべてのテストの準備ができたら、キーボードとマウスを使用してテスト方法を示し、初心者が観察します。 後続のタスクで役割とジョブを変更することを禁止する人はいません。 主なものは本質を変えることではありません-パートナーに自信を持つまで、1つのワークステーションでのタスクの共同テストです。
利益：
- 初心者はチームでより早く適応します。 彼にはエントリーポイントがあります。メンターを通して、チームの他のメンバーと知り合うことができます。 また、初心者は同僚の責任範囲を把握できます。これは、質問への回答を検索するときに、すぐに適切な人に同僚を送信するためです。
- 初心者はすぐに新しいサブジェクト領域を見つけます。
- 初心者がテストを経験していない場合、実際に新しいテスト手法について学び、その適用性を評価します。
- 開発プロセス、技術、テストツールに関する知識の共有があります。
- 初心者の見方は不明瞭ではないため、新しい非標準シナリオを導入できます。
- メンターは、新しい人の準備レベルを迅速に判断します。 これにより、開発ベクトルをタイムリーに修正し、タスクを選択できます。
- テストリーダーや開発マネージャーは、初心者の適応に気を取られません。 初心者は上手で、最初のタスクの品質に問題はありません。
ミニ出力：
パートナーが経験のない人で、初心者からスペシャリストにすぐに変える必要がある場合は、練習が適しています。 経験豊富な初心者と仕事をすることには利益があります。メンターを含め、誰もが学びます。 結局のところ、各人は独自の方法で作業し、独自の方法とツールを使用して、独自の方法で考えます。
タスク：継続教育
作業を正常に完了するには、関連する専門分野の知識が必要であるという事実に遭遇する可能性があります。ドキュメントを作成したり、タスクを自動化したりすることができます。 チームのメンバーに連絡してください。
例：
テスターとしてのあなたには、単体テストでカバーするのにより適切なタスクがありますが、十分な資格がなく、開発者に助けを求めます。 作業コンピューターの1つで彼と一緒に座って、次のようにプロセスの構築を開始します。開発者はコードベースと利用可能なテストを紹介する必要があるため、最初は開発者が主導的な役割を果たす必要があります。 次に、スクリプトをまとめて自動化を開始します。 開発者は最初のテストを作成し、観察し、次のテストをすでに自分の手で行います。
利益：
- プロジェクトがどのように配置され、どのテストがすでに存在するかをすぐに理解できます。
- テストを書くだけでなく、正しく（スタイル）書くことを学びます。
- 開発者は、テストシナリオに関するアイデアを拡張します。これは、箱の外で考える方法を示すためです。
- 開発者は、テストに渡す前にコードの品質を確認することを教えるため、テストプロセスの理解を広げます。
- タスクは、より短い期間で自動テストでカバーされます。
- マネージャーまたはチームリーダーが、あなたの成長を願っています。
ミニ出力：
ペアで作業することで、新しい分野の知識を迅速かつ効率的に得ることができ、実際にそれらをすぐに修正できます。
タスク：不可欠な要素を取り除く（ bus-factor ）
非常に多くの場合、チーム内に人がいます-特定の知識を持つ唯一のキャリアです。 多くの場合、テスターはユーザーシナリオ、サービスの実装方法、テストのために構成する必要があるものなど、すべてを知っているため、そのような人物になります。 しかし、人生にはプロジェクトから知識源を奪う可能性のある状況があります（解雇、休暇、病気休暇など）。 したがって、結果を最小限に抑えるために、安全にプレイし、事前に1人のヘッドから複数のヘッドに知識を共有することができます。 どうやって？ もちろん、ペアテストを通して！
例：
テスターとして、チームメンバーをタスクに没頭させ、神聖な知識を伝達する必要があります。 あなたは彼と一緒に1台の稼働中のコンピューターに座って、次のようにプロセスを構築し始めます：あなたは常に主導的な役割を持ち、最初から情報源を伝え、そして/または示し、得られた知識を統合するのに役立つタスクを更新、選択、分析します。
利益：
- 責任の圧力が減り、休暇やインターンシップなどに安全に行くことができます。
- ペアで作業すると、コンテキストを変更し、高度に専門化されたテスターのルーチンを希釈できます。
- マネージャーは落ち着いています。何人かの人が知識を持っているので、1人が離れても仕事は起こらないからです。
ミニ出力：
狭い専門家がいる場合は、ペア練習を行います。 互換性と関連情報の送信を強化します。
タスク：フィードバックを取得する
テストチームが複数の人で構成されている場合、フィードバックの実践が適用されます。 ペアテストは、OSに適したツールです。
例：
あなたまたはあなたの同僚はフィードバックが必要です。 あなたは彼と一緒に1台の稼働中のコンピューターに座っています。 プロセスをどのように構築するかは重要ではありません。主なことは、連携することです。
利益：
- あなたまたはあなたの同僚は、パートナーのスキルについてのアイデアを持っています。
- あなたまたはあなたの同僚は、フィードバックに基づいて開発ベクトルについてのアイデアを持っています。
- 同僚に関するフィードバックは、例によってサポートされるため、合理的です。
ミニ出力：
一対のセッションにより、テスターは同僚の作業を観察する機会が得られ、その結果、フィードバックの信頼性が高まります。
ペアテストで解決できるタスクを分析しました。
ここで、このプラクティスを使用するときに発生する可能性のある落とし穴を明確に説明するために、実際の経験について話しましょう。
人生の場合、または私たちのようにしないでください
テストチームの回顧の1つで、次の問題が特定されました。
- 不均等な作業（同様のタスクをテストする方法と時間は、特定の人に大きく依存していました）;
- あまりにもあいまいなお互いのフィードバック（多くの場合、1人のタスクのみが1つのタスクに従事し、6か月の終わりには、多くの同僚について何も書くことができませんでした。
これらの問題を定式化して、次のタスクを設定します。
- 経験を交換し、同様のタスクをテストするための最良の方法とツールを特定します。
- より詳細なフィードバックを収集するための条件を作成します。
ペアテストのプラクティスを使用してそれらを解決することに同意しました。
同僚と私は同じテスト作業に乗り出しました。
作品の前面は非常に大きく、必要でした：
- 新しいサブジェクト領域を理解します。
- 分析を確認し、その中の未説明のシナリオを見つけます。
- テスト環境を準備します。
- テストデータを準備します。
- テストケースを作成します。
- そして最後にテストします:)。
これはすべてゼロから行わなければなりませんでした。
1台のコンピューターの背後で、分析を読み始めました。 1つの段落またはテキストの一部を読んで、発生した質問について話し合い、最初のテストケースを既にスローすることに同意しました。 分析はかなり不十分に開発されており、ビジネスと技術の部分が混在していたため、10行のテキストを議論するのに15〜20分かかることがありました。 さらに、最終的に各問題に対処するために、アナリスト、開発者、またはテクニカルサポートの専門家による明確化が必要でした。 これらのメッセージと手紙もすべてペアで書かれています。
新しいサブジェクトエリアは非常に複雑だったため、テストケースをコンパイルするには、複雑な環境を設定し、テストデータの一部を準備する必要がありました。 ここでも、多くの質問と共同説明がありました。
これらすべてに直面して、作業の進行とペアテストの成功について議論するために、会議を遅くして開催することにしました。
会議で、私たちは実践を適用し始めたので、その使用目的を完全に忘れていることに気付きました。 テストケースの実行には至らなかったため、すべての注意はテストのみに集中しました。むしろ、テストの準備にさえ集中しました。
作業の過程で、すべてのアクションを議論する前に一緒に実行したため、相互の本格的なレビューを行うことができませんでした。 新しいタスクを紡ぐときに、パートナーの思考と行動の列に気づきませんでした。 対象分野は私たち両方にとって新しいものだったため、知識を交換することもできませんでした。
厳密に言えば、知識を共有することが判明しましたが、これらは次のような些細なものでした：
- 新しいホットキーを使用する
- 特定のバグトラッカーチップを使用して、
- ...
このような高価なプラクティスに頼ることなく、この知識を共有できます。
会議の終わりに向かって、私たちは自分たちのために結論を出しました。
練習を適用すると、最初のタスクを忘れてはなりません。
最初はすべてが正しく行われたようです。 私たちは問題を定式化し、タスクを設定し、ソリューションツールを選択しましたが、作業自体の間に重点がシフトしました。 このケースでは、2人のテスターが1つのタスクに従事していることのみを達成しました。
練習が適用されるように、テストタスクを選択します。
新しく複雑で膨大なタスクは、ペアテストにはあまり適していません。
-誰かを訓練するのが難しい。
-経験を交換することはできません。
-フィードバックを収集することは困難です。
問題をglossめないでください。
何か問題が発生したと感じたら、すぐにそれについて話し、タスクの終了またはチームの最終回顧展を待たないでください。 そのため、プラクティスが誤って適用されていることをすぐに理解できます。または、選択した問題を解決するのにまったく向いていないことがわかります。
多くの異なる慣行があります。 どれを使用するかは、あなた次第です。 最も重要なことは、それらを使用する理由を忘れないでください。また、練習のために練習を使用しないでください。
PSあなたの実生活で他のタスクにペアテストを使用した場合、コメントでそれらについて教えてください。
カレンダー記事のリスト：
別のアプローチを試してください
合理的なペアテスト
フィードバック：発生方法
テストを最適化する
本を読む
分析テスト
テスターはバグをキャッチし、Canerを読み、移動を整理する必要があります。
ロードサービス
QAサービスメトリック
セキュリティをテストする
顧客を知る
バックログを取る