ごあいさつ
こんにちは。エンジニアリング統括部の吉次です。 今回は、主に新規サービス系の領域で活動をしているQAエンジニアチームの取り組みの一つであるテスト俯瞰マップについて紹介いたします。
QAエンジニアチームと新規サービスの品質の歴史
QAエンジニアチームは、エンジニアリング統括部サービス共通基盤グループに属しており、 PERSOL MIRAIZ、HiPRO Direct、HR Forecaster、サラリーズなど、主にここ数年で生まれた新規サービスに対して横断的に品質可視化・向上の推進を担っています。
QAエンジニアチームが生まれた背景やこれまでのあゆみについては過去の記事をご覧ください。 techtekt.persol-career.co.jp
現在は、プロダクト・チームへの品質への取り組みのサポートを通して QAエンジニアチームの中でナレッジが蓄積され始めました。
それらをソリューションとして保持し、品質コンサル活動と銘打って 継続的に開発現場のエンジニアと協力しながら、プロダクトやチームの品質課題の解決に取り組んでいます。
今回の記事では、QAエンジニアチームで生み出したソリューションの1つであるテスト俯瞰マップについて取り上げます。 品質コンサル活動については別の機会にご紹介できればと思います。
テスト俯瞰マップとは？
テスト俯瞰マップは、どのような品質をどういったテストで担保しているかを可視化するためのツールです。 縦軸にテストタイプ・品質特性（どのような品質）、横軸にテストレベル（どういったテスト）をとるマトリクスになっています。 大まかなイメージとしてはこんな感じの表です。
| ユニットテスト | インテグレーションテスト | システムテスト | 受け入れテスト | |
|---|---|---|---|---|
| 機能テスト | ⭕ | ⭕ | ❌ | ❌ |
| 非機能テスト | ❌ | ⭕ | ❌ | ❌ |
| 構造テスト | ⭕ | ❌ | ❌ | ❌ |
| 変更に伴うテスト | ❌ | ❌ | ⭕ | ⭕ |
各テストタイプについてカバーしているテストレベルの列に⭕を入れていくと、 品質担保において手薄になってしまっている部分が可視化されます。 そうして見えてきた課題を深掘りしていくことで、プロセス・体制・ルール・手順などを改善するための施策立案につなげることができます。
テスト俯瞰マップを活用イメージと読み解き方
実際のテスト俯瞰マップは、上に示したイメージよりも各項目が細かく分類されています。 また、テストタイプ・品質特性によっては開発フェーズの中というよりも普段の運用・モニタリングの範疇でカバーされるものがあると考えたため、テストレベルに「運用フェーズ」の列を追加してあります。
主なテストタイプの項目を抜粋したものがこちらです。
今回は実際のテスト俯瞰マップを埋めていくのは大変なので、1つ前のセクションで示した大まかなマップを使っていくつかのパターンについて読み解き方を見ていこうと思います。
入力値の凡例は以下の通りとします。
| 記号 | 意味 |
|---|---|
| ⭕ | 十分できている |
| 🔺 | 一部できているが十分ではない |
| ❌ | できていない |
| 空欄 | 対象外・不要 |
縦軸のテストタイプは実際は細かい項目に分かれているため、 いかに示すマップの例は全体的に概ねOKといえる状態であれば⭕という感じで読んでみてください。
パターン1: 全体的にバランスよく品質が担保されている
| ユニットテスト | インテグレーションテスト | システムテスト | 受け入れテスト | モニタリング | |
|---|---|---|---|---|---|
| 機能テスト | ⭕ | 🔺 | ⭕ | ⭕ | |
| 非機能テスト | ⭕ | ❌ | ⭕ | ||
| 構造テスト | ⭕ | ⭕ | |||
| 変更に伴うテスト | ⭕ | ⭕ |
すべてのテストタイプについて、何かしらのテストレベルで十分な品質が担保されています。 各テストタイプについて、必要に応じて複数のテストレベルでのテストが実施できていると安心感があります。
完璧ではないかもしれませんが、現実的にはほとんど文句なしと言えると思います。
課題整理の例
- 十分でないテストレベルが存在する
改善施策の例
- 機能テストにおいて、Web APIのE2Eテスト（インテグレーションテスト）が一部しかできていないので、網羅的に適用していく
- 受け入れテストにおいて、非機能要件を意識した確認ができてないため、受け入れテスト実施の際に応答速度やユーザビリティのような非機能要件の観点を加える
パターン2: テストレベルが偏っている
| ユニットテスト | インテグレーションテスト | システムテスト | 受け入れテスト | モニタリング | |
|---|---|---|---|---|---|
| 機能テスト | ⭕ | ❌ | |||
| 非機能テスト | ⭕ | ❌ | |||
| 構造テスト | ⭕ | ||||
| 変更に伴うテスト | ⭕ | ❌ |
テストの手法がユニットテストに偏っています。 もちろん、これで全体の品質が高いことが担保できているのであれば問題はありません。 各テストレベルは、「このテストタイプにしか適用できない」という制限はありませんが、向き不向きはありますので、その点には注意が必要です。
課題整理の例
- テスト実施がユニットテストに偏っていて、プロダクト全体としての品質の担保できているか疑わしい
改善施策の例
- 必要な機能が揃っていて仕様通りに動くことを受け入れテストで担保できるようにする
- ユーザビリティやエンドツーエンドでのパフォーマンスなどユニットテストでカバーしきれていない部分は、システムテストや受け入れテストで担保できるようにする
- 修正時のデグレを検知するために、テストシナリオを作成してリグレッションテストを実施する
パターン3: 特定のテストタイプが考慮されていない
| ユニットテスト | インテグレーションテスト | システムテスト | 受け入れテスト | モニタリング | |
|---|---|---|---|---|---|
| 機能テスト | ⭕ | 🔺 | ⭕ | ⭕ | |
| 非機能テスト | ❌ | ❌ | ❌ | ❌ | ❌ |
| 構造テスト | ⭕ | ⭕ | |||
| 変更に伴うテスト | ⭕ | ⭕ |
全体的に悪くないですが非機能要件について考慮されておらず、品質が担保されていない状態です。
セキュリティ要件についてはセキュリティベンダによる脆弱性診断が会社のルールとして義務化されていることもよくあるので、全く考慮されていないということは少ないかもしれません。 一方で、パフォーマンスやユーザビリティ、またはセキュアコーディングが普段の開発から実践できているかどうかなどは、実際にプロダクト開発に関わる人たちで決めないといけない部分です。
特に開発初期においては、どんな機能をどう作るか考えることにほとんどのリソースが割かれ、非機能要件の定義が漏れてしまい、リリース後に問題が顕在化することがよくあります。
課題整理の例
- 非機能要件について考慮されていない
改善施策の例
- 最低限の非機能要件を定義し、テスト方法を確立する
- 主要な機能のレイテンシや可用性、Core Web Vitalsなどの目標指標を定めて、定期的にモニタリングを実施する
- ユーザビリティの要件を定め、システムテストや受け入れテスト実施時の観点に含める
テスト俯瞰マップ活用におけるポイント
テスト俯瞰マップはシンプルな考え方ながら、テスト実施状況の可視化にはとても役に立つツールです。 活用におけるポイントとして、以下のようなものが挙げられます。
全部⭕で埋めることをゴールにしない
テスト俯瞰マップを全部⭕で埋まっている状態は、少なくとも品質の観点では悪い状態ではないはずですが、 何よりも重要なのはプロダクトの価値に繋がっているか否かです。
プロダクトにとって必要がない or 重要でないテストを時間と労力をかけてやる必要はありません。 その分、ユーザに取って重要な機能を開発したり改善したりすることに時間を使いましょう。
「どこまでやるか」問題は品質に限らずしばしば出てきます。 チーム内で必要十分な品質目標を定め、それに沿う形でテストを充足させていきましょう。
プロダクトやチームに合わせて解釈する
テスト俯瞰マップを使うときに出てくる「品質特性」「テストレベル」「テストタイプ」などのキーワードは一般的な定義に基づいており、幾分抽象的なところがあります。 それらのキーワードを抽象度の高いまま扱うと、実際にプロダクトに適用して考える際にもやりにくさを感じることがあります。
その「テスト俯瞰マップで言うところのシステムテストって、このチームだとこれだよね」といったような形で 自分たちのチームやプロダクトに合わせて解釈して理解を揃えるようにしましょう。
メンバー間で解釈がバラバラなままだと、良い改善施策が出づらくなる可能性が高いです。
チーム外の情報を活用する
テスト俯瞰マップで課題を可視化した際には、一度立ち止まって他のチームや社外の情報を調べたり、 QAエンジニアに参画してもらい意見を聞いたりするとスムーズに改善施策の立案につながることがあります。
世の中の開発チームやプロダクトは、大抵似たような問題を抱えています。 また、その似たような問題を誰かが解決してくれていることが多くあります。
うまくチーム外の情報を活用することによって、抽出した課題に対して成功しやすいアプローチを取りやすくなります。
まとめ
テスト俯瞰マップは「なんかバグがよく起きるよね」、「ちょっとレスポンス遅いよね」といったような漠然とした品質への課題意識を 具体的かつ体系的に可視化してくれる有効なツールです。 パーソルキャリアのQAエンジニアチームではこれまでに複数の開発チーム・プロダクトに活用してきましたが、非常にうまく機能していると感じます。
一方で、可視化は改善のための最初のステップに過ぎないということに注意する必要があります。可視化の先には課題抽出と改善のサイクルが待っています。 可視化したことに満足せず、プロダクトが生み出す価値の最大化を目指していきましょう！
吉次 洋毅 Hiroki Yoshitsugu
エンジニアリング統括部 クライアントサービス開発部 HRサービスエンジニアリング第1グループ シニアエンジニア
2014年に高専専攻科を修了後、飲食店検索サービスを提供するWeb企業に入社。PHPをメインにバックエンドの領域の開発やプロジェクトマネジメントに従事。2016年にインテリジェンス（現パーソルキャリア）に入社。doda AIジョブサーチの開発などを経て、現在はSalariesの開発やQAエンジニア組織の立ち上げや運営などを担当している。
※2024年2月現在の情報です。
