Tabelog Tech Blog

食べログの開発者による技術ブログです

リスクベースドテストのアプローチを使って重篤なバグを早期に検出しホットフィックスを防いだ話

はじめに

こんにちは。
飲食店向けモバイルオーダーシステム「食べログオーダー」でQAチームの職域リーダーをしている池田です。
食べログオーダーとは「お客様が自分のスマートフォンを使ってメニューを注文できる」サービスです。

今回は食べログオーダーのテストアプローチとして取り入れて成功したリスクベースドテストについてお話しします。

目次

プロジェクトの課題

私が今回担当したプロジェクトは「食べログオーダーに外部POSのメニューを連携する」という内容でした。
外部POSとは、販売管理や決済処理を行うシステムです。
以降この案件を「外部POS連携」と呼びます。
外部POS連携は過去に類似プロジェクトがあり、2つの問題がありました。

問題1.バグがプロジェクトの最後の日まで発生し続けた
以下は類似プロジェクトのバグ検出推移です。

画像5-2-6

赤枠を見ると、消化テストケース410件から470件までの間でバグが7件検出されており、プロジェクトの終盤までバグが発生し続けたことがわかります。
この原因は、赤枠より前のテストケース実施の段階で、着手しやすい項目から実施しており、プロジェクトの最後にバグを発見する可能性が高いテストが残っていたためです。

問題2.バグが市場流出し、不具合が発生した
POSと食べログオーダーの仕様差分による不具合がありましたが、テストでは検出されませんでした。
本番環境にリリースされてしまったため、店舗で不利益が生じる前に、緊急で修正を行いました。
外部POS連携では、こうした問題が起きないようにする必要がありました。

リスクベースドテストの導入

外部POS連携では、「リスクベースドテスト」を導入しました。
優先順位を設定してテストを行うことで、類似プロジェクトで発生したような問題を防ぐことができると考えたからです。

リスクベースドテストについて

ISTQBテスト技術者資格制度Foundation Levelシラバス日本語版Version2023 には、

「リスク分析とリスクコントロールに基づいてテスト活動を選択し、優先順位を付け、マネジメントしていくテストアプローチをリスクベースドテストという」

と記載されています。
この定義は少しわかりづらいですが、一番重要な部分は「優先順位を付け」の部分だと考えています。
リスクベースドテストは、ソフトウェアの品質向上を目的にリスクレベルに基づいてテストの優先順位を設定する手法です。
外部POS連携では、テスト観点をリスクカテゴリに分類し、リスクレベルを設定することで、効果的にテストを実施しました。

テスト観点のリスクカテゴリ化

外部POS連携におけるテスト観点を抽象化し、リスクカテゴリを作成します。

画像1-3

例えば、テスト観点に記載されている以下のような観点があったとします。

  • メニュー名空欄
  • 構成数不一致

これら2つの観点を抽象化することでメニューの不備というリスクカテゴリを作成できます。

バグのリスクカテゴリ化

過去案件のバグチケットをトリガーごとに分類し、こちらもリスクカテゴリとして追加します。  

画像2-3

例えば、過去のバグチケットに、以下の事象があったとします。
POS連携後、POS上でメニューを削除した後に再連携すると連携失敗する
POS連携後、食べログオーダー上でメニューを編集して再連携すると連携失敗する
これらの2つの事象は、再連携時に失敗すると言えるので、共通のトリガーである再連携というリスクカテゴリを作成できます。

リスクレベルの定義

次に、リスク評価のために必要な因子を特定し、リスクレベルを作成します。
テストにおけるリスク評価の因子として計測可能な要素と感覚的な要素の両方が揃っていることが重要だと考えました。
計測可能な要素として「過去不具合の有無」を利用し、客観的なリスク評価を実施し、感覚的な要素として「不具合がありそうか、なさそうか」を利用し、主観的なリスク評価を実施します。
この2つの因子の組み合わせを四象限で表現してレベル1~レベル4の四段階のリスクレベルを作成します。

画像3-4

縦軸は「不具合がありそう、なさそう」、横軸は「過去不具合があった、過去不具合がなかった」という軸を置いています。
レベル1〜レベル4の四段階で、レベル4が一番リスクレベルが高いエリアになります。
レベル4を例として赤枠をご確認いただくと、縦軸は「過去不具合があった」に該当し、横軸は「不具合がありそう」に該当します。

リスク評価

上記の四段階のリスクレベルに、リスクカテゴリをマッピングしていきます。
付箋でレベル1~レベル4 の四段階のリスクレベルにリスクカテゴリを分類します。

画像4-2

リスクカテゴリを分類し終えた四段階のリスク分析マトリクスです。
赤枠をご確認いただくと、先程例として登場した再連携メニュー不備があります。
再連携は「過去不具合があった」且つ「不具合がありそう」に該当する為、リスクレベル4、メニュー不備は「過去不具合がなかった」且つ「不具合がありそう」に該当する為、リスクレベル3になりました。

リスクベースドテストの実施における工夫

バグチケットのトリアージ

外部POS連携ではリスクベースドテストを効果的にするため、バグチケットのトリアージも行いました。
バグチケットのトリアージとは、報告されたバグチケットの修正における、優先順位を決定することです。
外部POS連携では、テスト実施期間中は実装担当者、開発リーダー、PM、QA、デザイナーが集まって、バグチケット一覧を確認して優先的に修正すべき内容や修正漏れがないかを確認しました。

リスクベースドテストの特性上リスクレベルが高いテストを優先して実施するため、テスト実施序盤でリスクの高いバグが多く発見されやすくなります。
発見されたバグ全てが優先である状態となり、修正の着手順が分かりにくくなることがあります。
このため、バグチケットの修正における優先順位を決める点で、バグチケットのトリアージは非常に効果的です。
具体的には、トリアージを通じて各バグチケットの影響度や緊急度を評価し、修正の優先順位を明確にすることで、重要なバグチケットを迅速に解決できるようになります。

外部POS連携では、優先度が高いにもかかわらず、トリアージ前は後回しにされていたバグチケットが存在していました。
しかし、バグチケットのトリアージを行ったことで、優先順位が誤っていたチケットを見直し、適切な順序で対応できました。

結果と成果

外部POS連携では、リスクレベルの高いリスクカテゴリに属するテストケースから順番に実施しました。
その結果、検出されたバグは事前に評価したリスクレベルに一致しており、プロジェクトの終盤に実施したテストケースでは新たなバグが発生しませんでした。

(1)終盤のテストではバグが出ていない

画像6-2-7
プロジェクト前半の消化テストケース0件から50件まででは、5件のバグを見つけています。
一方で、プロジェクト後半の消化テストケース347件から431件では80件以上のテストケースを実行しているにもかかわらず2件しかバグが見つかっていません。
これらのことから、外部POS連携ではプロジェクトの前半で効率的にバグを検出し、終盤のテストではバグの検出が落ち着いていたことがわかります。

(2)重篤なバグを効率的に検出し、市場流出を防いだ

画像7-6
上の図は外部POS連携における累積バグ検出数の推移と各フェーズで見つかったバグがどのリスクカテゴリに紐付くかまとめたものです。

この四象限は、リスク評価で使用した四段階のリスク分析マトリクスと同一のものです。
バグ検出の推移は、リスクレベルに基づき、3つのフェーズに分かれています。

フェーズ毎に検出されるバグの傾向が分かれていました。

  • フェーズ①: リスクレベル4に分類されるバグが多く検出
  • フェーズ②: リスクレベル3に分類されるバグが多く検出
  • フェーズ③: リスクレベル2以下に分類されるバグ、リスクレベル4に分類されるバグが多く検出

私たちは、リスクレベルが高いリスクカテゴリに属するテストケースを優先的に実施しました。
グラフ上で累積バグ検出数が急激に増加している箇所を見ると、フェーズ①(テスト序盤)においてリスクレベル4に分類されるバグが集中して検出されていることがわかります。

具体的には、横軸が示すテスト消化件数の増加に伴い、縦軸の累積バグ検出数が急増している部分がフェーズ①に該当します。
このことから、リスクレベルの高いテストケースを優先的に実施した結果、序盤で多くの重要なバグを検出できたことを確認できました。
フェーズ③でリスクレベル4のバグが検出されました。
メニュー階層はフェーズ1で実施すべきでしたが、POS連携プロジェクトでは詳細な挙動について検討が必要だった為、後ろ倒しにしていました。
今後、リスクレベルが高いものに関しては、序盤で実施できるようにします。

QAチームが貢献できたことの考察

  • 序盤のテストでリスクレベルの高いリスクカテゴリを重点的にテストすることで、緊急修正が必要な障害の発生を未然に防ぎました。
  • バグの早期検出により、テスト終盤での修正を最小限に抑え、修正が間に合わずリリースが延期になることを防ぎ計画通りのリリースに貢献しました。

まとめ

リスクベースドテストのアプローチを採用することで、バグが発生する可能性が高い機能や、市場への影響が大きい機能におけるバグを早期に検知できました。
食べログオーダーでは、今後もこのアプローチを積極的に取り入れ品質向上に努めていきます。

最後に、食べログでは一緒に働く仲間たちを募集しています!
食べログで働いてみたいと感じてくださった方は、以下の採用情報のリンクから是非応募してみてください!!!

参考文献

1.ISTQB joint Foundation Level & Agile Working Groups.(2023)ISTQBテスト技術者資格制度Foundation Levelシラバス日本語版Version2023 https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf(PDF)