VoicyでQAのお手伝いをしている、森田 です。
先日、エンジニア勉強会で「品質リスクってなに？」というワークショップを実施しました。参加した方からは、「たまには立ち止まって、言葉の定義を改めて考えるのも大事」というコメントをいただき、励みになっています。
今回は、品質について学びたい方に向けて、品質リスクについてお話したいと思います。（勉強会の内容を一部抜粋しての紹介となります）
品質とは？
突然ですが、クイズです。品質とはなんでしょうか？
以前、「品質って何だ？」ワークショップを行いましたので、気になる方はこちらのブログもご覧ください。
さて、正解ですが、「どれも正しい」です。
品質そのものの定義は複数存在し、とても曖昧であることがわかります。
皆さんが「品質」という言葉を使うとき、どんな意味で使っていますか？同じ職場の人同士でも定義は異なっているかもしれません。だからこそ、その組織・プロダクトでいう品質は何か、今一番優先されるのはどういう品質なのかについて議論をすることが重要だと考えています。
クイズの選択肢の中で一番イメージしやすい定義は、Weinbergさんの「誰かにとっての価値である」かもしれませんね。
リスクとは？
続いて、もう1問クイズです。
リスクとはなんでしょうか？知っているようで、意外に迷ってしまいますよね？
リスクとは、悪い/望ましくない結果やイベントをもたらす可能性です。リスクは、プロダクト品質やプロジェクトの成功に悪影響を及ぼします。「ひどさ（度合い）×発生確率」で算出することができます。
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
ソフトウェアテストに関わるリスクには、プロダクトリスクとプロジェクトリスクの2種類があります。今回話題にしているの品質リスクはプロダクトリスクを指します。
品質リスクとは？
続いて、品質リスクについて考えてみましょう。品質リスク＝プロダクトリスクをわかりやすく言い換えると、「ユーザーの想定通りにソフトウェが機能しない、というリスク」と言えます。
参考：湯本 剛 "品質リスク（プロジェクトリスク・プロダクトリスク）の許容度合い"
リスクの算出方法が「ひどさ(度合い) × 発生確率」だったように、
品質リスクの算出方法は、「ソフトウェアの問題によって引き起こされる損害 × 発生確率」となります。
あなたの担当プロダクトの品質リスクとは？
ここまで、ソフトウェアテストの一般論としての品質リスクについて説明してきました。では、皆さんが担当しているプロダクトの品質リスクには、どのようなものが挙げられますか？
チートシートを用意しているので、ぜひ手元で書き出してみてください。
Voicyプロダクトの品質リスク例（ほんの一部です）
- アプリが起動しない
- 音声の収録・再生ができない
- 振り込み金額が正しくない
- 決済の失敗
品質リスクを低減する方法とは？
最後に、品質リスクを下げていく方法についてです。テストは品質リスクを低減する手段の1つです。
参考：JSTQB FLシラバス 15ページ
https://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2018V31.J03.pdf
参考：JSTQB AL テストマネージャ シラバス > 2.3.1 リスクベースドテスト
[JSTQB AL TM] 2. テストマネジメント を視覚的にまとめてみた（2/4）
JSTQBのシラバスには、リスクベースドテストとしてプロセスが紹介されています。しかし、これをきちんとやろうとすると結構コストがかかります。
参考までに、それぞれのプロセスの概要をまとめた画像を載せておきます。
組織やプロダクトのフェーズによっては、このような重厚なプロセスが必要になるタイミングもあるとは思います。ですが、もう少し簡易的にできないかを考えてみました。
以下の内容は、個人の経験をベースに編み出したやり方となります。
1.品質リスク一覧があることを前提としておりますので、ない場合は担当プロダクトの品質リスクについて考える、周りの人と話すところから始めましょう。品質リスクにはリスクの高いものから低いものまで様々です。まずはこれだけは防ぎたいという事象を羅列すると、品質リスク「高」の一覧として活用できます。
2.各案件のテスト設計を実施するタイミングで、実装方針や実装内容と品質リスク一覧を見比べます。影響がありそうなものをピックアップしていきます。影響があるかわからないものは不安に駆られてテストに入れがちです。そんな時は、ピックアップした品質リスクに関連度をつけて関連度の高いものを優先的にテストとして実行するのをおすすめします。
3.ピックアップした品質リスクをテスト観点として書き出します。リグレッションテストの一部として活用します。
4.テスト実行時に不具合として検知した場合は、リリースの前に不具合を修正する機会を提供できたことになりますし、不具合が検知されなかった場合は、該当リスクが発生しないことを確認できたことになります。
おわりに
今回は品質リスクについてお話しました。品質リスクは一人で考えるというより、関係者と議論して認識を合わせていくことが大切です。あなたの担当プロダクトの品質リスクのイメージは湧いてきましたか？
このブログが品質リスクの理解の一助になれば幸いです。最後までお読みいただき、ありがとうございました！
