00:07
皆さん こんにちは。B-Testing のブロッコリーです。この
B-Testing.fmは、QAエンジニアである 私 ブロッコリーが、テストや品質
に対する私なりの考えを約10分間 で語っていくポッドキャスト番組
です。オープニングは、最近行った ところについてなんですけれども、
プラネタリウムに行く機会が続けて 2回あって、2回とも別の場所なんですけ
ども、その中の一つを今日紹介したい なと思うんですけれども、今日紹介
するのは、東京の竹橋にある科学技術館 のプラネタリウムですね。これ、
科学技術館自体は子ども向けなところ ではあるんですけれども、そこの
プラネタリウムがどういうものか というと、ただ単に星の映像を
流すわけではなくて、自分が行った 回は、大学教授の講演形式みたいな
感じになっていて、そこであった のが、太陽系の惑星が表示されて
いて、普通にやったら惑星が回る わけですけれども、そこにもしも
近くに太陽系の太陽以外にもう一 つ太陽があったらっていうシミュレーション
の映像があってですね、実際に参加 する人に当てて、じゃあ太陽どこ
に置くみたいに聞いて、その場で 太陽を置いて、じゃあ太陽が2個
3個あったとき、じゃあ実際にシミュレーション やってみましょうって言って、惑星が
すごい規則性のない動きをして、 なるほどみたいな、そういうのを
子どもに楽しませるみたいなことを していました。すごい個人的にも
楽しかったなっていうところでした。 もう一つ別のプラネタリウムにも
行ったんですけれども、それの紹介 はまた今後別のエピソードのときに
話せればと思っています。今日は テストを早めに行うことの大切さ
についてこれから喋っていきたい と思います。ということで今回も
btesting.fmスタートです。ということで 今日の話ですね、テストを早めに
行うことの大切さという話なんです けれども、簡単に言うとテストを
早めに行うと手戻りの工数が減る と言われています。それは何か
っていうとテストの原則という ものがあります。これはJST QBの
白髪に書かれているものでして、 少し前はソフトウェアテストの
7原則と呼ばれていました。その中の 原則の三つ目ですね。そこに早期
テストで時間とコストを節約という 原則があります。実際に紹介します
が、プロセスの早い段階で欠陥を 取り除くと、その後の作業成果物
03:05
では取り除かれた欠陥に起因する 欠陥を引き起こすことはない。ソフトウェア
開発ライフサイクルの後半に発生 する故障が少なくなるため、品質
コストは削減されるというふう に白髪には書かれています。これ
何言ってるかというと、要は早め にテストするとコストが削減できる
よというお話を書いているということ なんですけれども、じゃあこのコスト
の削減って具体的にどれぐらい 削減されるのかなというふうに
気になるところであるんですけれども、 それについては2個紹介したいな
と思っています。一つは結構昔の 文献ではあるんですけれども、こういう
ふうに書かれているものがあります。 要求仕様で1倍の修正コストがあった
ときに、それが設計だと5倍、実装 だと10倍、テストだと20倍、リリース
後だと200倍かかるというふうに 言われているものがあります。これは
何言っているかというと、例えば 要求仕様を作りましたと。その段階
で関係者にレビューとかした段階 で、いや、これは別に要求に沿って
ないよ。こんなお客さん別に欲しい わけじゃないよという指摘があった
としますと。それが、なるほど、 じゃあ要求仕様直さないとねって
言って修正をしたとします。その ときに仮に1時間かかったとします
と。これを要求仕様の段階で見逃 してしまって、設計でも見逃して
実装でも見逃して、テストでも見 逃して、そのままリリースをして
しまったと。リリースした後に、 じゃあお客さんにこれ使ってください
って渡したら、いや、別にこういう ものをやりたかったわけじゃない
んだけど、直してっていうふうに 言われた場合に、全く同じ箇所
の修正すべき場所だったんです けれども、リリース後の段階で修正
すると200時間かかってしまうっていう ふうに言われていますと。今、これは
ちょっと分かりやすくするために 修正コストっていう言い方で、要求
仕様の段階だと1時間、リリース 後だと200時間っていう言い方を
しましたけれども、実際にはコスト なので、修正のコスト以外にも他にも
いろいろとコストがあると思っています。 特に例えばリリース後のコスト
として言えば、いや、こんなの使いたい わけじゃないんだけどとか、これって
どういうふうなことをしたいの みたいな、問い合わせがいっぱい
来るみたいな、その問い合わせの 対応コスト、カスタマーサービス
の人たちが頑張って対応するような コストとか。あとは、なんか新しい
のリリースされたけど、こんなの 別に使いたくなかったんだけど、
このプロダクトをそのまんま使い続ける 意味ないなっていうふうになっちゃう
みたいな、信用失墜のコストとか そういうのも含まれて、この200倍
っていうのがあります。この200倍 というのが出た文献より、もう少し
06:05
新しいほうの文献、NISTの論文から 持ってきているんですけれども、
それに関しては少しコストは低く 見積もらえています。何かっていう
と、要求定義とかアーキテクチャ 設計の段階で1倍で済むような修正
のコストがあったとして、それが 単体テストだと5倍、それがコンポーネント
テスト、統合テスト、システムテスト だと10倍、初期顧客のフィードバック
やベータテストだと15倍、製品リリース した後30倍かかるっていうふう
に言われている文献もあります。 先ほどは200倍でしたけれども、
この文献だと30倍っていうふう になっています。ただ、どちらにしろ
コストはやっぱりすごい高くな っちゃうわけですね。じゃあそういう
ふうに200倍とか30倍とかっていう すごい高いコストにならないように
するためにはどうすればいいか っていう話なんですけれども、それは
どうすればいいかっていうと、早い 段階でその欠陥を見つけましょう
と。修正することで開発にかかる 総コストは削減できるはずですね
と。リリース後にばっかり欠陥を 見つけるとすごいコストがかかる
から、できるだけ早く実装とかを 行う前の段階からテストとかレビュー
とかもその一つなんですけれども、 結果を見つけるっていう作業を
そこに手間暇かけることで結果的に 総コストを削減できるという話
があります。けどこれ実装とかを 行う前からテストのことを考える
ってどう考えるのっていう話なんです けれども、皆さんの子供の頃を
ちょっと思い出してもらいたいん ですけれども、例えば中学の歴史
の授業で学校の先生が例えば往任 の乱って書いて、この往任の乱っていう
言葉テストに出すからがっていう ふうに先生が言ったとします。こう
なるとどうなるかっていうと、実際 の期末テストとかの往任の乱が答え
の問題って正解率がすごい高くなる はずなんですよね。なんでかっていう
と生徒が頑張って、ここ往任の乱 ってテストに出すって言ってた
な、じゃあちゃんと覚えなきゃっていう ふうに対策をするわけですね。試験
対策をするので、期末試験とかの 正解率が上がるっていうことになります。
これは今学校のテストの話で例え ましたけれども、これはソフトウェア
テストにおいても同じようなことが 言えると思います。ある意味、自分
はテストの予告って呼んだりするん ですけれども、ここテストをしよう
と思ってますっていうのを事前に 予告することで、そもそもバグが
発生しなくなる、欠陥が発生しなくなる っていうことに繋がるわけですね。
っていうのがさっき言った設計 の段階から欠陥を見つけるような
テストの活動の一つかなと思って います。実際にその200倍とか30倍
09:03
とかアドコートになればなるほど コストがかかるっていう言い方
をしたんですけれども、実際に欠陥 が発生すると具体的にはどんな
コストがあるかっていうと、リリース 前であっても、例えばチケット
を起票するコストですね。バグチケット とかを実際に起票するコストが
あったりとか。あとは例えば開発 をして、開発をした後1週間後ぐらい
にテストをして、ここ欠陥ですよ、 バグありましたよっていうふうに
起票して帰ってきたときに、そもそも あれ、1週間前の自分どんな実装
したっけなっていうのを思い出す のもコストですよね。さらにもちろん
修正することもコストですし、修正 したら終わりではなくてもう一度
テストする、再テストと呼ばれたり しますけれども、もう一度テスト
してちゃんと直ったよねって確認 することも追加のコストです。さらに
じゃあその部分だけテストすれば いいかっていうとそうではなくて
その近い部分、関連する部分でデグレード がないか。今、欠陥があったよっていう
ところは直したんだけど、その結果 他の部分で別の欠陥が発生して
いたらもともともないので、そういう のが発生してないかどうかを確認
するのもやっぱりコストがかかります。 その後、最後、起票したチケット
をちゃんと完了まで持っていって これで大丈夫でしたよっていう
ふうなチケットを操作すること自体 もやっぱりコストになるわけですよ
ね。こういうふうにさまざまなコスト が発生する、欠陥が発生するとすごい
手戻りが発生しちゃうわけですね。 こういうことを早い段階でテスト
を予告するみたいな活動をする ことで防ぐことができるんじゃない
かっていうことですね。これがテスト を早めに行うことの大切さにつなが
っているかなと思っています。 けど、実際にソフトウェアテスト
でどうやってこれやるのっていう のは、ちょっと具体的な例に関して
はまた別のエピソードの中で紹介 したいなと思っていますので、今後
のエピソードを楽しみにしてみて ください。
ではエンディングです。 btesting.fmではリスナーさんからの
お便りを募集しています。エピソード の感想や私に聞いてみたい質問
やテストの悩みなど、どんなことでも かまいません。投稿フォームは番組
概要欄にあります。またエピソード の感想は、ハッシュタグBtesting
BanscotestingでXのポストをお願いいたします。 今日の話とか、具体的にどういうこと
なのみたいな感想でもかまいません。 ぜひXのポストもしくは投稿フォーム
から投稿をお願いします。感想を 書いていただいた方には、もれなく
いいねもちゃんとしたいなと思って います。もしもこれからも聞きたい
12:04
という方はお手持ちのPodcastアプリ で番組のフォローもお願いします。
今日も話したとおり、今後のエピソード の中で今回の続きとかも
話したいなと思いますので、ぜひ フォローお願いします。最新回が
上がったときにはすぐ気づける と思いますので、ぜひよろしくお願いします。
ということで今回はここまでです。 それではまた次回。バイバイ。
