Inspire Quality Services社の取締役かつプリンシパルコンサルタントであるFran O'Hara氏は、先日lessons learnt integrating test into the agile lifecycleを公開した。O'Hara氏の主張の核心は、 従来型のテストをする役割がなくなったとしてもテスト能力というのは必要だということだ。 アジャイルチームが機能テストの自動化だけに注目してしまうと、探索的テストだけでなくシステム結合テストや非機能エリア（たとえばパフォーマンスやユーザビリティ）といったリスク領域の面でも隙間が生じてしまう。
機能横断的なチームを作ることが目的であるとはいっても、それが個別の専門家（たとえばテスターやプログラマーやデザイナー）の集まりだとか、ゼネラリストだけの集まりでもいけない。後者のケースでは、チームは効果的なソフトウェア開発に必要とされるスキルレベルを欠く恐れがある。とくに組織がスクラムを公式文書にするようになるとテスティング能力（テストケースの設計やビジネス要求の明確化やきちんとしたテストの自動化など）というものは忘れられ、その結果チームは開発者だけ（それとスクラムマスターとプロダクトオーナー）で構成されてしまいがちだ。
O'Hara氏によれば、テストの専門能力のあるチームの方がないチームよりも通常はパフォーマンスが高い。このことは、スキルはなおのこと人格的特徴（テスターは細かいところにうるさく注意を向ける傾向にあり、それによってプロダクトを作り込む前に要求に誤解や欠落があることが明らかになる）さえも混成することが必要であることを示しているという。
非アジャイル環境でテストやQAのマネージャーに割り当てられる典型的な能力、たとえばテスト工程とテスト戦略の定義やテスト計画といったものは、アジャイルにおいても同様に必要だろうとO'Hara氏は続ける。多くの組織ではいまだに新機能をいくつかまとめて大きなリリース単位にするので、リリースにはある程度のシステム結合が必要になる。また一方、テストをしながらやっている（たとえばTDDやBDDを活用して）アジャイルチームでさえ、ユーザーストーリーの機能的な側面に集中し、パフォーマンスやユーザビリティなどの非機能要求を無視してしまうことが多い。それでもリリース前にはどこかで実施する必要があるので、かくして調整や計画が必要になるのだ。
O'Hara氏は、いろんなチームと協働しつつテスト能力の差をなくしていく方法をアドバイスして回れるテスト推進派かコンサルタントをアサインすることを勧めている。究極の目的は、機能横断的なチームの中でテスティングを完全に取り入れることである。下記でいうとシナリオCだ。
このレベルまでテスティングを取り入れるためには、多重の業務プラクティスが必要だとO'Hara氏は注意する。受入テスト駆動アプローチにはじまり、スプリントプランニングでテストのタスク（テスト環境の構築やテストツールの導入、探索的テストなど）を盛り込むこと、スプリントの早いうちからテストができるように大きなストーリーを小さなものにブレークダウンすること、一度にしかかるストーリーが少なくなるようWIPを制限すること、テストや検証を後回しにさせないこと（たとえば"検証"列がボードにあるのはマズい予感）、効果的で頻繁なバックログのリファインメント、コードの品質の重要視（コーディング基準、レビュー、TDD、BDD）、そして、厳格な完成の定義を着実に実行すること（圧力のあるときにあってもなお）にいたるまで。
バックログリファインメントの間に（スプリントプランニングでも多少は）ビジネスの観点から要求について議論をすること もまた極めて重要な活動であるが、O'Hara氏によれば、この活動を効果的なものにするためにプロダクトオーナーがざっくりしたフィーチャーだけでなく受入条件のたたき台も持ってくるべきであって、そこでチームがより深い議論をして精緻化し、スコープが明確で小さなストーリーになるのだという。
最後に、レトロスペクティブは完成の定義をよりよくすることに集中するべきで、それによって技術的負債に対処したり十分な内部品質（コード）と外部品質（機能、非機能）を守るのだとO'Hara氏は結んでいる。