リスクベースのテストは、デリバリされるストーリの品質を向上し、システムテスタがスクラムチームの一員になることを支援する — Evosoft Hungary Kftの製品エキスパートであるCsaba Szökőcs氏は、TestCon Moscow 2019でこのように述べて、旧来のリスクベースのテストをスプリントの一部として取り入れ、その完了状態を定義することによって、自分たちのアジャイル実践に適合させた方法について説明した。
Szökőcs氏が最初に示したのは、テスト活動をイテレーションの最終段階から最初に移すために、氏がチームをサポートした方法についてだった。数年前のスクラム転換時、開発者チームは、完全にテストされたユーザーストーリを提供する方法についてまったく知らなかったし、"出荷可能(potentially shippable)"の意味も理解していなかった。当時のチームは、年に1回か2回のリリースを実施していたが、"システムテスト"フェーズ（別名"バグ修正"）に数か月を要していた。現在はスクラムを使用してバグのないストーリのデリバリにトライしており、新たに形成されたスクラムチームでは、より多くのテストアクティビティを導入している。
チームはテスト経験が少なかったため、当初は既知の方法の導入を試みていた — スプリントの最初に小さな設計を作成して実装し、終了後にそれをテストする、という方法だ。Szökőcs氏の説明によれば、これはスプリント内における小さなウォーターフォールモデルであり、一般的なウォーターフォールと同じ欠点を持っていた。
テスト中に大きな問題が発見されると、ほとんどの場合、それを正しく修正するにはすでに遅すぎるため、その結果を受け入れざるを得ませんでした。すなわち、バグを容認して後日修正する、ストーリの範囲を縮小する、あるいは技術的負債のコストを伴う短期的なソリューションを導入する、といった方法です。いずれも望ましいものではありません。
そこでSzökőcs氏は、当時アーキテクチャワークショップで学んだリスクベースのテストが、氏らのスクラムチームに役立つのではないか、と考えたという。それを試みるため、スプリント内でユーザストーリを計画する前に、各ストーリのリスクを収集することにした。これにより、ストーリが実装される前にテストアクティビティについて検討することや、多くの問題を事前に回避することが可能になった。この経験を活かすため、氏らは、極めて早い段階からシステムテスタ担当の同僚を関与させることにした。
リスクベースのテストは、スプリント中のストーリの処理方法を劇的に変更し、デリバリするストーリの品質を改善したが、それだけではなく、システムテスタ役の同僚に大きなモチベーションを持たせることも可能にした。これについて氏は、ストーリの最終的な実現方法に影響を与えることができるようになったからだ、と説明している。これらのシステムテスタの多くは、現在ではスクラムチームの一員となっている。
"一部のスクラムチームではリスクベースのテストを使用していますが、すべてではありません。それにトライして、すでに長く使用しているチームもありますが、そうでないチームもあるのです"、とSzökőcs氏は述べている。それらのチームは、従来のリスクベースのテストをスクラムプロセスに適応させることで、自分たちのアジャイル実践により適合するものにしている、と氏は言う。
Szökőcs氏によると、一般的なリスクベースのテストは、短いテスト期間において最も価値のあるテストを見つけることを目的として、テストチーム内で実施されるものだ。これに対して、氏らのスクラムチームでは、ほぼすべてのユーザーストーリあるいはエピックを対象として、個別に独立したリスクベースのテストを行っている。ストーリのリスクを収集して優先順位を付けることは、その準備完了の定義のひとつである。特定のトピックには数人の専門家（システムテスタ、アーキテクト、製品所有者）が関与して、リファインメントの一部としてリスク収集を行う。システム内にすでに存在するバグを見つけることもあれば、ユーザストーリの変更が必要な場合もある。特別なシナリオで受け入れ基準を拡張したり、極めてトリッキーなシナリオについては分割することもある。
リスクの収集後、2人の同僚がリスクに優先順位を付けて、各リスクの確率とダメージを、1から5までの数字で評価する。２つの数値を乗算することで、リスクエクスポージャ(exposure)が明らかになる。 Szökőcs氏によると、エクスポージャの高いリスクは、すべて、何らかの方法で処理する必要があるものだ。
さらに、経験豊富なテスタが各リスクのテスト有効性を推定し、テストでこのリスクを処理するのはどの程度簡単か、という質問に回答する。これも1から5の範囲で評価する。1が"テスト不可"で、5は"自明"だ。この数値にエクスポージャを乗じたものが、テスト優先度番号（1～125の範囲）になる。数値が大きいほど、影響が大きく、テストが容易なリスクであることを示しているため、優先して対処する価値がある。低い数値は、テストが困難で影響の少ないリスクであることを示している。したがって実質的な価値はなく、無視した方がよい、と、Szökőcs氏は主張する。
優先順位を付けることによって、ハッピーデイシナリオのみをテストするのではなく、最も影響の大きいリスクを対象とした、価値あるテストによるテスト戦略の策定が可能になる。テストするリスクのレベルを特定するために、優先順位を使用することも可能だ、とSzökőcs氏は述べている。
TestCon Moscow 2019での講演を終えたCsaba Szökőcs氏に話を聞いた。
InfoQ: Evosoftでのリスクによる優先度の設定から、どのようなことを学びましたか？
CsabaSzökőcs: まず最初に、優先順位付けは必須ではありません。ただし、それを完全に省略すると場合でも、リスク収集には大きな価値があります。一部のチームはこの方法で作業していますが、十分な成果をあげています。
第二に、優先順位を深く考え過ぎないことです。私たちはいつも、次のような方法でやっています — 最低のリスクを見つけて１を設定し、次に最高のリスクを見つけて、それに５を設定します。他のリスクはすべて、すぐにその間で優先順位を付けることができます。
第三に、テストの優先度は、ストーリにおいて最も価値のあるテストを見つける上で本当に役立ちます。それにより、デリバリするユーザストーリの品質が全体的に向上します。
InfoQ: リスクの収集は、どのように行うのですか？
Szökőcs: 私たちは、"このストーリで何が問題になるのか？"という問いに答えることで、ユーザストーリのコンテキストにおいてリスクを収集しています。
同時に、新しい機能がすでに動作している状況を想像しながら、さまざまなシナリオについて、それがどのように使用されるか、あるいは誤用されるかを考えます。新機能を他の既存機能とを組み合わせることによって、うまくいかなくなる可能性についても検討します。
パフォーマンス、使いやすさ、セキュリティといった非機能要件についても確認します — 影響はあるのか。このストーリによって問題が発生しないか。システムの負荷が高い場合、問題になる可能性があるのは何か。システムに何らかの矛盾が生じた場合はどうなるのか。
（可能性のあるシナリオというだけではなく）価値のあるリスクを見つけるために、私たちはいつも、そのドメインの専門家（他チームのシステムテスタやアーキテクトやプロダクトオーナ）の支援を求めています。チームが何かを実装する前にストーリに影響を与えることができるという面で、これは、彼らにとってもやりがいのある仕事です。
チームの誰かが病気になった時や予算を使い果たした時に何が起こるか、といったような、プロジェクトのリスクを対象にしていない点も重要です。テストケースも収集していません。 ひとつのテストケースだけで複数のリスクをカバーできる場合もあれば、ひとつのリスクのために複数のテストが必要な場合もあります。テストケースはもっと後で、最も重要なリスクから割り出します。
InfoQ: リスクベースのテストを行う上で、ヒントになるのは何ですか？
Szökőcs: まずは試すことです。シンプルに始めて、段階的に改善してください。
最初は、洗練プロセスの一部として各ユーザストーリのリスクをいくつか収集し、それらを単純なリストに文書化するだけで十分です。こうすることで、チームがストーリの問題点を感じ、それらに集中することが可能になります。
その後で、経験豊富な同僚をその会議に招待して、リスクを収集するのです。
それに慣れたならば、次に優先順位付けも試してみてください。チームがよりよい、あるいはより価値のあるテストケースを定義する上で、これが役立っているかどうかを確認しましょう。
リスク収集会議を必須にしたり、長過ぎるものにしないでください。チームはすでに、会議で過負荷になっている可能性があります。さらにそれ以上のものは必要ありません。興味を持っているチームメンバと一緒に実施して、他の人にはすべて省略してしまいましょう。結果は後で確認することができます。
最後に、シンプルさを維持しましょう。最も価値があるのは、リスクに関する議論です。その事を忘れてはなりません。