QAスタイルについて - imtndのブログ

最近、QAのスタイルについて思うことがあったので少し書いてみようかなと思います。

QAと言っても、この記事で書いているのはテストエンジニアというニュアンスの方が近いかもしれません。

アジャイル開発におけるQAの関わり

最近の各社のQAの取り組みを見ていると、QAは開発のチームの中に入って入り込む形をとっているケースがよく聞かれます。

アジャイル品質のパターン集であるQA2AQでも以下のように紹介されています。

したがって、アジャイル品質チームでは、最初からQA担当者をアジャイルチームの一部として含めることが重要です。

　最初からアジャイルチームの一部として含まれている場合には、QA担当者は、アジャイルチームの全員が要件を理解して検証することを支援できます。QA担当者は完成（Done）の定義付けも支援できるようになり、考慮すべき品質属性とそれらにいつ対処すべきかをプロダクトオーナーが理解できるように手助けすることが可能になります。

codezine.jp

ただ、ここで注意が必要なのはQAがチームに入るのは、テスト実施をすることではなく、アジャイルチームをサポートすることが目的になっています。

JSTQBのアジャイルテスト担当者シラバスにはもう少し具体的なことが記載されています。

アジャイルチームにおけるテスト担当者の役割は、テストステータス、テスト進捗およびプロダクト品質だけでなく、プロセス品質に関してもフィードバックを生成し、提供する活動を含む。このシラバスの別の場所で説明している活動に加えて、以下を含む。
・テスト戦略を理解、実施および最新化する
・適用可能なすべてのカバレッジの観点について、横断的にテストカバレッジを測定し報告する
・テストツールを適切に使用していることを確実にする
・テスト環境とテストデータを構成、使用およびマネジメントする
・欠陥を報告し、チームと共に欠陥を解消する
・テストの視点から他のチームメンバをコーチする
・リリース計画時およびイテレーション計画時に適切なテストタスクをスケジュールしていることを確実にする
・開発者およびビジネスステークホルダと積極的に協調して、要件を、特に試験性、整合性および完全性に関して明確にする
・チームのふりかえりに積極的に参加し、改善を提案および実施する
アジャイルチーム内では、各チームメンバはプロダクト品質に責任を持ち、テスト関連のタスクを実行する役割を果たす。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation-AgileExt_Version2014.J01.pdf

このシラバスに記載されている内容もテストを実施するというよりは、他のメンバをサポートをしたり改善するニュアンスが記載されています。

伝統的な品質保証

一方で、今までのいわゆる伝統的な品質保証というのはどういう形で行われていたかというと、QA組織は開発組織とは独立した形態を取れらていることが多く、最後に妥当性検証を行っているのではないかと思います。

これはV&VやIV&Vという考え方をベースとして組織を形成していることが多いからではないかなぁと思います。

IV&V（Independent Verification and Validation）は、「ソフトウェアの独立検証と妥当性確認」と訳されます。IV&V とは、開発プロジェクトから独立した組織が、独立した検証技術、及びソフトウェア開発組織の影響を受けない資金によって、ソフトウェアの課題や問題を洗い出し、潜在するリスクを軽減する活動です。

(略)

ソフトウェア開発組織自らが行う V&V では、開発活動と V&V 活動との間で、人的リソースや資金的リソースの奪い合いが起こり易く、その結果、十分な V&V 活動の実施が妨げられる可能性があるためです。上表の 3 つの独立性のうち、組織的独立と資金的独立は、この利益相反による問題を防ぐために、特に重要な要素です。

https://sma.jaxa.jp/Software/IVV/files/JAXA-CAA-2018018.pdf

JSTQB　FLのシラバスにもテストの独立性のメリットというのが記載されています。

独立したテスト
テストタスクは、テストに特化した役割を持つ人たち、または別の役割を持つ人たち（例えば、顧客）が行う場合がある。ある程度の独立性を確立すると、開発者とテスト担当者の間の認知バイアスの違い（1.5 節を参照）によって、テスト担当者はより効果的に欠陥を発見できる。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf

つまり、独立した組織で行われるテストというのは、バイアスがかからなかったり、色々な側面から独立するメリットがあるというわけです。

目指すべきQAスタイル

開発チームに入り込むスタイル、独立した組織とするスタイルの両方を紹介しましたが、それぞれ別のメリットやデメリットが存在します。

結局の所、

QAとしてのスペシャリティを活かして、開発チームを品質面でサポート、改善したいのであれば開発チームに入るやり方もあると思いますし、

社外への不具合流出を減らしたいのであれば、独立したQA組織というのもあったほうが良いのかなと思います。

どちらを採用するのか、または、両方を採用するのかは各組織の状況や、プロダクトの特性によって違うと思うので、各プロジェクトに応じて考えた方が良いかなと思います。

昨今の流行のQAのスタイルでは、独立したQA組織という形態を取るのは遅れている的なことを聞くことがあったので、そこは本当にそうなのかなぁと思ってこの記事を書きました。

独立した組織でQAをやっている人も遅れているとは思わずに、自分の所属の組織は何を求められているのかを、再度考えてみると色々なものが見えてくることもあるような気がしています。