オープニングとテストの7原則（後編）の紹介
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QAエンジニアである私、ブロッコリーが、テストや品質に対する私内の考えを、約10分間で語っていくポッドキャスト番組です。
最近ですね、会社の方でもですね、ポッドキャストをホストするようになりました。
テックトークという番組名で、そちらの方ではですね、大体30分前後ですかね。
ゲストの同僚を招いてですね、自分がホストとなって2人でトークしていて、技術会多め、けどたまに雑談会も含めて各週ぐらいでやっているというのになります。
それの収録もそうですし、編集とかも自分でやったりしているんですけれども、やっぱりこの B-Testing.fm をやってからですね、編集がすごい同じようにできるっていうところですね。
編集で使っているですね、サービスもですね、同じなので、すごい慣れた感じでやれているかなと思っています。
今日はですね、前回話したテストの7原則の後半3つについて紹介していきたいと思います。
ということで、今回も B-Testing.fm スタートです。
今回はテストの7原則の後編になります。
これは改めて前回も話したところであるんですけれども、テストの7原則というのはそもそも何かという話ですが、
ISTQB および日本語訳している JSTQB に記載されているあらゆるテストで共通に使える一般的なガイドラインになっています。
これはテストエンジニアとか QA エンジニアとかのみならず、開発者とかマネージャー、経営層まであらゆるロールの人に知ってほしい原則になっています。
今回はその後編として原則の5、6、7について話していきます。
原則5：テストの弱化（殺虫剤のパラドックス）
まず一つ目がテストの弱化ですね。
7原則の5番目、テストの弱化です。
これは何を言っているかというと、同じテストを繰り返すとだんだん新しい欠陥を発見できなくなるという原則です。
これは昔は殺虫剤のパラドクスと呼ばれていました。
少し前の ISTQB、JSTQB の調査では殺虫剤のパラドクスと呼ばれていました。
どういうことかというとですね、ある虫がいてその虫に対する殺虫剤を開発したとしますと、
そうするとその虫の中にはその殺虫剤に耐性を持った虫が出てくるかもしれないと。
そうすると耐性を持っていない虫は殺虫剤によって殺されるけれども、耐性を持っている虫がそのまま繁殖することによって最初の殺虫剤では効かないようになっています。
そうするとですね、その殺虫剤を作っていた会社はさらに改良して、
その耐性を持った虫にも対応できるような新しい殺虫剤を作ると。
そうするとその新しい殺虫剤にも耐性を持っている虫が生き延びてそのまま繁殖する。
そうするとまたその耐性を持った虫が繁殖して多くなった時にもそれにも対応する殺虫剤を作るみたいに、そういうふうに考えています。
これが殺虫剤のパラドクスですね。
殺虫剤をどんどん作ったとしてもそれを耐性するものが出てくるみたいなそういう感じなんですけれども、
そこからちょっと取っていまして、毎回同じテストを繰り返すとそのテストで見つかるものは欠陥として取り除くことができるけれども、
新しい欠陥っていうのが発見しづらくなっていくっていうところになります。
この原則をちゃんと理解をしておかないとですね、こういうふうに考えたりする方が周りにいないですかね。
このプロダクトに関してはどういう新しい機能を作ったとしても、
このテストさえちゃんと通せば大丈夫だよとか、毎回同じテストをやって、それをもってリリースをしようと。
他は大丈夫、その同じテストをやればいいからみたいになっているところとかないですかね。
それはまさにこのテストの弱化に陥っている可能性があって、新しい欠陥を発見できなくなる状態なんだけれども、
それは欠陥として見つかってないので、じゃあこのままいこうかみたいになっている可能性があるんですよね。
なのでテストをしようと思った以外の部分の欠陥を見逃している状態になるので、
常に新しい機能とか開発するたびに、それに対するテストってどういうのが必要かって考え続けることが何よりも大事なんですね。
続いて7原則の6番目にいきます。
原則6：テストはコンテキスト次第
テストはコンテキスト次第という言葉です。
これは何かというと、ソフトウェアの種類によってテスト次第内容とかテストにかけるコストというのが変わってきます。
例えば人名に関わる製品とゲーム製品では同じ品質やテストの構成にはならないはずですよという話です。
何言っているかというと、例えば皆さんスマホでゲームとかやったりしますかね。
スマホゲームとかやっていたりして、ゲームの中でバグが起きてしまったときには、
最悪、すいませんこういうところでバグが出てしまったので、
そのお詫びとしてゲーム内で使える通貨をプレゼントしますみたいな、いわゆる詫び石みたいな形ですね。
そういうのでお詫びにして済ませる可能性はありますと。
一方で人名に関わる製品、例えば医療製品であったりとか、
そういうところで不具合が起きちゃいました、その結果人が死にましたとか、
そういうふうになってしまうと、すごい困りますよね。
なのでそういう人名に関わる製品というのは、少なくともゲーム製品に比べたら、
いっぱいテストとかをして、工数をかけてでもちゃんと動くというものを保証するというふうに動くと思います。
同じ製品であっても、やっぱりコンテキスト次第でいろいろ変わってくるかなと思います。
例えば先ほどのゲーム製品とかであっても、
例えば画面上のレイアウトが少し崩れてしまっているとか、
そういうところの話と、実際に課金の部分、有料のお金が関わる部分で、
例えば二重に課金されてしまうみたいな、
そういうところはやっぱり重要視したいところですよね。
同じ製品であっても、バグが起きたらまずいようなところっていうのを考えて、
どこにコストをかけるべきなのかっていうのを見極めるっていうのが大事ですよ、
っていうのがこのテストはコンテキストしたいという話につながるかなと思っています。
原則7：「欠陥ゼロ」の落とし穴
最後ですね、欠陥ゼロの落とし穴ということで、
これは必ずしも欠陥がないという報告イコール素晴らしいという話ではないですっていうことです。
これ何かっていうと、例えばプロダクトがテストをしてバグが一件も見つかってなかったですって言われたら、
これって本当に大丈夫かなと。バグは一つもないんだけれども、
そのシステムの起動に5時間かかるようなシステムは実は使いたくないですみたいに言うかもしれません。
ある意味起動に5時間かかるようなシステム自体がバグだっていうふうに捉えることもできると思うんですけれども、
そういうふうに欠陥が一つも報告されてないっていうことは必ずしも素晴らしいという話ではないですよという話です。
他にも以前とある会社の記者会見、謝罪会見の中で会社の代表の方が言っていた話があります。
この記者会見というのはですね、
セキュリティのインシデントを発生させてしまって、個人情報の流出かなんかが起きたときの記者会見でですね、会社の代表、社長がですね、
わが社はセキュリティの専門会社にチェックをしてもらっていて、そこで大丈夫だったんで、
わが社のシステムとしては大丈夫ですみたいな言い方をしてしまっていたんですね。
それはまさに欠陥ゼロの落とし穴にはまっていることであって、
セキュリティ会社にチェックしてもらって、それで一つも見つからなかったイコールセキュリティは万全だっていう話ではないですよ。
落とし穴に落ちる可能性はあるという話になります。
あともう一つここでお伝えしたいものがあって、
例えばリリースの前日までにバグが一つだけ見つかったときに、その一つのバグを直すべきなのかっていうところ。
これも状況によって違うかなと思います。
これは修正することでバグがゼロになる、欠陥がゼロになる。
だからそれに向かっていこうって思うかもしれませんが、
修正することでプログラムの変更が発生して、新たな欠陥を引き起こすリスクもあるかなと思います。
これもある意味、欠陥ゼロの落とし穴っていうところになるかなと思っています。
ということで、テストの7原則の後編として、
今日はテストの原則5、6、7ですね。
テストの弱化、テストはコンテキスト次第、そして欠陥ゼロの落とし穴の3つを紹介しました。
質問コーナー：テスト待ちの解消
それではここから質問コーナーです。
これも以前にイベントでいただいた質問をそのまんま持ってきました。
テスト待ちを解消したなと思った瞬間はどんな時ですか?という質問をいただいています。
ありがとうございます。
テスト待ちというのはおそらくですけれども、開発は開発者は開発を終わらせました。
ただしテストが終わっていないからリリースができませんよ、みたいな、そういう状態を指すかなと思っています。
テスト待ちっていうのを、そもそもそういう風な考え方を持つにしない、
QAエンジニアがテストするのに時間がかかっているからリリースができないという状況を作り出さないというのがまずは大事かなと思うんですけれども、
仮にそういう風な組織だったとして、やっぱり解消したなと思うところで言うと、
事前に開発が終わる前までに、テストが実際に始まる前までに、こういうところは危ないよね、みたいな、
そういうのを事前に共有をしておいて、
ここはバグが起こりやすそうだなと思いながら開発に実装してもらって、注意深く実装してもらって、
その結果、QAエンジニアがテストをやるとなった時に、バグ脱出をするというよりもここは大丈夫だよねっていうのを確認でやっても大丈夫だったという風になる。
これがテスト待ちを解消するという状態になるかなと思います。
解消したなと思った瞬間って言うとどうか分からないですけれども、
自分がよく指標というか考えているものとしては、テストの実行自体はもちろん動くものがないとできないので、
開発実装が終わった後にやることになるんですけれども、少なくともテスト設計の部分はですね、
ものができてからじゃないとできないっていう話ではないので、開発が実装が終わる前、
もしくはもっと極端なことを言ってしまえば、実装が始まる前の段階でテスト設計をある程度終わらせておくというのが、
テスト待ちを解消したなっていう風に思える瞬間かなと思っています。
ということで質問ありがとうございました。
エンディングと次回予告
ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想は、ハッシュタグBテスティングでXのポストをお願いいたします。
今回の話で言えばですね、テストの7原則の後半を話していきました。
特に最後の欠陥ゼロの落とし穴とかは、
実際の謝罪会見とかでも経営者の方があまり意識できてなかったなと思えることとかもあったので、
自分のところの経営層、ここ意識してなかったかもなとか、
そういうような感想をいただけると嬉しいなと思います。
もしもこれからも聞きたいという方は、お手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がった時にすぐに気づけます。
このテストの7原則の話は今日で一旦おしまいになって、
次回になるかわからないですけど、またテスト設計技法の話に戻っていこうかなと思うんですけれども、
そういう新しいエピソードにもすぐに気づけると思いますので、ぜひ番組のフォローお願いします。
ということで今回はここまでです。それではまた次回。バイバイ。