【QAチーム ブログリレー3日目】
エンジニアリンググループ QAチームの末吉です。前回の記事ではいつか英雄ポロネーズを弾いてみたい...なんて書いていたようですが、なんと私の今の課題曲が英雄ポロネーズです。２年前の私がびっくりするでしょうね。
導入
リファクタリングはソフトウェアの健康を保つために不可欠な取り組みです。しかし、その品質を保証するリファクタリングQAは、目に見えない内部構造の変化を相手にするため、QAエンジニアは広範囲な影響とリグレッションの恐怖に直面し、その難しさを痛感する場面も少なくないはずです。
本記事では、ある製品のリファクタリングQAを進める中で私たちが直面した課題と、それを乗り越えるために実践したチーム（PdM、CS、Eng）との連携についてQAエンジニアの視点からご紹介します。開発側視点でのリファクタリングについての記事はマルチデバイスチームの渡辺さんが既に記事にしてくれています。www.m3tech.blog
m3.com 電子書籍アプリについて
画像はiOSのもので、Androidもリニューアル予定
m3.com 電子書籍アプリは医師・薬剤師・医学生向けの電子書籍アプリです。Webで購入した電子書籍コンテンツ（以下コンテンツで表現を統一します）をダウンロードし、オフラインで閲覧や書籍を横断した内容の検索、メモ・テキストの書き込みなどができます。
リファクタリングQAの一般的な大変さ
リファクタリングQAに取り組むQAエンジニアであれば、以下のような「大変さ」に一度は直面したことがあるのではないでしょうか。
- 影響範囲の特定が困難
- リグレッション（=デグレード）との戦い
- テストケースの陳腐化と再構築の必要性
私たちの製品におけるリファクタリングの壁
前述のような一般的なリファクタリングQAの困難さに加え、この製品では、さらに特有の課題に直面していました。
この電子書籍アプリはただ電子書籍を閲覧するだけでなく、コンテンツごとに様々な付加価値（例えば、コンテンツ間の詳細なリンク機能、専門的なデータベースとの連携コード、あるいは動画など）を提供しています。
「一般化」の罠
既存の動作のリファクタリングがコンテンツによって差分を生んでしまう可能性がある、という事象に当たりました。共通処理の改善を目指したリファクタリングが、あるコンテンツでは改善でも、別のコンテンツでは意図しない挙動を引き起こす「あちらを立てればこちらが立たぬ」状況に陥りやすいのでした。
全数テストという「幻想」
提供しているコンテンツは多岐にわたり、網羅的なテストを実施することは、時間的にもコスト的にも現実的ではありませんでした。 これらの課題を前に、「全てのコンテンツをチェックすることは不可能」という現実に直面し、私たちは個々の力だけでなく、チーム全体でこの問題に立ち向かう必要性を痛感しました。
連携こそが鍵
直面した製品特有の壁。「全てのコンテンツをチェックすることは不可能」という現実。私たちは、この困難な状況を打破するために、個々の努力だけでなく、PdM、CS、開発エンジニア（Eng）それぞれとの連携を強化し、より戦略的なアプローチを取ることを決意しました。
【PdMとの連携】：ビジネスインパクトに基づいたテスト戦略の策定
- 課題：
- 全コンテンツを網羅的にテストするのは不可能。
- 連携アクション：
- PdMから販売実績やコンテンツ特性（例：隔年発行の重要コンテンツ）のデータを共有してもらう。
- 得られた効果：
- 闇雲なテストから脱却し、ビジネス価値の高い機能にリソースを集中できた。
- 課題：
【CSとの連携】：ユーザーインパクトの最小化と迅速な問題解決体制の構築
- 課題：
- カナリアリリース中、ユーザーからの問い合わせは避けられない。
- 連携アクション：
- CSチームへ、リファクタリング概要と段階的なリリース計画を事前に共有。
- QAからCSへ、懸念箇所や実際に発生したバグから想定される問い合わせ内容と、その対応方針を連携した。
- 得られた効果：
- CSは問い合わせにスムーズに対応でき、ユーザーの不安を軽減できた。
- CSからのフィードバックを素早くテストや開発に反映するループができた。
- 課題：
【他エンジニアチーム（iOS）との連携】
ここはQA主体でなく、QA交えて開発エンジニア間で積極的にコミュニケーションをとっていました。iOSは先行してリファクタリングが完了しているため、先行事例を基にプラットフォーム間の仕様共通化が加速していきました。
段階的リリース戦略
カナリアリリースは、一部のユーザーにのみ新バージョンを先行して提供し、問題がないかを慎重に検証する手法です。今回は私たちの抱える以下の課題に対して有効だと判断しました。
- 全数テストは不可能（ソフトウェアテスト原則): 全コンテンツ・全機能の事前検証が難しい状況でも、リスクを限定的にすることができます。
- 影響範囲のコントロール: 万が一問題が発生しても、影響を受けるユーザーを最小限に抑え、迅速な対応やロールバックが可能になります。
- 実環境での早期フィードバック: テスト環境では見つけにくい、実際のユーザー利用状況下でのみ顕在化する問題を発見できる可能性があります。
今回は、製品の特性とリファクタリングの規模を鑑みてカナリアリリースを選択しましたが、私たちのチームでは、より細かく影響をコントロールしたい場合や、新機能の評価、UI改善のABテストなどを行いたい場合には、フィーチャーフラグ（例えばFirebaseの機能にあるRemote Configなど）を用いた段階的リリースを活用しています。状況に応じて適切なリリース戦略を選択し、PDCAサイクルを回していくことも、品質を継続的に高めていく上で非常に重要だと考えています。
まとめ
このAndroidアプリのリファクタリングは道半ばです。今回の取り組みを通して、QAを進める上で直面する困難な課題こそ、チーム全体で共有し向き合うことが重要だと改めて感じました。
We are hiring!
エムスリーでは、m3.com 電子書籍アプリをはじめ様々なアプリを開発しています。もし興味がありましたらお気軽にお問い合わせください！
