00:07
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
はい、ということで第3回になるわけですけれども、自分でですね、第1回、第2回を編集してみて聞いてみたんですけれども、1回目と2回目すごい違いがあるなと思っていて、何かというと自分の声の大きさですね。
第2回のオープニングでも話したんですけれども、やっぱり自己紹介とか会社紹介とか、自分は緊張しがちで、そうすると声が小さくなるんですね。
で、それに合わせてちょっとマイクの位置とかも近づけていたんですけれども、その結果第2回品質のこといっぱい語ってたら、自分の中で熱くなっちゃって、結構もしかしたら音割れしていたかもなっていうのはすごい申し訳ない感じなんですけれども、
マイクの距離感というのはちょっと考えないといけないなと思ったところです。はい、そんな中、今日第3回はですね、テストって何のために行うのっていうのをちょっとお題として話していきたいなと思います。
それではよろしくお願いします。はい、先ほど言った通りテストって何のために行うのっていう話なんですけれども、皆さん多分普段テストをやっている方が多いかなと思います。
開発者であってもテストをやったりしていると思うんですけれども、そもそもこれテストって何で行うんですかね。ちょっと考えてみてほしいなと思うんですけれども、
よくある意見としては、テストでバグを見つけたいんだよとか、あとは仕様書通りに作られているか確認するためにテストってやるんだよとか、
自分が想定していた通りになっているか、想定通りになって動いているかを担保するためにテストってするんだよっていう意見がよくあったりします。
あとはたまにあるのは、いや正直そんな考えてなくて、いや冗長に言われたからやってました。そういうふうな自分なりのテストって何で行うのかっていうのをちょっと考えてみてほしいんですけれども、
この中でJSTQBというものがあります。これはテストとか品質についての資格試験があるんですけれども、そこの資格を受けるにあたってのシラバスがあります。
これは世界的に共通のやつですね。世界的にはISTQBがあるんですけれども、それの日本語版としてJSTQBというものがあります。
それのシラバスの2011年のバージョンではテストの目的っていうのはこの4つを書かれています。
03:08
欠陥の検出、対象ソフトウェアの品質レベルが十分であることの確認、意思決定のための情報の提示、そして欠陥の作り込みの防止の4つです。
まず1つ目の欠陥の検出は、先ほどよくある意見として言ったバグを見つけるためとかいうやつですね。
欠陥、バグとか不具合を見つけるためにやる。これはよく想像されるかなと思います。
そして2つ目、対象ソフトウェアの品質レベルが十分であることの確認。
これちょっと注意しなくちゃいけないのは、あくまでも品質レベルが十分であることの確認なので、完璧とは言ってないんですよね。
なので、これテストをしたからこのソフトウェアはもうバグないよ、完璧だよって言い切ることはできないという話なんですね。
あくまでも十分であることの確認です。
そして3つ目が意思決定のための情報の提示。
この意思決定っていうのは、対象のステークホルダー、いろいろなステークホルダーがいると思います。
例えば唐突にこのソフトウェア使ってよってお客さんに渡したら、本当にお客さん使ってくれるんですかね。
本当にちゃんと動くのって不安になるかもしれない。
その時にこういうテストをしました、だから大丈夫なんです、使ってくれませんかって言ったら、じゃあ使ってみようかってなるかもしれません。
ここでよくイメージしやすい例として言うと、テレフォンショッピングがありますよね。
このテレフォンショッピングでフライパンとかで、これ何万回もヘラでこすっても全然傷つかずにきれいに洗えるんですよみたいな、何万回の耐久試験に合格してますみたいな。
そういう話を見て、そんだけいいフライパンだったら買おうかなって視聴者が思うかもしれません。
これも買おうっていう意思決定をするための情報の提示になるわけですね。
また、対社外とかお客さんだけじゃなくて、対社内に対してもそうですね。
例えば、来週リリースの予定のものがありましたけど、テストをやっていたら重大な不具合にちょっと見つかりましたと。
このまんまだと来週リリースしたらまずいんじゃないですかっていうのを提示できる。
そうすると、それを見た開発の部長なりが、じゃあこれ来週のリリースはちょっと延期しようかとか、
じゃあこの機能の部分はリリースに含めないようにしようかとかっていう風な意思決定ができるわけですね。
っていう意思決定のための情報の提示があるっていうのが3つ目です。
そして4つ目、欠陥の作り込みの防止。
これが多分一番出にくい話だと思うんですけれども、
06:01
先ほど一般的な意見で仕様書通りに作られているか、確認するとか、あとは担保するとか、
そういう風な言葉を結構言ったりすると思います。
こういうような意見が出てくる背景としては、こう考えてませんかね。
まず開発があって、開発が終わった、さあテストの出番だって思ってませんかね。
開発の後テストをするっていう風に思っている人も多いかもしれません。
それだけじゃないよっていうのが、この4つ目の欠陥の作り込みの防止という定義になります。
つまり、物を作る前からテストのことを考えることによって、
欠陥、バグとか不具合を予防することができる。
これも重要なテストの役割なんですね。
ちなみに、このJSTQBのシラバスの2011年度版でこの4つを紹介しましたが、
最新の定義はもう少し多くなっています。
一応これも読み上げますと、
要件、ユーザーストーリー、設計およびコードなどの作業成果物を評価する。
故障を引き起こし欠陥を発見する。
求められるテスト対象のカバレッジを確保する。
ソフトウェア品質が不十分な場合のリスクレベルを下げる。
使用化した要件が満たされているかどうかを検証する。
テスト対象が契約、法律、規制の要件に適合していることを検証する。
ステークホルダーに根拠ある判断をしてもらうための情報を提供する。
テスト対象の品質に対する信頼を積み上げる。
テスト対象が完成し、ステークホルダーの期待通りに動作するかどうかの妥当性確認をする。
全部で1、2、3、4、5、6、7、8、9個テストの目的を言っています。
ちょっとこれ9個が多かったりするので、自分はよく先ほど言った2011年度版のテストの目的をよく使ったりします。
ちなみにこの欠陥の作り込みの防止の話も、今の最新の定義の中で入っているかなと思っていて、
一つ目の目的ですね、要件、ユーザーストーリー、設計及びコードなどの作業成果物を評価するというのがまさにそれに当たると思います。
コードを書いて、そこから動くものが出来上がっているのを評価だけではなくて、
そのコードを書く前の要件とかユーザーストーリーとか設計に対しても評価するよと。
これは結局バグを作り込むことの予防につながる、防止につながることかなと思うので、
これもやっぱり2011年度版の欠陥の作り込みの防止の意味合いも含まれているのかなと勝手に思っています。
ということで、今回は普段あまり意識していなかった人も多いかなと思うんですけれども、
09:00
そういうテストの目的について語っていきました。皆さんいかがでしたでしょうか。
前回話した品質って何だっけっていう話もそうですけれども、
このテストって何でやっているのっていうのは、ぜひ自分の会社の同じ組織の人たち同士で話し合ってみるのもいいかもしれません。
はい、ということでエンディングです。
testing.fmではリスナーさんからのお便りを募集しています。
エピソードの感想だったりとか、私に聞いてみたい質問やテストのお悩みなどどんなことでも構いません。
口でハッシュタグBテスティング、Bアンスコテスティングでツイートをお願いします。
もしもそこでX状で表明するのが難しい、恥ずかしいという方はDMを開放していますので、
私のXのところに、私宛てにDMを送ってください。
あとちょっとフォームも用意しておこうと思うので、フォームから直接お悩みとかを投稿していただいても構いません。
もしもこれからも聞きたいという方はPodcastアプリで番組のフォローもお願いします。
ということで第3回のbtesting.fmは以上となります。
それではまた次回。バイバイ。
Btesting.fm
