これまでのQAについて

最初に、私たちのQAチームの役割や、開発ライフサイクルの中でのQAの位置付けなどがこれまでどう認識されていたかについて触れておきます。

QAチームの立ち位置、役割

私たちの開発現場では、スクラムを用いて開発を行っています。

その中で、QAチームは独立したチームとして、プロダクト開発を行うスクラムチームとは別に存在しています。3人という少数精鋭部隊で複数のスクラムチームのQAを分担したりして、1つのチームのみで完結しない、チーム横断的な品質の関心事（例えばリグレッション、性能、脆弱性など）に注意を払ったりしています。

これにより、開発者が気づけないリグレッション観点や、少し専門性の高い脆弱性観点などを第三者視点で確認できるというメリットがありますが、一方でプロダクト開発チームが品質周りのプロセスの一部をQAチームに依存する傾向があります。

翻訳サービスのQAって難しそう

「機械翻訳サービスのQAって何するんですか？（難しそう...）」という質問をいただくことがあるので触れておくと、翻訳結果の質（翻訳精度など）についてはQAチームではスコープにしていません。

私たちプラットフォーム開発部で担当しているのは翻訳サービスのアプリケーション部分の開発で、翻訳処理を行う部分（いわゆる翻訳エンジン）についてはエンジニアリング部というお隣の部署で開発しているため、翻訳精度などはそちらで検証しています。

QAフェーズ

QAチームの作業の中心は、実装・テストが終わった後に「QAフェーズ」と呼ばれて行われるものになります。

QAフェーズとは何をするものなのか、用語に対する疑問はありますが*1、これまでの私たちの開発においては、これまでに実施したテストケースや結果から漏れている観点が無いか確認したり、先程挙げたリグレッション、性能、脆弱性観点のブラックボックステストを実施したりといった作業を行っていました。

もちろん、そのQAフェーズで対象とする開発規模によってやること・やらないことを選別したり、テストケースや観点の確認はできるだけ早いタイミングで確認したりといった工夫もしています。

とはいえ、QAフェーズ中に何か問題が見つかれば当然、設計・実装に戻って問題を修正するということになるので、自然とこの工程やそれを担うQAチームが「最後の門番」的な存在として認知され、バグがないことや観点の抜け漏れがないこと等が重要視されることになります。

しかし、これはかなりウォーターフォール的な開発プロセスであり、私たちのやりたいアジャイル開発の進め方とはどうも合わないのでは、ということは感じていました。

アジャイル開発におけるQAとは

では、アジャイル開発を行う現場では、どのようにQAを考えればよいのでしょうか？

従来型QAとアジャイルQA

以前、QAチームの改善のコンサルティングでお世話になったアジャイルコーチの藤原大さん (@daipresents) が、JaSST Tokyo 2022 で従来型QAからアジャイルQAへの進化方法というセッションをしていました。

speakerdeck.com

この中で、「従来型・アジャイル型の「QA組織・役割」の比較」としてそれぞれ特徴がまとめられています。

従来型のQAの役割
- 「完成品のテスト」「QAフェーズですべてを終わらせる」
アジャイル型のQAの役割
- 「小さな未完成品のテスト」「くり返し改善を続ける」「効率性重視」

（P.13 ”従来型・アジャイル型の「QA組織・役割」の比較” より抜粋）

私たちの現場では、開発者自身も単体テストや機能テスト*2 を開発中に行うため、QAフェーズにすべてを託しているわけではありません。

また、QAフェーズとして行うE2Eのリグレッションテストを自動化するなどして効率化を図っています。

一方で、「開発が終わったらQAしてもらう」という開発の「最後の門番」的なイメージを持っている人も多いので、まだアジャイル型にはなりきれておらず、従来型に近い考え方が残っているように感じます。

このスライドの中では、先のアジャイル型のQAになるために必要なことついてこう書かれています。

短いサイクルの中で開発サイクル全体に対してQA活動を行う
速さに見合った品質を提供する（スピードと品質を両立する）
テストを通じたフィードバックサイクルを構築する

(P.18 「従来型」→「アジャイル型」への進化例より抜粋）

本格的にアジャイル型となるためには、チームメンバー全員がこれらを理解し実現することが求められるということです。

QA is 何

と、ここまで話して今更ですが、QAって何のことを指しているのでしょうか。「テスト（的な何か）をすること」であり、「テスト（やテスト的な何かの確認）をする人」と思われていることが多いようです。

QA＝「テスト（的な何か）をすること」を指している場合は、定義やスコープが曖昧で、ブラックボックスなものと理解されています。

時折「QAお願いします」という会話がされるのを見かけますが、この背景にはQAで何をするのかがあまり理解されておらず、QA＝「テスト（的な何かの確認）をする人」の領域だという意識が強いからではないかと思っています。

先程のスライドにはこのようなページもあります。

あなたは1週間の短いスプリントで開発を行っているチームの一員です。

テストを担当するQAエンジニアはいません。

さて、あなたはどのようにプロダクトの品質を守りますか？

（P.17 マインドセットの変化を体験してみよう）

藤原さんは、従来型QAの経験がベースとなっている現場でアジャイル型QAを考えるきっかけづくりとしてこの質問をされるとブログでも言及されています。

アジャイル型のQAを目指すということは、これに対して自分たちなりの解を模索し続けることなのでしょう。

アジャイル品質パターン QA to AQ

アジャイル開発での品質保証に関するパターン集として、QA to AQ (Quality Assuarance to Agile Quality) というものがあるので、アジャイル型QAを考える際の参考としてこちらも紹介しておきます。

codezine.jp

QA to AQは、アジャイル品質の考え方と推奨される実証された活動のエッセンスを、問題と解決をペアにしたパターンのカタログとしてまとめたもので、QA to AQの名称には、「昔ながらの品質保証の考え方から脱却し、アジャイル開発に適合する形でよりアジャイルな方法で品質保証を進めよう」といったメッセージが込められています。

（アジャイル品質のための中核パターン：「アジャイル品質プロセス」と「障壁の解体」より抜粋・編集）

QA to AQ は 23のパターンを4つの分類に分けて整理してまとめられています。

この中で中核パターンとなる「アジャイル品質プロセス」と「障壁の解体」には、以下のような問いが書かれています。

問：システム品質の検査（作業）やQA担当者をアジャイルプロセスのどこに、どのように組み込めばよいのか？

これに対する最も重要な考え方は、「QA担当者をチームに組み入れてOneチームとしてあたり、品質の考え方をアジャイルマインドセットに統合すること」だそうです。というか、ほとんどのアジャイルプラクティスにおける重要な原則が「Oneチーム」というコンセプトなので、QAに関しても例外ではないということです。

品質に感度の高いQA担当者がスクラムチームに入り、バックログやプランニングに品質観点がきちんと加わっているかを確認したり、品質妥当性を確認するためのテストやモニタリングをする方法を開発してチームに浸透させていく活動をしていくことがアジャイルプロセスの中での品質の扱い方、QA活動ということです。