こんにちは。LINEでさまざまなサービスのQAを担当しているSoogwang Chaeです。私は社外のQAの方々とコミュニケーションするために、さまざまなチャネルを利用しています。今後は、LINE Engineering Blogブログを通じて多くの方と、QAに関するさまざまなテーマについてコミュニケーションをしていきたいと思っています。今回の記事では、QAが「Quality Assurance」から「Quality Assistance」「Quality Advocator」に変化してきた流れを説明します。そして、その変化の流れの中で行った「Shift-left」と「Shift-right」というアプローチによって、いかにより良い品質を確保できるようになったかについてご紹介します。

QA（Quality Assurance）はなぜ品質を保証できないのか

従来のQAでは品質の基準を設け、その基準を満たすプロダクトだけをリリースする方法で品質を保証しました。しかし、時代の流れによってプロダクトをより頻繁に、より高い水準でリリースすることが求められるようになりました。この矛盾した目標を、以前と同じ方法で達成することは困難です。LINEアプリのリリースサイクルは2週間ですが、アクティブ状態のデバイスが数多くあり、約1万8千に及ぶ多種多様なデバイスモデルに対応しています。

このような状況ではテストケースに合格したプロダクトであっても、実際ユーザーが使用する本番環境では基本機能に関するバグが発生することはありますし、ユーザーからのバグ報告やフィードバックへの対応も困難です。以下は、2022年上期のLINE Androidアプリのユーザーからのレビューを分析し、算出した否定的なキーワードの上位6件です。

従来の品質保証では、これ以上対応が難しくなりました。より頻繁なリリースに対して、より高い品質を達成するためには、開発組織がより素早く動くしかありません。そこで、QAもこの開発プロセスの変化に合わせて、より素早く動くためにいろいろと工夫を始めました。このような中で、品質保証の問題はもはやQAだけの問題ではなく、開発チーム全体、ひいてはプロジェクト全体の問題として認識されるようになりました。なお、QAの役割も品質を保証（assurance）することからサポート（assistance）する役割に変化しました。 

'

QA（Quality Assurance）ではなくQA（Quality Assistance）として新たに試みること

QAが品質をサポートする役割に変化すると、開発プロセスにも多くの変化が生じます。ここではその変化のうち、プロセス全体の観点でのアプローチを中心に説明します。

これまでQA（Quality Assurance）が果たしてきた役割について

まず、これまでQA（Quality Assurance）が、どのような役割を果たしてきたかを見てみます。以下は、一般的なソフトウェアの開発プロセスを示した図です。非常にシンプルに表現したもので、現場では必要に応じてより詳細化したり、より複雑な形にすることもあります。

ここで注意すべきことは、QAはテストと同じことだと考えて「QA＝テスト」と定義しがちですが、「テストはQAの１つ」というのが正しい定義だということです。 

この段階でQAでは、基本的にマニュアルテストの他に機能テストと非機能テストを行います。

もしQAの能力の範囲内であれば、探索的（exploratory）テストまたは自動化されたテストも導入することができます。もちろん自動化されたテストがマニュアルテストよりいつも良いとは限りません。能力のあるQAは、プロジェクトとプロダクトの状況に応じて、効率的なテスト方法を提案すべきです。

ここからはQAをより広い意味のQA（Quality Assistance）に拡張するために導入した、「Shift-left」と「Shift-right」の2つのアプローチについて、事例をもとに説明します。

Shift-leftアプローチについて

Shift-leftは文字通り、QAの役割を開発プロセス上で「左に移動」することです。以下は、不具合が発生した段階と、発生した不具合を修正するためのコストを示すグラフです。このグラフから、多くの不具合がコーディング段階で組み込まれ、不具合が見つかるのが遅いほど修正するためのコストが大幅に増加することが分かります。これは、QAを左に移動すべき背景をより明確に示しています。 

Shift-leftの目的は、テストをなるべく早い段階で行い、早めに不具合を見つけ出すことです。不具合を早めに発見するには、単体テストやコンポーネントテスト、APIテスト、パフォーマンステストが効果的で、これを可能にするポイントはテストの自動化です。QAは早めに開発段階に参加しテストを自動化することで、開発過程おいて継続的なテストを可能にします。

Shift-leftによって、QAの活動範囲を以下のとおり左に広げることができました。

Shift-leftアプローチは、単にテスト観点でのアプローチだけを意味しているわけではありません。以下のグラフは、Shift-leftモデルと従来の品質モデルを比較したグラフです。

このグラフで注目すべき点は、Shift-leftモデルでは開発やビルドの領域も重要ですが、それと同様に企画やデザインの領域も重要であることです。そのため、品質の観点でのShift-leftは、以下のとおり開発段階を超えてより左に移動すべきです。

QAの役割を企画段階まで拡大しました。いよいよ、本当のShift-leftについて話ができるようになりました。企画段階までQAの役割を拡張することは、単に企画の仕様を確認することを意味しているわけではありません。ビジネスの観点も踏まえて、プロジェクトの初期から目的と方向性を一緒に検討し、プロダクトの機能や設計を各段階ごとに検証することを意味します。QAは企画段階で重要な意思決定に参加して、プロジェクトとプロダクトに貢献し、開発チームと密接にコラボレーションしながらプロダクトの品質を高める存在として機能すべきです。また、プロジェクトで行われるさまざまな話し合いに、なるべく早めに参加してプロジェクトの各段階でリスクを識別し、事前にリスクを軽減させる必要があります。 

LINEでの導入事例

では、実際にどのように業務に適用できるのでしょうか。LINEでは、まず企画段階でのピアレビューのプロセスを改善し、QAが積極的に参加できるようにしました。この際、QAの役割は単に仕様を確認することに留まりません。重要な意思決定の瞬間に品質の観点から有益な質問をする必要があります。 

AS-IS：企画段階の後に参加するQAの形
TO-BE：プロジェクトの初期から活動するQAの形

開発段階では、テストを一緒にレビューして設計することで予測可能なテストを提供することで、テストの透明性を高めました。これにより、エンジニアはテストが今後どのように進むのかが分かり、コーディングの前に漏れているケースを確認して例外処理する部分により集中できます。QAも開発設計についてきちんと理解でき、テストのカバレッジを実際に引き上げるテストケースを確保できます。以下は、共有モジュールのリファクタリング開発段階でエンジニアと一緒にレビューし、設計を行ったテスト計画の一部です。 

テスト段階では、小規模な単体テストから大規模な統合テストに、順次規模を拡大しながらテストを行います。この小規模の単体テストは、エンジニアが最も行うテストの1つであり、すべての自動化テストの基本となります。LINEでは開発プロセスのルールで、このテストの作成責任者をエンジニアと定めています。QAはこのガイドに従って、エンジニアがより高い品質の認識で単体テストを作成できるように促し、エンジニアが作成したテストを確認します。また、統合テストでは、APIテストやパフォーマンステスト、UI自動化テストなどが含まれる自動化されたテストを利用して、継続的なテストを可能にします。以下は、LINEアプリのKeep機能の統合テストで行った、自動化されたパフォーマンステストの結果を示すダッシュボードです。 

前述のほとんどのテストは自動化されたテストをベースに行いますが、自動化されたテストだけでは数多くの例外ケースを処理できず、さまざまな非機能テストも行うことができません。これを補うための方法として、ヒューリスティック方式を最大活用する探索的テストを行います。探索的テストは、ペアレビューとペアテスト、テストノート、ディブリーフィング（debriefing）などの要素を適切に活用し、不具合を見つけ出すことが目的です。自動化されたテストは良いツールですが、それ自体が目的になってはいけません。場合によっては、自動テストのメンテナンスに多くのリソースを無駄遣いすることもあります。自動化の罠に陥らないよう、常に自動テストを効率的に行う方法について考え、手動テストと自動テストのバランスを取るように努力する必要があります。以下は、LINEで行った実際の探索的テストの例です。 

しかし、このようなさまざまな試みと努力にもかかわらず、より頻繁に、より高い品質のサービスを提供することは、依然として非常に難しいことです。Shift-leftアプローチがいくら優れていても、結局Shift-leftアプローチでは孤立した環境に存在するテストデータを使用するためです。私たちが行うすべての作業は、結局ユーザーのためのものです。したがって、QAはユーザーについてきちんと理解できるリアルなデータを分析する必要があります。そこで試してみたアプローチが、Shift-rightです。

Shift-rightアプローチについて

今度は右の方に拡張してみましょう。Shift-rightは本番環境で行うテストです。 

Shift-leftはテストを早期に行う方法でしたが、Shift-rightはテストを遅いタイミングで行うという意味ではありません。Shift-leftのようにShift-rightもテスト方法だけを意味するわけではないためです。Shift-rightアプローチでは、本番環境でのユーザーからのフィードバックを収集し、そのデータを分析することで、何を改善すべきかを知らせるガイドラインとしてまとめます。本番環境でテストを行うことで、シミュレーション環境とは異なって非機能要素により集中できます。すでに以下のような複数のレポートにより、多くの人が本番環境でのテストに興味を持っていることが分かります。

Shift-leftとShift-rightを比較してみます。 

Shift-left	Shift-right
予防活動に近い	検出活動に近い
各段階ですぐにテストを行う	開発後、ユーザーのフィードバックを受ける形でテストを行う
早期にテストを行うことが目的	中核機能が本番環境で正常に作動するかを確認することが目的

では、本番環境でテストを行うには、どのような技術が必要なのでしょうか。CXテストと分析技術、この2つに簡単に定義できます。これを馴染みのある用語や行動に言い換えると、A/Bテストやカナリア（canary）テスト、段階的リリース、パフォーマンステストなどで表現できます。つまり、実際のユーザーの行動やフィードバックをベースに要件を検証し、それに基づいて機能やパフォーマンステストのシナリオを導き出します。また、変化に対するユーザーの好き嫌いについてもテストを行い、さまざまな環境で発生する不具合を検出していきます（通常、このようなテストは基本的にクラウドテスト（Crowd testまたはCluster test）の形で行います）。 

LINEでの導入事例　

では、実際にどのように業務に適用できるのでしょうか。新しい機能をリリースしたり、データを分析する際には内部テストだけでは十分ではないため、A/Bテストの戦略が必要です。LINEにはすでにさまざまなA/Bテスト戦略が策定されています。QAはこのようなテストに関する十分な知識を持って、プロジェクトに適切なアドバイスができる必要があります。A/Bテストが必要な理由と目的はもちろん、その後に行うべきアクションアイテムまできちんと整理し、与えられたリソースの中で、最大の効果を得るようにアドバイスする必要があります。以下はLINEで提供するA/Bテストのガイドです。 

カナリアリリースは、すでに実装されている機能を特定の対象のみに公開して制御する手法です。代表例として、サービス構成（service configuration）や フィーチャーフラグ（feature flag）、DFM（dog fooding management）などがあり、テストの目的に応じてそれぞれの手法を活用します。以下は、LINEでCanary releasesを活用したときのものです。

このようにQAは、機能および非機能テストの後、本番環境でテスト戦略をどのように立てるかを提案します。例えば、リスク管理の観点でDFMなどの内部テストの実施期間を延ばしてプロダクトの安定性を向上させます。この活動はリリース後に発生する、予期できない課題の感知に役立ちます。また、ユーザーのパターンの分析やCS（customer service）課題の確認、アプリケーションストアのレビューの分析などの活動により、オープンモニタリングをより一層強化することもできます。この活動から収集して分析したデータは、プロジェクトの主要データとして活用され、より高い品質のプロダクトづくりに役立つ土台となります。

ここでソフトウェアの開発プロセスを再度確認してみます。QAがリリース段階とメンテナンス段階に品質活動の領域をより広げるようになりました。

Quality Assistanceを超えてQuality Advocatorへ

以上のようにQAは、開発プロセスのパラダイムの変化によってQuality AssuranceからQuality Assistanceにその役割が変わってきました。なお、今もその役割は拡大を続けており、継続して変化を求められています。前述のようにQA活動はすべてのプロセスに影響を与え、QAの能力によってプロダクトの品質も大きく変わります。QAの役割が拡張して、今のQAは自動化テストのエンジニアやデータサイエンティスト、AI/MLエンジニア、デザイナー、DevOpsエンジニア、SREなど、プロジェクト全体にわたって多種多様な職務の同僚とコラボレーションしています。このようにカバーするプロジェクトが大きくなって複雑になるにつれ、1人のQAの力だけでは品質に関する業務をサポートすることは限界になっています。

これからQA（Quality Assistance）は、QA（Qualilty Advocator）に変化する必要があります。QA担当者は、全社レベルでQAへの関心を高めるための活動を行い、プロダクトに関わる全員が品質に関心を持って自ら責任を取るような文化が作られるように努力すべきです。そのようなQAの役割をQuality Advocatorと呼びます。 

これ以上、1人ではすべてを「QA」できません。1人で品質を向上させるのは不可能です。すべてを1人でやり遂げようとしないでください。それがテストであっても、みんなが一緒に行うべきです。コラボレーションすることで、QAは今より品質を向上させることができます。そのためにQuality Advocatorは、同僚に良い質問を投げつづける必要があります。同僚と一緒に品質を向上させるために、新しいアイデアを提供すべきです。もちろんそれは簡単ではありません。しかし、簡単ではないだけに自分の能力を高められるモチベーションになると思います。

私たちは、このような活動をいつまで続けるべきでしょうか。逆説的に言えば、「同僚がQAなしにも自ら品質への関心を持ち続け、高い認識レベルに至るまで」だと思います。私は、この目標を達成していくことがまさにQuality Advocatorのありかただと思います。