QA リーダーとペアリング
- パターン：QA リーダーとペアリング（原題Pair with a Quality Advocate , 原著 Joseph W. Yoder, Rebecca Wirfs-Brock, Hironori Washizaki）[3]
「団結は力である。チームワークとコラボレーションがあれば、素晴らしいことを達成できる。」――Mattie Stepanek
品質とは、システムを構築してテストするだけではありません。システムの製造の準備が整う前に取りかからなければならないシステム品質やその他の考慮事項は数多くあります。重要なシステム品質に余裕をもって早期に焦点を合わせていないと、重大な問題、遅延、手戻りが発生する可能性があります。パフォーマンスやスケーラビリティの欠陥を改善するには、システムのアーキテクチャの大幅な変更や修正が必要になる場合があります。
プロダクトオーナーは、チームの作業に優先順位を付ける責任がありますが、システムのテスト方法や、システム品質のテストが、開発者が書いているユニットテストとどのように異なるかを認識していないかもしれません。これは、品質に関連したタスクを無視したり、品質関連のタスクがプロダクト全体の品質達成へ貢献することについて誤解したりすることにつながります。
アジャイル開発者は、システム機能を実行および検証するためのユニットテストの作成に精通しています。ユニットテストは重要ではありますが、システム品質にはユニットテスト以上に重要なものがあります。重要なシステム品質特性を理解してテストしようとすると、優れた機能テストを行うことが難しいときがあるかもしれません。
特にシステム品質特性を理解してテストすることになると、アジャイルチームはどのようにしてシステムに品質を組み込むことができるでしょうか？
＊＊＊
アジャイル開発者は、ユーザーストーリーの要件に基づいて開発するのは得意ですが、システム品質特性のテストに関してそれほど経験はありません。一方でQA担当者はシステム品質特性を理解しており、それを検証する方法に関して多くの専門知識を持っています。
非機能要件に焦点を合わせると、プロダクトオーナーが説明した重要な機能要件から注意がそらされることがあります。プロダクトオーナー、開発者、およびエンドユーザーは実装された機能を見たいと思っています。それを見ると進捗していると感じるからです。しかしながら、非機能要件について対処されていない間は、システムは実稼働環境にリリースする準備ができているとは言えません。
システムの開発者は、機能要件を実装し、作成したテストで検証します。多くの場合、機能はシステムの品質に影響を与えます。開発者は、QA担当者によってテストと検証が行われるまで、システム品質の制限や要件に気づかないことがあります。QA担当者と開発チームとの間に良好なコミュニケーションがない場合、品質に関する懸念事項に早期に対処することが困難になることがあります。
QA担当者は、すべての詳細を説明するのに十分なバックグラウンドを持たずに、製品の構築や設計の方法を開発者に伝えようとしていると見られることがあります。開発者の中には、QA担当者はプロダクションコードを書いていないし書けないのですべての問題を理解することができないからと、QA担当者からのコメントを無視する人もいます。開発者はせっかちになり、より多くの詳細を求めるようになります。開発者は何が本当なのか分からないまま、プロダクトはおそらくこう動くべきなのだろうと推察しながら詳細仕様を自分で考えて実装してしまうので、結果として、テスト可能性が損なわれる可能性があります。
＊＊＊
そこで、開発者と他のアジャイルチームメンバーをペアにしてQAを行い、品質関連のタスクを完了させ、QAの知識と品質の視点を広めましょう。
QAは、ソフトウェアをテストして検証するだけではありません。チームが認識していればシステムの成功に役立つ重要な品質に関する考慮事項があります。すべてのプロセスを通してQA担当者とチームがペアリングすることで、チームは重要な品質特性を理解し、どのように検証し、それについて考えるかを理解することができます。重要なシステム品質特性が最も適切なタイミングで対処されるように、責任モーメントを計画[GWY]することが重要です。
QA担当者は、プロダクトオーナーやプロジェクトマネージャーとペアを組んで、ソフトウェアがどのように機能することが期待されているか、どのような種類のテストが行われているかを伝えることで、QAプロダクトチャンピオンになることができます。「私は、テストについて詳しく知りたい、製品について詳しく知りたい、少なくともテストチームのやるべきことについて詳しく知りたいと思っているプロジェクトマネージャー（PM）と複数回にわたってちょっとだけペアを組んだことがあります。私がPMと一緒にテストすると、PMはテストに必要な時間をより明確に理解し、コミュニケーションが改善され、必要な時間を予測しやすくなりました [Joh]」
プログラミング作業の間、QA担当者は開発者とペアを組むことができます。QA担当者は開発者と一緒に座っていると、システム品質特性のテストに焦点を当てたユニットテストの設計のみならず、より優れたユニットテストの設計も支援することができます。QA担当者とペアを組んでいる開発者は、結合テストを共同で作成することもできます。
開発者とテスターのペアリングはアジャイルコミュニティにとって新しいものではありません[Joh、Koh、Mon]。ペアリングは、最初のスプリント計画から始まり、開発を通して継続し、さらには本番でも、さまざまな方法で実現できます。洞察に富んだ経験レポートと書籍は、QA担当者が強力なリーダーとなり開発サイクル全体を通して他のチームメンバーと協力できるさまざまな方法を強調しています[Bro、GC、Hil]。QAリーダーとペアリングは、アジャイルチーム全体に品質作業を分散させることにより、QAを含むOneチームの考え方をサポートします。
QAリーダーとペアリングにより得られる相乗効果には、双方にとって利点があります。テスターは通常、ユーザーの観点からテストに焦点を合わせます。テスターは開発者とペアを組むと、ソフトウェアが舞台裏でどのように機能するかをより深く理解することができます。これは、QA担当者がより多くのテストが必要になる可能性のある領域を特定し、欠陥をより適切に特定することに役立ちます。開発者は、どのような条件が潜在的な失敗につながるかだけでなく、QA担当者からテストの境界条件、優れたインターフェイス、入力の検証についても多くのことを学びます。ペアリングのやり方は固定である必要はありません。Joseph W. Yoder[Joh]は次のように述べています。「開発者はテストについて学んだことを自分の開発プロジェクトに適用すると、自分たちで独自の優れたテストシナリオを思いつくようになった。何よりも良かったことは、ペアテスト後に開発者のコードの欠陥を見つけることが難しくなったことだ」
ある組織は、テスト作業の重複を大幅に減らすことができたと述べています[Sav]。「重複率は50％であることがわかった。SDET[注3]が作成した自動テストの50％は、開発者の一連のユニットテストにも含まれていた。ユニットテスト、ハッピーパステスト（正常系テスト）、およびいくつかのネガティブテスト（異常系テスト）で構成されていたが、これらのテストは既に問題なく動いていたので、別のチームが作成して再度実行する必要はなかった。これは無駄なことであった。それは新しい方法で取り戻すことのできる時間とリソースの無駄であった」。
QA担当者とDBAのペアリングは、特にデータスキーマやデータアクセスの問題を特定する場合に役に立ちます。QA担当者は多くの場合、DBAよりもソフトウェアがどのように機能するべきかについてより深く理解しています。両者はお互いの懸念事項をよりよく理解し、システムのテストと検証を改善するためのアイデアを得ることができます。
アーキテクトはQA担当者とペアリングすることで、テストアーキテクチャ戦略[GWY]を定義したり、特定のテスト結果が特定のシステム品質に及ぼす影響を評価したりすることができます。テストにより特定のシステム品質属性が着陸ゾーン[YW]の最小値を下回ったことが示された場合、QA担当者はアーキテクトと協力して問題に対処します。QA担当者はアーキテクトおよび開発チームとペアリングして、現在のソフトウェアのベンチマークを実行したり、実稼働システムの測定が不可能な場合には、特定のパフォーマンスやスケーラビリティ属性の予測値を推定したりすることがよくあります。
ペアリングは常に成功するわけではなく、注意すべきリスクがいくつかあります。Janet Gregory[Koh]は次のように述べています。「どちらか一方が一方通行の学習体験であるという考えで参加した場合、その体験は失敗に終わるだろう」。ペアリングは、互いへの尊敬の念と信頼があって初めて効果を生み出します。ペアの間で理解している内容にギャップがある場合、ペアリング中に「ドライブ」している側の人は、相手が積極的に参加し、何が起こっているかを理解していることを確認しながら進める必要があります。目標は、相互に尊敬と信頼を築き、協力して作業することです。たとえば、開発者はQA担当者を開発者にしたり、その逆をしようとしたりするのではなく、互いの強みに基づいて尊敬と信頼を築く必要があります。たとえば、QA担当者は開発者とペアを組み、具体的な詳細を品質シナリオに追加したり、それらに最適なテスト戦略を決定したりすることができます。または、QA担当者は開発者と協力して、ユーザーストーリーの品質の折り込みの意味を理解し、それらが満たされていることをテストする最善の方法を理解することができます。
注3 SDET
Software Development Engineer in Test。開発やテストの時に、テスト容易性やパフォーマンスなどの専門知識を持って支援してくれるITのスペシャリスト。
