底辺過ぎてちょっとビビる

26歳からIT業界にいるエンジニアが、まったく成長できてないことを確認するブログ。備忘録的に使いたいとも考えています。

リスクベースドテストについて考えてみた

今のQAチームではリスクベースドテストをもとにテスト設計を行っている。具体的に何をもってリスクベースを考慮しているの?という部分だけど、基本的にはプロダクトのリスクのことを指している。プロダクトのリスクって何を言っているのかといえば、例えば

 

  • 新規機能が追加されたことによる「顧客影響」
  • 新規機能が追加されたことによる「機能影響」

 

のことを指している。いずれにしても明確な指針はなく、設計されたテストケースから「新規機能」部分と「新規機能の影響が及ぼす箇所」をピックアップし、ピックアップされた中からさらに「顧客影響に影響のあるもの」「機能影響が大きいもの」をリスク認定して優先度や重要度を設定している。

 

本来、優先度や重要度が高く設定されているテストケースからテスト実施しておくべきなんじゃないか?という気がしているが、テスト実施中はあまりその辺が考慮されておらず、テストケースの上から順にテストを消化している状態だ。

 

「せっかくリスクの設定(重要度や優先度)しているのに意味ないじゃないか」という声が聞こえてきそうだが、全くご指摘の通りで今後は優先度、重要度を優先的に進めるべきではないか?という話をチーム内で議論したいと考えている。

 

「リスクベースドテスト」で検索してヒットしたこちらの記事では、

リスクベーステストの実践的アプローチ - UIテスト自動化ツール Ranorex

 

たとえば、2つの要件をテストするとします。
要件Aは、顧客がWebページを介して支払いをおこなえるように支払い機能を構築することであり、要件Bは、Webページ全体のフォントサイズを14から16サイズに変更することです。
要件Aが正しく実装されていない場合、顧客からの支払いが一切おこなわれない可能性があるため、ビジネスや顧客に対して大きな影響を与えます。その結果、莫大な金銭的損失や、顧客の満足度の低下を招く恐れがあります。また、要件Bが期待通りに動作しなかった場合、問題ではありますが、顧客やビジネスには金銭的な影響はなく、お客様に気づかれないこともあります。

上記の要件をテストするための作業工数が3日間ある場合、大半の時間を要件Aのテストに割り当て、残りの時間(もしあれば)を要件Bのテストに割り当てる方が理にかなっています。このようにして、リスクと影響に基づいてテスト作業に優先順位を付けます。

 

顧客に影響のある支払い機能を追加する要件と顧客影響の少ないフォントサイズを変更する要件では実施する「工数」についても考慮すべきである、と書かれています。その通りだと思う。今のQAチームでは重要度と優先度の設定レベル分けが2段階くらいになっているので、もうちょっと細かいレベル分けが必要と思う。具体的には、

 

  • 重要機能確認:High
  • 機能確認:Middle
  • レイアウトなどの機能外確認:Low

 

というような感じで。とはいうもののついできるところから始めちゃうんですよね...

せっかくテスト管理ツールを導入してテストをしているのだし、かなりリッチなツールなので、リッチな機能を装備しているはずなので、うまく使いこなしたい。