【QA チーム ブログリレー1日目】
こんにちは。エンジニアリンググループ QA （Quality Assurance） チームの津向です。 健康診断前は気を付けていましたが、すっかり生活習慣が戻ってしまいました。
さよなら、ワカメ、納豆、フィットボクシング。
こんにちは、ラーメン、餃子、ピザ、ポテト。
私が所属するUnit4（医療系ポータルサイトm3.comの開発・運営を担当するチーム）では、「全員QA」の考え方のもと、エンジニアも品質保証に積極的に関わる取り組みを進めています。
エムスリーにおけるQAは、単に不具合を見つけるだけでなく、リリースするサービスの品質を総合的に保証するチームです。開発された機能が要件を満たしているか、使いやすさに問題はないか、安定して動作するかなど、様々な視点から検証しています。具体的には新機能が正しく動くか確認する機能テスト、システム全体の連携を確認するシステムテスト、リリース前の最終確認である回帰テストなど、多岐にわたるテストを実施しています。
今までエンジニアの方が全くテストをしていなかった、ということは決してなく、品質保証という共通の目標に向かって、エンジニアとQAがそれぞれの専門性を持ち寄り、協力し合う体制を構築しています。
特にシステムテストの確認フェーズではEngQAとして積極的に協力いただいています。
EngQA実施例
EngQAとして確認完了していただいている一例としては次のようなものがあります。
- 簡易なテキスト修正
- 誤字脱字など、機能への影響が軽微で、目視で確認できるもの。
- 1パターンの疎通確認で確認完了できるもの
- 特定のAPIエンドポイントが正しく応答するかなど、テストパターンが少なく、影響範囲が限定的なもの。
- CIなどフロント影響のない修正
- サーバーサイドのロジック変更やビルドプロセスの改善など、ユーザーインタフェースに直接的な影響がないもの。
- QA環境用の設定修正
- 本番環境に影響しない、開発・テスト環境固有の設定変更。
- 一部のライブラリバージョンアップ
- セキュリティアップデートやパフォーマンス改善など、既存機能への影響が少ない、もしくは自動テストでカバーできるもの。
上記以外にも、エンジニアの方から「これEngQAで大丈夫じゃない?」と判断されたものは、QA チームが確認したうえでEngQA で確認完了にしていただいています。 ただし、QA側で通常のQA確認が必要と判断した場合は、従来通りQA側での確認を実施しています。
EngQAのメリット・デメリット
EngQAのメリット
- 修正からリリースまでの時間が短縮できる
- QAリソースを規模や影響の大きい改修へ集中できる。また、テスト自動化、改善活動に割くことができる
EngQAのデメリット
- エンジニアの作業負荷が増える
- EngQAの判断基準が人によって異なる可能性がある
デメリットについては、テスト自動化（特にmablの活用）の促進と、後述するSlackワークフローによって、判断基準の明確化とエンジニアの作業負荷軽減が図られ、改善されています。
mabl:非エンジニアでもローコードで自動テストが作成できるツール。活用事例は以下の記事でも紹介しています。
mablを一年運用してみた成果と課題 - エムスリーテックブログ
EngQA確認依頼を効率よく行う
変更内容に関わらず、エンジニアからEngQAで対応可能かどうかの確認は必須としています。これは、QA側で把握していない変更がリリースされることを防ぎ、製品の品質に対してQAが責任を担うためです。
また、フロントエンド部分への影響がある場合は、EngQAであってもmabl自動テストによる確認を必須にしており、主要な機能の一通りの動作を担保しています。 現在はGitLab上からmabl自動テスト実行がワンボタンで可能になり、エンジニアは手間なく実行でき、QAは修正内容とテスト結果を効率的に確認できるようになりました。
日々、 テキスト修正やCI修正など、様々な改修が頻繁に行われています。 そのため、EngQA判断の確認を効率よく行うためSlackのワークフローを利用しています。
Slackのワークフローを利用する理由
- フロント影響の有無や変更の種類など項目を設けることで、情報不足や内容のばらつきを防ぎ、ポイントを把握しやすくする。
- 確認する場所を1つのチャンネルに集約することで、不明点の質問などナレッジとして蓄積する。
- ボタン操作1つでOK回答できるようにすることで、手間を最小限に抑える。
まとめ
EngQAの導入により、現在では月80件ほどの軽微な修正をエンジニアに確認してもらうことで、QAリソースを規模や影響の大きい改修や改善活動に集中させることが可能になりました。また、mabl自動テストの活用とSlackワークフローによる効率化により、EngQAのデメリットであった「エンジニアの作業負荷増加」や「判断基準の曖昧さ」も改善されています。実際にEngQAを実施したエンジニアからも、『ロールアウト速度が早まった』『EngQAに出すハードルが下がった』といった好意的な意見をいただいています。
また、ロールアウト速度と引き換えに不具合増加や品質低下はしておらず、全員QA作戦展開後もエムスリーとして健全な品質が維持されています。
さらなるQA業務の発展に向けて、今後はより複雑なテストシナリオの自動化や、開発初期段階からの品質向上への関与など、自動化・効率化を長期的な課題として取り組み、開発プロセス全体の高速化に貢献していきます。
We're hiring
そんなわけで自動化や効率化が大好きな方、AIが大好きな方、なぜか不具合に好かれる方など様々なQAエンジニアを募集しています。一緒にQA活動しましょう！
