カバレッジ10%のテスト自動化で7割以上のテスト工数を削減できる！？〜ゆもつよメソッドを使った要求分析〜

こんにちは。食べログでテストのお仕事をしている@shibu_shibuです。
今年も食べログアドベントカレンダー始まりますよ〜
みなさん2021年はどんな年でしたか？
私は新しくQAのお仕事を始めて上手く行ったり失敗したり試行錯誤のチャレンジの年でした。
そしてこのアドベントカレンダーも初参加で1日目担当というチャレンジングなことをしています。
各種レビューが間に合うかのギリギリの戦いをしていますが、この記事が世に出ているということはきっと間に合ったということでしょう。ホッ

1. はじめに

今年の6月から食べログにQAチームが新設されました！
その後チームが統合してDeveloper ProductivityチームのQAユニットとなり、私はそこでテスト設計や自動化のお仕事をしています。
この記事では、QA初心者である私がQA活動に取り組む中で「ゆもつよメソッド」を使用してテスト要求分析を実施したので、そこから学び得たことをご紹介しようと思います。

2. テスト要求分析とは

ありがちなテスト活動

忙しいプロジェクトの現場でテストを実施する場合、実装や要件からテストケースをExcelにバーっと出してそれを実施するというのがありがちなテストの流れです。
食べログもそうなんですが、巨大なシステムは全体を把握するのは容易ではなく、全網羅しようとすると大変な工数がかかってしまうため網羅すべきテストに抜け漏れが発生しやすい状況にあります。
ありがちなテスト活動では「テスト」の中に要求分析、設計、実装がごちゃ混ぜになっており、「何をどうテストしよう？」と考えながら実装しているような状態になりがちです。
このような課題を解決するため、QA活動でも要求分析を実施するようになってきました。

テスト要求分析による品質保証

一般的な開発工程

テスト要求分析の手法は、開発の要求分析手法の Software Systems Architecture から、開発で抑えるべき「観点」を使用した分析の手法を元にしています。
開発工程では、要求分析や設計の段階で、何を実現したいのかそのためにどのように設計するのかといった観点を「ビューポイント」と「パースペクティブ」で明確にしてから実装に入ります。
要求分析の段階でやるべきことが明らかになっているため、実装の段階で「何を実装しよう？」と迷うことはありません。
QA活動の中で、テストケースを作成する前に「観点」を明確にする工程がテスト要求分析です。

湯本剛さんによる「ゆもつよメソッド」とは

「ゆもつよメソッド」はQAの専門家の湯本剛さん考案のテスト要求分析手法です。
ゆもつよメソッドのテスト分析では以下の2つを洗い出します。

• テスト対象フィーチャ(機能)
• テスト条件(仕様項目と期待結果)

ゆもつよメソッドでは、以下の手順に従ってテスト要求分析を実施していきます。

1. テスト対象フィーチャー(機能)を選択
2. テストカテゴリを決めて合意(論理的構造 → テストカテゴリ)
3. 仕様項目と期待結果を特定して整理
4. テストパラメータを特定して整理
5. テスト条件一覧(テスト観点表)をチェック

今回私たちは2の手順に従って「テスト分析マトリクス」=「テスト観点表」を作成しました。

テスト分析マトリクスの作成

テスト分析マトリクスの作成では、論理的構造¹を具体的な観点(テストカテゴリ)にして、その観点に対して過去の障害情報などを元に 意味付け をしたうえで、認識の齟齬がないかをQAと開発者で議論して 合意形成 をします。

テスト分析についての説明資料公開用 from Tsuyoshi Yumoto

テスト分析マトリクスがあるとこんな時嬉しいです。

• 機能に対してどんなテスト条件でテストするのかテストの要件を理解できる
• テストケースより抽象度が高いので、どの機能に対してどんなテスト条件でテストするのかをQA担当者、開発担当者、承認者でコミュニケーションをとったり合意形成しやすい
• 観点表の機能、テスト条件の構成を元にテストスクリプトの構成がしやすい

3. ゆもつよメソッドを使ってみたよ

テスト観点表ができたよ

ゆもつよメソッドを実際に利用して、テスト分析マトリクスを作成しました。
上記の表は、食べログの機能の中のみんな大好きレストラン検索の機能とテスト条件を表したテスト分析マトリクスです。ゆもつよメソッドの「テストカテゴリ」を「テスト観点」と読み替えて我々はこれを「テスト観点表」と呼んでいます。
「テスト分析マトリクス」を参考にして、縦軸に機能、横軸にテスト条件を置き、機能に対するテスト観点に「意味付け」をマークをしていきました。
レストラン検索機能以外の食べログのメイン機能群の観点表も作成し、全体の機能、テスト条件、テスト観点の数は以下のようになりました。

• 機能数：25個
• テスト条件数：67個
• テスト観点数：807個

テスト観点表詳細

• 🔥：障害情報
• 😃：過去のテスト実績
• 10%マーク：全体のテスト観点のうち特に優先度の高いテスト観点10%
• 20%マーク：全体のテスト観点のうち優先度の高いテスト観点20%

障害が発生しやすい箇所と、過去よくテストしている箇所についてマークをしました。
これでどこでよく障害が起きているのか、どこをよくテストしているのかをマークから確認することができます。

実際にゆもつよメソッドやってみてどうだった？

• 開発チームとの合意形成に利用できている
• どこがよくテストされていて、どこで障害が起きているかなどかパッと視覚的に把握できる
• 既存のテストを意味付けとして活かして観点表を作成できた
• 自動化のスクリプト作成で観点表の縦軸と横軸を利用して項目分けできた
• 意味付けした観点を優先順位付けに利用できた
  • 全体のテスト観点の9%をカバーすることで、担当の開発チームで実施しているテスト観点の74%をカバーできる優先度付けをすることができた
  • 上記と同様に全体のテスト観点の9%をカバーすることで、障害発生箇所の90%をカバーできる優先度付けをすることができた

テスト観点に自動化の優先度をつけたよ

「意味付け」を利用したテスト観点の優先度の付け方について少し詳しく説明します。
意味付けをした「テストをよく実施している観点(観点表B)」は、開発者が消費している工数が高いため、自動化することによって生産性を高めることができると考えられます。
また、「障害が起きている観点(観点表C)」は、バグが見つかる確率が他のテスト観点よりも高いと考えられます。
なので、これらのテスト観点を重点的に自動化することによって、より早くより効率的にバグを検知できるようにします。

• いきなり全てのテスト観点を自動化するのは大変なので、まず、優先度上位10%を自動化することにする
• 優先度上位10%では「テストをよく実施している観点」「障害が起きている観点」を網羅できるようにする
• 食べログのテスト観点表では、総テスト観点数800個のうち、上位80個を「テストをよく実施している観点」「障害が起きている観点」から選択し、優先度上位10%とする

これにより、優先度付けをしたテスト観点に対するテスト実施回数カバレッジと障害カバレッジが上記のグラフです。

総テスト観点の9%の80観点の段階で「テストをよく実施している観点」の74%、「障害が起きている観点」の90%をカバーするように優先度を付けました。
つまり、全体の9%のテストを自動化しただけでも開発者のテスト工数を74%削減し、バグの検知率も維持できることが分かりました。

4. 食べログのテスト自動化

※ さも自分が考えたように出しましたが、こちらは我らがリーダーが考案してDPチーム＆開発チームの皆さん全体で目指している最強のテスト活動です。

次のステップでは、今回作成したテスト観点表を利用して優先度上位10%の観点の自動テスト実装をします。
こうしてテスト要求分析から自動テスト実装までの流れを見てみると、今回実施したテスト要求分析は「自動テスト」というソフトウェア開発のための要求分析に他ならないことが分かります。一般的なソフトウェア開発と同じように、どんなソフトウェアを作りたいか、ここでは開発者のテスト工数の削減と、バグの検知率の維持、を明らかにしてから自動テストを設計、実装していきます。
食べログのテスト自動化の設計と実装については、12/11(土)に@hagevvashiの投稿で紹介がありますのでこちらもお楽しみに！

5. まとめ

初心者の私でもテスト要求分析できた
今回初めてテスト要求分析という作業をしましたが、そんなペーペーの私でもテスト観点表の形にすることができました！試行錯誤した面もありますが、機能を出して、観点を出して、意味付けをすることで実際にテストすべき観点をパッと視覚的に理解できるものができました。

全体を俯瞰することで気づけることがある
「テストで要求分析までしなくても..」という気持ちがうっすらあると思います。
実際に作ってみて意味付けをしてみると「こんな機能・条件があったのか」とか「ここでよく障害が起きるのか」「この条件をよくテストしているな」「ここは殆ど改修がないからテストが少ないな」などの発見があり面白いです。
１つ１つは既知の機能や観点も、全体を俯瞰することで足りないものや重要なものが確認しやすくなりました。
テスト設計をする前にさくっとでも要求分析をしてみることをお勧めします

6. 最後に

現在、食べログでは一緒にお仕事をしてくれるSETエンジニアを募集しています。
これからもりもり自動化に取り組んで参りますので、ご応募お待ちしております
正式なご応募以外にも、転職活動前の情報収集やランチを交えた情報交換なども大歓迎です。その場合はご応募いただくときに、フリーテキスト記入欄に「カジュアル面談希望」とご記載ください！

明日は@mamiyanさんで「食べログ スマートフォンページのCSSを最適化してLCP改善にトライ！」です！
お楽しみに

1. 入力調整, 出力調整, 変換, 貯蔵, サポート, 相互作用, AUT外部 の7つのこと。ユーザが入力してから出力するまでの処理を抽象化してMECEに整理したもの ↩