ごあいさつ
こんにちは！ユニファアドベンドカレンダーをご覧頂きありがとうございます！ ユニファQAチームの斉藤です。 このブログは、UniFaアドベントカレンダー 20日目となります。
今年はコロナで大変な１年でしたね。ユニファQAチームも今年の早い時期からフルリモートに切り替えて活動を行ってきました。もともとリモート勤務可能ではありましたが、案件が去年の２倍以上に増えたり、メンバーの入れ替わりがあったりしたので、フルリモート体制で乗り切るには大変な１年だったなぁと感じています。
そんな中ですが、新しい取り組みにもチャレンジしてみました。リスクベースドテストです。 今回はそこから学んだことをふりかえってみたいと思います。
新しい取り組み 「リスクベーステストを始めよう！」
冒頭のごあいさつさらっと記載しましたが、今年はテスト案件が去年に比べて大幅に増えました。
去年までは当時のQAチームメンバーでもなんとか回せる量だったのですが、今年の春頃から数か月規模の案件が並行で走り、秋頃からさらに増えて、現在は多くの案件が並行して動いています。案件が増えることは計画内だったので、今年の春頃から「案件が増えた時にそなえて、テストを考えねば」という話題はチーム内であがっていました。
そこで当時のQAチームリーダーから提案されたのが、リスクベースドテストでした。
リスクベーステストって？
では、リスクベースドテストとは何でしょうか。
JSTQB用語集で引くと、以下のような記述が出てきます。
リスクベースドテスト（risk-based testing）： プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。
プロダクトリスクというものを識別し…テストプロセスをガイドする…なるほどわからん。
私の理解をざっくりいうと、要はプロダクトリスク（そのプロダクトで起きてほしくない事象）の重大度と発生率を整理して定義し、それに基づいてテストする機能やしない機能を選んでいく、というテスト戦略です。
プロダクトリスクのリスクタイプやリスクレベルも、以下のようにリーダーの方で定義して頂いたので「それに基づいてテストする機能やしない機能を選んでいくのだよ」の具体的な方法を、いよいよQAチームメンバーで考えていくことになりました。
ユニファQAチームで取り組んだやり方
ユニファQAチームは、メンバーによってテスト設計から実装までのやり方が少し異なります。このリスクベースドテストを導入しようとしている時は、複数プロダクトにそれぞれメンバーが分かれてアサインされていました。 いつもだと、それぞれのプロダクトに合わせてメンバーがテスト設計をしますが、このリスクベースドテストを導入するなら、複数プロダクト統一したやり方じゃないとレビューがしにくいな～と考えました。
そこで複数プロダクト間である程度、統一できるやり方として、テスト観点を抽象化したリスク設定要素、基本リスクレベル、補正リスクレベルという項目を使ってみようと考えました。
リスク設定要素
リスク設定要素とはいわゆるテスト観点です。
ユニファQAチームで行うリスクベースドテストでは、このテスト観点をできるだけ抽象化したものをリスク設定要素と名付け、これに重みづけすることで「テストする機能やしない機能を選ぶ」ことをやってみようと考えました。
このリスク設定要素（テスト観点）は、ユニファQAチームメンバーの認識をそろえるため、全員参加でマインドマップを使ってブレストして決定しました。
基本リスクレベル
次に基本リスクレベルです。
基本リスクレベルとは、リスク設定要素の基本的な重みづけです。
リスク設定要素とリスクタイプでマトリクスを作り、QAチーム全員で話し合いながら1～5点の間で点数をふっていきました。（5点がリスクとして一番重い点数です）
全てのリスク設定要素に基本リスクレベルとして点数を設定したら、次にそれを、プロダクトリスクレベルへマッピングを行いました。
リスク設定要素のもつ下限値～上限値を均等にリスクレベルへわりつけ、該当するリスク設定要素をマッピングして、QAチームで眺めてみました。
結果、リスクレベルとリスク設定要素の組合せに違和感はないね！ということで、基本リスクレベルの設定が完了できました。
補正リスクレベル
基本リスクレベルの設定が完了しました。この後のフローとしては、機能・画面ごとにリスク設定要素をあてはめて、QA保証対象以上のリスク設定要素のみに対しテスト設計をしていく、という形にいったん整いました。
ただ機能・画面によっては、リスク設定要素（基本リスクレベル）通りにあてはめてしまうと、具合が悪いというものもあります。 たとえば、リスク設定要素の「バリデーション」や「画面UI」は、QA保証対象外ですが、機能・画面のビジネス的な重要度によっては、QA保証対象とした方がよいこともあります。
これを補うために、補正リスクレベルを使うことにしました。
補正リスクレベルとは「基本リスクレベルを見ると、QA対象もしくは対象外だけど、担当QA判断によってレベルを調整してよい」というものです。
レビュー時にレビューアに対して「ここは重要もしくは重要でないと判断したから、確認してくれ」というアピールとしても使えると考えました。
リスクベースドテストやってみた結果
やってみた結果は以下です。
①工数はあまり削減できなかった
②短期間のテスト実行で、重要度の高いバグが検出できた
①については、もともとリスクベースドテストは「工数削減」が目的ではなく、「少ないリソースで品質を担保するためにテストするしないをプロダクトリスクに基づいて決めていく」やり方なので正しいのですが、今回は「テストしない」と決めた部分についても
- QAチーム以外にテストしてもらおう！
- QAチーム以外にテスト依頼してOKもらったが、「テストするからチェックリスト下さい」となりQAチームにタスクが戻ってきた！
という動きをしてしまい、結果、QAチームはQA保証対象外のリスク設定要素についても、なにがしかの形でテスト設計することで工数削減効果はあまりなかった、という結果になりました。
リスクベースドテスト時、工数も適正な量に抑えたいのであれば、QA保証対象外部分については「やらない」という選択をすること、「やらない」代わりに問題発生した時はどのようにするか等をステークホルダーと話し合っておくことが必要そうだな、と感じました。
②はまさに、リスクベースドテストで狙いたいところだったので、満足いく結果でした！
これから
リスクベースドテストをやってみたのは2020年初夏～秋頃のテスト案件なのですが、現在ユニファQAチームではリスクベースドテストを行っていません。
理由としては、案件がさらに増えたため外部QA会社さんに入って頂いたりと大幅なQA体制変更があったこと、並行して複数案件が走っているので日々変わりゆく状況変化に対応することの方が、QAチームとしても重要になっているためです。
ユニファQAチームって、品質をあげるための活動は何でもできることが魅力です。 今はQA体制の安定化に力を入れていますが、いつかリスクベースドテストももっとブラッシュアップした形で取り組みたいと思っています！
ここまでお読み頂き、ありがとうございました！ まだまだコロナで大変な時期続きそうですが、体調に気をつけて、元気にQA＆テストエンジョイしていきましょうね！では！
ユニファQAチームではQAエンジニアさん、テスト自動化エンジニアさんを大募集しています！
カジュアル面談も大歓迎です！
「ちょっとならお話してあげようかな」って思われた方はWantedlyの求人ページから「話を聞きに行きたい」ボタンをクリックお願いしまーーーーーーす！
