# タイトルコール ようこそ、世界が広がるソフトウェア品質で。 このチャンネルでは、QAエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストウェア品質の世界を広げていきます。 # 📣放送/相談/コメントリクエストを募集中！ 放送・相談・コメントのリクエストを募集中です。 おしゃべりリクエストボックスという名前のGoogleフォームを作りました。 このチャプターのリンクに貼っております。 2025年3月31日までの期間限定でトライアル運用中です。 こういう話を聞きたい、相談に乗ってほしいなど、ぜひぜひご意見をいただきたいです。 一緒にこのチャンネルを盛り上げていきたいので、あなたの投稿をお待ちしております。 # リスクとは？品質リスクとは？そしてリスクベースドテスト こんにちは、Qエンジニアのさみぃです。今日も楽しんでますか? 今回はですね、リスクベースドテストのお話をしようと思います。 結構その新機能軟件のテストマネージメント、 テストマネージャーとして入るときってリスクベースドで物事を考えていることが多いなぁって思っているのが取り上げたきっかけの一つです。 今回の話の流れとしては、まず最初にリスクとはというところを深掘りというかおさらいをしようかなと思っていて、 その後、とはいえ実務としてリスクのアセスメントとかリスクの洗い出しして、 リスクを防ぐためのアプローチしてというのを本に書いてある通りにガチガチにやるのって大変だなぁと思っているので、 すごく簡略的にやるにはこうしたらいいんじゃないかみたいなお話を考えていることをお話ししようと思います。 はい、ということでまず最初がリスクについてですね。 おなじみのISTQBグローサリーで調べてみます。 リスクとは将来否定的な結果を生む要素というふうに書かれています。 なるほどですね、リスクというのは要素らしいです。 続いてJSTQBのファウンデーションレベルの調査数、 これ新しいですかな、2018年バージョンの71ページ目にもリスクについて書かれています。 5.5章のリスクの定義を読み上げますね。 リスクは将来に否定的な結果となる事象が起きる恐れを含む リスクのレベルはそのような事象が起きる可能性とその影響、 事象による結果がもたらす損害で決まるというふうに書かれております。 ここまでのところを読んでみて私なりの解釈だと、リスクというのは悪いとか望ましくないとか、 顧客とかユーザーにとって悪い結果やイベントをもたらす要素であるということがわかりました。 さらにそのリスクのレベルというのは可能性と影響、インパクト、損害というものによってそのリスクの大きさというものが決まるわけですね。 JSTQBのファウンデーションレベルの調査数だと可能性とその影響で決まるって書いてありますけど、私なりの言葉にすると ひどさあるいはヤバさかける発生確率というのでそのリスクのレベルが決まってくるというふうに考えています。 ちょっと脇見きにそれますが、ISJQBグローサリーでリスクという単語で日本語で検索をしたら16件の結果が出てきましたのでバーッと読み上げます。 セキュリティリスク、プロジェクトリスク、プロダクトリスク、リスク、リスクアセスメント、リスクコントロール、リスクベースドテスト、リスクマネジメント、リスクモニタリング、リスクレベル、リスク分析、リスク可能性、リスク影響、リスク識別、リスク軽減、品質リスク、以上です。 何か気になる用語とか、なんだろうと思った用語があればISJQBグローサリーでぜひ見てみてください。 さっきリスクベースドテストをテストマネジャーとして入った時にやってるって言っちゃったんですけど、JSTQBのアドバンスのレベル、テストアナリストの知らばすにガッツリリスクベースドテストにおけるテストアナリストのタスクというのが書かれています。 2章ですね、2章にガッツリ書かれていますので、テストマネジャーというよりかはテストアナリストとしてやるべきことがたくさんあります。 リスクの話に戻ってくるんですけど、まだちょっとリスクって何やねんというか、品質リスクって何なのかみたいなところのイメージついてないんですよね。 ちょっとどこから引用を持ってきたか調べたか、引用元忘れちゃったんですけど、ソフトウェアテストにおけるリスクっていうのを考えた時に、結構2つに分けることができます。 1つがプロダクトリスクで、もう1つがプロジェクトリスクになります。それぞれ具体例をご紹介したと思うんですけど、プロダクトリスクですね。 プロダクトリスクの具体例としては不正な計算ということで、何か計算結果ですね、何でもいいですけど給与計算でもいいですし、の計算結果が間違ってしまっている、計算結果が不正であるというのが1個プロダクトリスクの分かりやすい具体例になります。 他にもユーザー入力に対する応答の遅れというものもプロダクトリスクの一例になります。何か検索画面で入力をして、検索ボタンを押して、それで結果が返ってくるまでの応答が遅いというところも非機能のリスクとしてプロダクトリスクの1つになります。 他にも画面の分かりにくさというところも、使用性に対する非機能リスクというところでプロダクトリスクの1個具体例になります。 一方でプロジェクトリスクの具体例を4つほど紹介するんですけれど、例えばテストによって大量の問題が検出されてテストの進捗が滞るというのもプロジェクトのリスクですし、 あとはテスト環境の構築ができないとかですかね、何かいろいろハードウェアの必要なものがあってそれが準備ができなくて、そもそもテスト環境が構築できてないというのもプロジェクトリスクですし、 あとはプロジェクト後半で使用変更が入ってしまってやり直しが発生するのもプロジェクトリスクですし、あとは人員のスキル不足というものもプロジェクトリスクの1個の具体例になります。 どうですかね、リスクのイメージついてきましたでしょうか。ここからそのリスクのイメージがついたと、じゃあどうやってそのリスクを防ぐんだっけという話に移っていこうと思います。 まさに品質リスク、リスクを軽減するための方法というのがテストになります。これはJSTKBのファウンデーションレベルのシナバスの15ページ目1-1に書いてあるんですけど、一番最初はテストとは何かという章の中にありまして、 引用ではないんですけど、テストとはソフトウェアの故障が発生するリスクを低減する一つの手段であるというふうに書かれています。要はテストというのはリスク、品質リスクを軽減するためにこのやり方です、手法ですということですね。 じゃあテストを使ってどうやって品質リスクを軽減するんでしたっけというところで、ちゃんとしたプロセスですね。これはJSTKBのテストマネージャーのシナバスに載っているんですけれど、2-3-1のリスクベースのテストですね。 正式なプロセスとしては4つのプロセスがあります。リスク識別、リスクアセスメント、リスク軽減、そしてリスクマネジメントというのですね。 ただこれ結構全部ちゃんとやろうとするとすごい重たいプロセスになってしまうんですよね。例えばリスク識別で、一体何がリスクなのかというのを最初に識別する必要があるんですけど、 その手法としては専門家へのインタビューとか第三者による評価アセスメントだったりとか、リスクテンプレートのようなものを使ってどれがリスクなのかを識別するとか、 プロジェクトを振り返ってとか、ブレストするとか、チェックリストを使うとか、過去の経験を活用するとか、などなどなどめちゃくちゃ大変そうですよね。 さらにそのリスクアセスメント、識別をした後には評価をする必要があるので、リスクの調査としてリスクを分類する、ちゃんとISO25000の品質特性を使って分類しましょうとか、 あとさっきリスクのレベルの話は可能性×影響という話をしたと思うんですけど、可能性を決める要因みたいなところですね。 例えばどのくらい技術が難しいかみたいな複雑性というところも可能性に影響するしとか、 変更率がめちゃくちゃ高いプロジェクトとか環境、文化だったりすると、そのリスクが顕在化する可能性って上がりやすいよねとかですね。 もう一個その影響の方ですね、影響度合いっていうのもその機能が使われる使用頻度だったりとか、どのくらいその機能が重要なのか、ビジネスドメインという文脈で大事なのかみたいなところによってもインパクトっていうのは大きくなりますよねとか、 業務の損失みたいなところですね、そのリスクが発生した時のインパクト、影響っていうのはどのくらい業務が失われてしまったのか、ロスが発生してしまったのかでも大中小変わってきますよねみたいなところをいろいろ洗い出しをした上でマッピングをするんですね。 だいたい大中小とか高中低みたいなところで発生する確率と発生した場合の影響度合いっていうのを表にして数値化をして、じゃあこのリスク、識別されたリスクっていうのは評価をするとこのくらいになるよね、何ポイントになるよねみたいなところを計算するんですよね。 じゃあというところまでをやった上で、さらにリスク軽減というところでようやくそれらの識別、評価、アセスメントされたリスクを軽減するためにこういうことをやっていきましょうっていうのをテスト計画書とかに盛り込んでいくみたいなことをやっていくわけですよ。 ここまで聞いただけですごく大変そうかなっていうところが伝わったかと思うので、例えばスタートアップとか小さい規模の開発組織とかでそこまでできるかっていうと結構難しいと思うんですよね。 はい、ということで最後と言いますか後半戦で一番痛かったこと、じゃあもうちょっと簡素化して実務でパッと取り入れるためにはどうしたらいいのかっていうところを最後お話ししようと思います。 これはあくまでも私の一個人の考えではあるんですけれど、もしですね会社で品質目標とかこれは絶対に防がなきゃいけないとか守らなきゃいけない最低限の機能だったり体験というものがあればぜひそれを参考にしていただければいいと思うんですけれど、 それがない場合でも今回の案件というものに対して一番守りたい体験とかこれだけは絶対防ぎたい不具合みたいなものをリストアップしてそれを防ぐためにはどういうテストをしたらいいのかっていうのを考えるだけでも一番簡素的なリスクベースのテストになるかなというふうには考えています。 # 今日のほっこり話🦵 今日のホッコリー話です。今日は足運動の話をします。 先日ですね、週末に公園に歩きに散歩行ったんですよ。全然運動してなくて。 そしたらですね、なんと公園の階段で転ぶまで行ってないんですけど、足をグキッとひねってしまいまして、右足をいたわりながら歩く生活をしております。 足をくじいてから痛くなるまでの期間が年々というか10年前、20年前と比べるとすごく遅くなっているので、そこですごく自分も年を取ったんだなぁなんてことは感じたりするんですが、 今回足をくじいてしまったのも運動不足が原因かなと思うので、パーソナル人も再開しようか悩んでおります。 運動しなさいという激励のコメントをお待ちしております。以上、今日のホッコリー話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はVoicyのトークテーマ、気になるニュースというハッシュタグに乗ってお話をしようかなと思っております。 今回の放送を聞いて、なるほどな、確かにな、マグビーになったなと思った方は、 是非、画面右下のハートマークでいいねを押していただけるととても励みになります。 また、SNSや口コミなどで広めていただけるととても嬉しいです。 それではまたお会いしましょう。 バイバイ。