この記事は Akatsuki Games Advent Calendar 2024 6日目の記事です。
昨日は NaoyaKohda さんの 自宅の消費電力を可視化してみた でした。 モジュールを使えば個人でもスマートメーターから値を引っ張ってこれるんですね。
はじめに
アカツキゲームスQAエンジニアの山﨑 @tomo_tk11 です。ゲーム開発のプロジェクトで QA 効率化をミッションに掲げ活動しています。最近リスクベースドテストを実践してみたんですが、このテスト戦略の使い所やメリットが少しだけ分かった気がしたので書き留めておこうと思います。
目次
リスクベースドテストとは
JSTQB AL のテストマネージャシラバスには次のように書かれています。
リスクベースドテストでは、プロダクト品質リスクを使用してテスト条件を選択し、それらの条件に合わせてテスト工数を割り当て、作成されたテストケースを優先度付けする。リスクベースドテストには、収集するドキュメントにおける重要性の種類と度合いによるバリエーション、および適用する公式度合いによってさまざまな技法が存在する。また、リスクベースドテストには、明示的または暗黙的に、テストにより品質リスクのレベル全体を引き下げる、特にリスクレベルを受け入れ可能なレベルにまで引き下げるという目的がある。
ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04 | p.24
リスクベースドテスト、JSTQB シラバスを読んだときは言葉として理解はできるものの、なんだかとても重厚な戦略だなと感じていました。リスクを扱うテストなので仕方がない面もあるのかなと思います。とは言っても重たい…。使い方が想像できない…。
また、リスクベースドテスト戦略は4つのプロセスで成り立っています。
リスクベースドテストは、次の 4 つの主な活動で構成される。
• リスク識別
• リスクアセスメント
• リスク軽減
• リスクマネジメント
ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04 | p.24
特に、リスクベースドテストでどのようなテストを実施すべきかは、リスクマネジメントを除く3つのプロセスで検討されると思います。し、識別…？アセスメント…？難しそうです。
そして、リスクベースドテスト戦略の中で取られるテスト手法には公式で重い技法として、ハザード分析、エクスポージャーコスト、故障モード影響解析、フォールトツリー解析*1が例に挙げられています。シラバスのリスクベースドテストのページに書かれていることを実直にやろうとするととても大変そうです。
リスクベースドテストの使い所
テスト戦略は多いほうがいい
プロジェクトチームで話をしていたときに、「この機能、次のバージョンに入れたいんだけど、テストに時間がかかるらしくて難しいらしい。なんとかならないか？」という意見を聞きました。所属しているプロジェクトでは、テスト分析、設計を経て、比較的ローレベルなテストケースを実装し、テスト実行する、というテストプロセスです。通常、機能追加を行う際はそのバージョン開発開始時点で計画されます。リリースまでのマイルストーンに間に合うように開発するため、テスト工数の問題は発生しません。ただ、「この機能入れたいんだよね〜。」の要望は計画外のところからやってくるのが常です。機能入れたいんだよね、を提案する方のモチベーションはユーザのためであることがほとんどです。この機能を入れることでプロダクトがもっと良くなる、ここでユーザに提供できないと機会損失が生まれてしまう、だから入れたいんだ！という思いなはずです。その意思を尊重したい気持ちはありますが、いかんせんテストプロセスが重たく、「テスト工数が足りません…。」と返答せざるを得ません。この状態はなんとか解決したいです。
ここで注目すべきは、チームとして持ち合わせているテスト戦略が1つしかない、という点です。なのでテスト工数が少ない戦略を増やすことで解決できそうです。
過不足ないテストを実現するテスト戦略
ここでリスクベースドテストの話に戻ってくるのですが、リスクベースドテストの本質は「やらないテストを決められること」にあると思っています。本来テストというものはリスクを回避、軽減、認知するための手段である、という考え方をしています(個人意見)。リスクベースドテストを知ったときも、リスクを基にテストを考えるのって普通じゃ？くらいに思っていました。多分それは間違いで、リスクに対して他のテストよりも向き合っているのがリスクベースドテストなのかなと感じています。時間が無限にある中では洗い出されたリスクに対して対策を講じれば良いと思いますが、時間が限られているのが普通です。切羽詰まっているときだってあります。
そのときに効果を発揮するのがリスクベースドテストです。洗い出されたリスクの中で優先度を設定し、限られた時間の中で対策したいリスクだけを選択する。選択したリスクに対してテストスコープを決め、そのリスクを軽減するための過不足ないテストを計画する。そうすることで、普段のテストプロセスよりも少ない時間で品質を保証することが可能です。
つまり、リスクベースドテスト戦略の使い所は「限られたテストコストの中で機能を追加した上で品質を保証し、なんとしてでもプロダクトをリリースしたいとき」です。
リスクベースドテストの使い方
早さを求められるのに、重厚である
冒頭で、リスクベースドテストは重厚である、という話をしました。リスクについて考えるのでどうしても時間をかけて行うことを想像してしまいます。実直にやろうとすると時間がかかるのです。一方で使い所は、限られたテストコストの中で機能追加してなんとしてでもリリースしたいとき、とも言いました。この矛盾を解決しなければ、使い所は分かっても使えません。
軽量化する
軽量な技法は、より公式な技法と同様に可能性および影響の要因に対する重み付けを使用して（たとえば、テストの精緻さの度合いなどに応じて）、ビジネスリスクまたはテクニカルリスクを強調できる。ただし、より公式な技法とは異なり、軽量な技法には次の特徴がある。
• 可能性と影響の 2 つの要因のみを使用する。
• シンプルで定性的な判定と尺度を使用する。
これらのアプローチは、軽量という特性により、柔軟性と広い範囲のドメインへの適用性、あらゆる経験とスキルを持つチーム（非技術要員および若手要員を含む）へのアクセシビリティを持つ。
ISTQBテスト技術者資格制度 Advanced Level シラバス 日本語版 テストマネージャ Version2012.J04 | p.28
JSTQB では公式で重い技法の対比で軽量な技法が紹介されています。重いならば軽くしましょう。リスク識別(洗い出し)、リスク判定(優先度付け)、リスク軽減(過不足ないテスト計画)、このプロセスにかかる時間をどれだけ早くできるか、がリスクベースドテストを実務に活かすポイントだと思います。
軽量なリスクベースドテストの良い所
やらないテストを決めることができる
これは既に上で話しましたね。リスク判定を行うことで過不足ないテストを計画することができます。それにより、不可能だったリリースが可能になります。
やらないテストの理由を関係者とともに考えることができる
「この機能入れたいんだよね〜。」という話とセットで言われるのが、「この機能を入れることによるリスクある？」です。リスクまで洗い出された状態で機能追加の提案を受けることは少ないんじゃないかなと思っています。その提案を受けるタイミングはたいてい切羽詰まっている状況なはずだからです。しかしながら、テストを計画する立場としてはリスクは考えなければいけません。Hotfix であれば不具合修正したコードの影響範囲を確認する必要があります。この作業を QA だけで行うのは大変です。リスクベースドテストを用いることでエンジニアなどの関係者と話し合いのもとリスクを洗い出し、優先度までつけることができます。助かりますね。
やらないテストの理由をステークホルダーに説明できる
関係者と話し合って決めた「やらないテスト」なので、そこにはきっとロジカルな理由が存在します。それを使ってリリース判断するプロダクトオーナーやプロジェクトリーダーに説明することで、やらないことへの正当性が生まれます。つまり、「やらない」ということをチーム全体で合意できたことになります。リスクベースドテストはやらないテストを決めて合意形成するまでの一連のプロセスを含んでいます。これにより、コミュニケーションコストがぐっと下がると思います。
軽量なリスクベースドテストの悩ましい所
使い所が限定される
影響範囲の少ない Hotfix 程度であればリスクの洗い出し、優先度付けまでスピーディーに進めることができます。実際私が行ったときは2時間くらいでテスト計画まで終えることができました。しかし、大きな機能に対してや複数の機能に対してリスクベースドテストを適用しようとすると途端に重たくなるはずです。
私のプロジェクトチームでは使い所は「限られたテストコストの中で機能追加してなんとしてでもリリースしたいとき」に限っています。なので、追加される機能も自然と小さなものに限られるはずです。その場合は軽量化された戦略でスピーディーに意思決定すれば良さそうです。
逆に、大きな機能であれば検討する時間の余裕があるはずなので、リスクに向き合う時間も確保できると思います。より重い技法を使うこともできるはずです。
そもそもちゃんとしたリスクベースドテストなの？
公式に軽量化したリスクベースドテストというよりは、概念を理解したうえで実務に活かすにはどうすればいいか？から考えたので、オリジナルな要素が強い戦略になってしまいました。ただ、理論は実践するのが大切だと考えているので、理想を掲げるだけではなく今のプロジェクトに即した形にチューニングして実戦投入したことは今のところ後悔していません。価値を出すことが何よりも大事です。
まとめ
リスクベースドテストは重厚なテスト戦略ですが、軽量化することで「限られたテストコストの中で機能を追加した上で品質を保証し、なんとしてでもプロダクトをリリースしたいとき」に効果的に活用できます。
軽量化されたリスクベースドテストのメリットは以下の通りです：
- やらないテストを決めることができる
- やらないテストの理由を関係者とともに考えることができる
- やらないテストの理由をステークホルダーに説明できる
ただし、大規模な機能や複数機能への適用は難しく、使用シーンは限定的です。理論を実践に落とし込む際は、プロジェクトの状況に合わせて柔軟にチューニングすることが重要です。
また、今回リスクベースドテストを実践するにあたりJSTQB シラバスの他に、ソフトウェアテストのセオリーという書籍も大変参考になりました。テストプロセスに関連する情報を網羅的に紹介していくれているのでかなりオススメです。
