mhlyc -practice

ソフトウェアテストと品質保証がメインテーマです。

テスターちゃんSS「リスクに応じたテスト」

テスターちゃんの本を読んで、気分が高まったのでSSを書いてみました。

testerchan.hatenadiary.com

 

九華「テストケース、できましたっ」

ウサコ「お〜、どれどれ、見してみ」

ウサコ、九華の作成したテストケースに目を通す。

ウサコ「……」

九華「……?」

ウサコ「ダメだな」

九華「ええ〜っ! なんでですか!? >△<」

九華は疑問に思った。ちゃんと、教わった通りの書式でテストケースを書いた。誤解されるような表現がないかも、大田さんに見てもらった。なのに、どうしてこれではダメなのだろうか。

ウサコ「今回作るのは課金機能のテストケースじゃないか。それだと、これじゃあバリエーションが足りなすぎる。割り込みは? 通信遮断時の確認はしてる? 端末の決済モードも、設定しているものによって挙動が違うかもしれないし、その辺もみておかないと……」

九華「…… >△<」

ウサコ「わ、わかった。わかったから、ちゃんと教えるから。そんな顔すんなって」

九華「……◯△◯」

ウサコ「ほんとコロコロ表情が変わるよな…… で、今回覚えてほしいのは、『リスクに応じたテストをする必要がある』ってことだ」

九華「リスクに応じたテスト……?」

ウサコ「そう。例えば、今回テストしてる課金機能がバグった時と、画面に表示する項目名の誤字だったら、ユーザはどっちが困ると思う?」

九華「多分……課金機能の方が、バグったら困ると思います」

ウサコ「そうだろ。お金が絡んでるしな。このように、その機能がバグった時のユーザへの影響が大きいほど、リスクとしては大きく設定するんだ。それで、リスクが大きいほどテストケースのバリエーションや観点を増やして対応する」

九華「そうだったんですね!」

九華は改めて自分が作成したテストケースを見直してみた。操作のパターンや端末の状態など、観点を増やせそうなところがいくつかありそうだ。もう一度テスト設計をやり直してみよう。

ウサコ「基本的にはその影響度と、発生確率を掛け合わせてリスク値とすることが多いな。他にも要件の変更度合いを考慮したりと色々とやり方はあるんだけど(参考)、まずは影響度と発生確率を考えることから始めるといいぞ」

九華「発生確率は、どうやって考えたらいいんですか?」

ウサコ「わかりやすいのは使用頻度だな。例えばSNSだったら、プロフィールの変更機能よりも投稿機能の方が使う頻度は高いだろ? だから、投稿機能の方が発生確率としては高いと判断するんだ」

f:id:mhlyc:20180526130014j:plain

九華「なるほど!わかりました( *ˊᵕˋ* ) ありがとうございます! ……ところで、さっきからウサコさんが上下に揺れているのはなぜなのでしょうか……?」

ウサコ「ああ、話してる間にカーフレイズをしてたんだよ。とりあえずあと50回くらいやっとこうかな」

九華(いつも通りのウサコさんだった……>△<)

end

 

 

九華ちゃんとウサコの掛け合いを書いてみました!

ウサコが出てきたのは単純に僕が好きなキャラだからです。