オープニングと今回のテーマ紹介
皆さん、こんにちは。B-Testingのブロッコリーです。このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
オープニングは、先日3月3日にNewbeeさんのところでお話をしてきました。動画出演をしてきました。
ここに書いている通り、AI時代の品質保証最前線ということで、品質保証のトップランナーというふうな肩書きで書いていただいていて、大変恐縮なんですけれども、
主にAIとQAに関する話を1時間弱話してきました。今、YouTube上に公開しているので、ぜひ気になる方は見てほしいなと思います。
実際に、動画を本当に収録場所に行って、来たら話しましょうか、みたいな感じで、激手のHachiさんとデブサミのとき、一緒に登壇していたので、ある程度気心を知れているという感じで、
事前にこういう話をしようというのは、オンライン上で擦り合わせはしてきたんですけど、こういうふうにすぐ収録に入るんだというふうなのがちょっとなるほどと思いました。
今日は、テスト設計とテスト設計技法について話していきたいなと思います。ということで、今回もbtesting.fmスタートです。
今日はテスト設計とテスト設計技法についてちょっとしゃべっていきます。ついにテスト設計というところに入っていきます。
テスト設計の必要性：全数テストの不可能性
そもそもテスト設計というのがどうして必要なのか。このPodcastの中でも何回かテスト設計という言葉が出てきたと思うんですけれども、
テストプロセスの中にもテスト設計というものがありますけれども、どうして必要なのかというと、テストの原則1番ですね。
テストは欠陥があることは示せるが、欠陥がないことは示せないとか、あとはテストの原則2番ですね。全数テストは不可能とかありますよね。
なので、テストケースって時間があれば無限にやりたいことっていっぱい出てくるわけですよ。一方で現実的には時間制約があるわけですよね。
いついつまでにやらなくちゃいけないとかっていうふうになるので、その中で効果的なテスト、もしくは効率的なテストをするためにテスト設計っていうのを行っていく必要があります。
テストにおける「効果」と「効率」の定義
ここで言う効果的と効率的っていう話、何かっていうところは、これは鈴木一さんが若手の中で発表していただいたスライドですね。
テスト設計技法をちょっと俯瞰してみようというスライドがあります。
ぜひスライドの内容、全体的にすごいいいスライドなので、ぜひ見てもらいたいなと思うんですが、その中で効果的と効率的について書かれていました。
まず効果的なテストっていうのは何かっていうと、できるだけ多くのバグを検出できること。
それからどれだけバグを見逃さずに済むかとか、ある程度の基準を設けて網羅的に見逃さずに多くのバグを見つけられるかっていうところが効果的なもの。
一方で効率的っていうのは時間の話も関わってくるわけですね。
かけた時間に対して検出するバグっていうのが多いっていうことですね。
重要なバグ、ここちょっとバグが出そうだなっていうところを集中的に確認する。
そうすることによって別に全体的に網羅的にバグを見つけているわけではないんだけれども、バグがすごい見つかりやすいっていう状況を作るっていうのが効率的と呼んでいました。
この効果的もしくは効率的を狙いとしてテストを考えてみる。
テストのパターンとかを考えてみるっていうのがテスト設計であって、それをやるために使う方法をテスト設計技法と呼んでいるのかなと思っています。
テスト設計技法による「省思考」の実現
このテスト設計技法、どうして実際に用いるといいのかなっていう話に移るんですけれども、
このテスト設計技法を用いることで小思考をする。思考を短縮できるっていうところがあります。
特にこれは現代品質管理総論という書籍の中に書かれている文言ですね。
まずちょっと引用して読み上げますけれども、標準化という話を言っています。標準化の目的は統一、単純化にあると。
標準の活用は知識の再利用、経験の有効活用、小思考と言える。
改めて計画する必要なくし、その分を独創的な仕事に振り向けるべきであるというふうに書かれているんですね。
よく標準化とか標準という言葉をネガティブなイメージを持っている方とかいたりするんですよね。
標準に合わせてやるためにはこういうのを書かなくちゃいけないとか、そういうふうに思ったりする方もいるかもしれないんですが、
そうではなくて標準というのはある程度決められているものにすることによって、小思考を省略できるっていうのがあります。
スライドを見えている方には信号機をちょっと載せましたけれども、
信号機って必ず横の場合だと左から順番に青、黄色、赤の順番ですよね。
ここの順番とか色を何にしようかって考える必要がないわけですよね。
信号機っていうのはそういうもんだからと。
その上でじゃあここの信号機を作るにあたって、信号機のライトの大きさであったりとか、
もしくは例えば雪が多く降るからこのライトの上の日差しの部分をどういうふうにしようとかっていう話に注力して考えることができるわけですよね。
何も最初から左から何色にしようかって考える必要がないわけですよね。
これが標準にすることのメリットだし、そこの部分の思考を省略できるっていうものがあります。
ちょっと回り道になってしまいましたが、この標準っていうところの一つとしてテスト設計技法っていうものがあると思うんですね。
なのでテスト設計技法っていうものをある程度標準的なものを習得することによって、
自分が今回やった場合でも次回やった場合でもいちいち最初から考えようではなくて、これは技法を使えばこういうふうにできますよねみたいに
そこの書き方とか書きっぷりに関しては思考を省略することができるはずだと。
そうすることによって他の部分に時間をかけるっていうことができるかなと思っています。
テスト設計技法の学習順序
そんなテスト設計技法についてなんですけれども、いろいろとあります。
いろいろとあるし、その中には知っておくべき順が個人的にはあるかなと思っています。
まず一番何よりも土台基礎となるのがテスト設計技法の中でも同時分割法というものがあります。
同時分割があります。
それに対して境界値分析やディシジョンテーブルや状態遷移テストと呼ばれるようなもの。
これを一応基本とおきましたが、これはJSTQBのシラバスでいうファンダメーションレベルに書いてあるものですね。
そこから先のものとしてJSTQBのアドバンストレベルのテストアナリストのところに、
例えばクラシケーションツリー技法であったりとか、ペアワイズのテストであったりとか、
ユースケースのテストとか、もしくは直行表とかもあるかもしれません。
直行表はよく使われやすいんですけれども、そもそも直行表をちゃんと理解するためには
同時分割とかそういうところもきちんと理解しておく必要があるかなと思っています。
標準化をすることによって、これ直行表を使えばいいんでしょうとかっていうふうになりがちだけれども、
本当にそれを使うべきなのかとかっていうのは、ちゃんと精査をしなくなってしまう可能性があるんですよね。
なので、ちゃんと基礎の部分から知っておいていく必要があるかなと思っています。
質問コーナー：開発経験、テスト観点、技法の使い分け
ということで、今回はこのテスト設計とテスト設計技法について語っていきました。
おそらく次以降のPodcastのエピソードの中で、実際のテスト設計技法についてもちょっと詳しく語っていきたいと思いますので、
次回以降もお楽しみにしてください。
今回も質問コーナーです。一つ質問を答えていきたいなと思います。
ここはユニットテストでやりましょうよ。
もう言えるし、テスト観点も洗い出せるし、技法も使い分けられるようになるまでの道のりを聞いてみたいですと。
開発経験は必須になっていくのでしょうか?という質問ですね。
ありがとうございます。
まず最後のところですね。開発経験が必須かどうかに関しては、やりに越したことはないですが、
個人的には開発経験が必須とは思っていません。
特に今日お話ししたテスト設計技法ですね。
載せていたような同時分割法とか境界値分析とかディシオンテーブル状態遷移テストとか、
そういうところはいわゆるブラックボックステスト技法と呼ばれたりします。
それは何かっていうと、開発がとかコードの中身がっていう話ではなくて、
そもそも仕様としてとか、そういう実装されるコードを見ないでもちゃんと組み立てられるようなテスト設計技法になってるし、
むしろそここそQAエンジニアとかテストエンジニアで必要になってくる部分かなと思っています。
なので開発経験の必須かどうかっていうのは別に必須ではないかなと思っています。
あとはテスト観点を洗い出すとかっていうところは結構そのドメインの知識とかにもよるとは思うんですけれども、
それ以外にも物事の抽象化と具体化をちゃんと行き来がうまくできるとかっていうのも重要になってくるかなと思います。
それも今後のエピソードで話せればいいかなと思っています。
技法の使い分けに関してはもうこれは経験がものを言うところではあると思うんですが、
まずはただその経験の前に基礎の部分としてちゃんと技法を理解するっていう必要があります。
その上でこの場合はこの技法を使い分ける。
ここだったらこれを使えばいいんだっていうのをきちんと理解していく。
そこは経験が必要だなと思っています。
これに関して言うと、例えば数学の高校受験とかそういうのをちょっと思い出してほしいんですけれども、
例えば高校受験って中学3年間、小学校の算数の頃も含めてそこで学んだ内容を使って高校受験って臨みますよね。
その中で中学でいろいろなものを学びました。
1次関数とか2次関数とかあとは二次方程式とか解の公式とかいろいろ学んでくる中で、
そこに出てきた公式とかを全部覚えたら必ず高校受験って100点取れるとかっていうとそうではないと思うんですよね。
この問題があってこの問題を解くためにはっていうのを考えたときに、
今まで覚えてきた公式の中の、じゃあこれ二次方程式の話だな、これ因数分解で解けそうか解けなさそうだということは解の公式使ったほうがいいな、
だから解の公式を使ってっていうふうになると思うんですね。
つまり出てきた課題に対して、それはこれを使えばいいんだっていうのをやっていく必要がありますと。
これは受験勉強とかもそうですけれども、数で慣れる部分っていうのが正直あると思うんですよね。
なのでそれは普段の業務の中でテスト設計技法をまず使ってみると、
その結果うまくいかなかったとかっていうのも経験ではあると思うのでやってみるっていうのがありますし、
それ以外にもいろいろと今書籍が出ています。
数をこなす、いろいろ練習するっていう意味だとソフトウェアテスト技法練習帳という書籍があります。
それで数を慣れて、こういうふうに使えばいいんだっていうのを学んでいくことが大事かなと思っています。
ということで今日の質問の回答は以上になります。
エンディングとリスナーへの呼びかけ
質問いただきありがとうございました。
ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、
どんなことでも構いません。
統合フォームは番組概要欄にあります。
またエピソードの感想は、
ハッシュタグBテスティングでXのポストをお願いいたします。
今日の話で言えばですね、
テスト設計技法、自分普段使ってるよとか、
実はあんまり使ってないよみたいなそういう反応とかもらえると嬉しいですし、
それ以外にも今日オープニングで話したですね、
YouTubeのみゅうびさんの動画、見たよとか、
そういう感想も送ってもらえると嬉しいなと思っています。
もしもこれからも聞きたいという方は、
お手持ちのPodcastアプリで番組のフォローもお願いいたします。
最新回が上がった時にはすぐ気づけると思います。
特に今回からテスト設計技法っていう話を進めていく中で、
次回以降も動地分割から始まって境界値分析とか、
どんどん続いていくと思いますので、
それが出てきた瞬間にすぐ気づけると思いますので、
ぜひフォローもよろしくお願いします。
ということで今回はここまでです。
それではまた次回。バイバイ。
おやすみなさい。
