オープニングと番組紹介
皆さん、こんにちは。B-Testing のブロッコリーです。この B-Testing.fm は、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
ポッドキャストの収録っていうところに関しての、今日は最初話そうかなと思うんですけれども、実は自分2年前ですかね、2024年はポッドキャストの収録もそれなりにやっていました。
去年2025年は収録をほとんどやらなかったんですね。そんな中、今年2026年に入って、1月からこのポッドキャスト、B-Testing.fmを始めているわけですけれども、今一応この週1回という公開ペースを維持して続けていきたいなとは思っています。
というか、もう若干週に、木曜日にも出したりすることが多くなっているっていうのが正直なところなんですけれども。最初は音声のみにしようかなと思っていたんですけれども、スライドの文字情報を載せたビデオポッドキャストは、これそのまま続けていこうかなと思っています。
ただし、聞きながら、例えば他の作業をやって耳だけ聞いていただいているっていう人もいるかと思いますので、できるだけ音声だけでも理解できるように、そんな話っぽりを目指していきたいなと思います。
そんな中、今日のやつは結構スライドの文字情報もあったりするので、なかなか伝えるのは大変かもしれないですが、やっていきたいと思います。ということで、今回もB-Testing.fmスタートです。
実装前のテスト・レビューの重要性（復習）
今日のテーマは何をテストすべきかという話なんですけれども、その話をする前に、何でそういう実装前にテストレビューをするのかっていうのは、以前話したことがあったと思うんですけれども、それを復習的にちらっと話しておきます。
早い段階で欠陥を発見して修正するっていうことで、総コストを削減できるっていうお話を以前したことがあります。
実際にテストっていうのが実装が終わった後にテストするんじゃなくて、その実装の前にテストのことを考えておくよっていう、そういうのがすごい高数の削減にもつながる良いことだよっていうお話をしたと思うんですけれども、
この考え方を持つときに重要なのは、今日のテーマでもある何をテストすべきかという話なんですね。
パスワード仕様からテスト内容を考える（例題）
何をテストすべきかっていうところに対して、一つ具体的な例を持ってきました。
こんな仕様がありますと、パスワードは4文字以上12文字以下のA数字のみを許容する。
パスワードを3分以内に4回以上間違って入力するとアカウントを5分間ロックする。
こんな仕様があったときに、これに対してどんなテストをしたほうがいいのかなとか、こんなところ気になるなとか、こんなバグ起こりそうじゃないかなっていうのを皆さんぜひ考えてみてほしいなと思います。
できたら一時停止してもらうなりして、この仕様に対して何をテストすべきかっていうところをぜひ考えてほしいなと思います。
実際にこれを考えた結果、例えばこういうことが思い浮かぶんじゃないかなと思います。
例えばパスワードは4文字以上12文字以下のA数字のみを許容するっていうところでいえば、4文字以上12文字以下みたいな文字数、文字列の長さとかはお気になったかもしれません。
あとはA数字のみっていう文字の種類とか気になったかもしれません。
今回ここでいうと4文字以上12文字以下っていうところに対して、じゃあ4文字のパターン気になるよねとか12文字のパターン気になるよねとか、
あと境界値分析っていう話を聞いたことがある方は3文字とか13文字気になるよねみたいな、そういうことを具体的なテストのパターンとかも考えた方もいるかもしれません。
それ詳しくそういうふうに考えているのもすごいいいとは思うんですけれども、別にそれを間違えというつもりはないんですが、それをそのもっとざっくりとしたもの、これ気になるなみたいな、そういうものとしてこの文字列の長さとか文字数とかっていうふうなことを気にするかなと思います。
これが何をテストすべきかっていうところの話ですね。
他にもこれ気になるところっていろいろあるわけですよ。
例えばパスワードを3分以内に4回以上間違って入力するとって書いてあるところで言うと、3分以内にっていう誤った入力を行う期間の話を気になった方がいれば、4回っていう入力の回数を気にするテスト、そこをテストしたほうがいいよねって考えてる人もいるかもしれません。
あとはアカウントを5分間ロックするっていう話に対して、このロックっていうステータスの繊維っていうのを気にした人もいれば、あとはそれがロックの保持期間として5分間みたいな、そういうところを気にした方もいるかなと思います。
ここらへんっていうのは大体仕様の中に書いてあって、これ気になるよねっていうところがよく出てくる話かなと思います。
仕様の曖昧さと潜在的なバグ
これで全部かというとそうではないかなと思っています。
そうすると、例えばこの中で言うと、この許容するっていう言葉、この4文字以上12文字以下のA数字のみを許容するっていう言葉、これ許容しないとどうなるんですかね。
例えばパスワード15文字とか入れたとき、これ会員登録画面なのか、それもよく分かってないところであるんですけれども、例えば15文字とか入れたときに会員登録するっていうボタンがそもそも押せない非活性の状態になっているみたいなボタン制御がされているのか、それとも15文字とか入れても登録を試すことはできる。
ボタンを押せるんだけれども、その結果パスワードが流すぎますみたいなメッセージが出てくるとか、エラー画面に映っちゃうみたいなそういうふうなこと、どういう状態になるんですかね。結構曖昧ですよね。
あとはこのパスワード3分以内に4回以上って言ってますけれども、以上っていうところに注目してもらって、例えば1分間にもう4回間違えました。じゃあその次の5回目の入力ってどうなるかっていうと、いやもう4回以上間違ってばロックされるんじゃないのって思う人もいれば、いやいやいや、まだパスワード3分以内に試せるって書いてあるんだから、
別にその3分の中だったら何回でも試していいでしょう。5回目の入力も受け付けるでしょうって思う人もいるかもしれません。結構ここ曖昧ですよね。それ以外にも曖昧な場所、曖昧というか気になるところっていろいろあるかなと思います。
例えばそもそもパスワードって言っているので、そこのパスワード入力した文字の表示っていうのが米印のマスクされた状態でちゃんと表示されてるよねとか。あとは例えば最初の1分の中でパスワードを間違えて失敗して失敗して失敗して成功してログインができて、
そのままログアウトして失敗。これを例えば1分で行ったときっていうのはロックされちゃうんですかね。1回成功してますけど。これどうなんだろうなとか気になるかなと思います。
これ実はこのお題、自分いつもよく使ってるお題でして、もう過去何十回とやってるんですけれども、いろいろなカンファレンス勉強会でやってるんですけど、毎回新しい、なるほどそういうテストも確かに必要かもねみたいなのが出てきます。
前というか去年か一昨年かにあったもので言うと、例えば23時58分にロックがされましたと。そのまま5分経過経つんだけれども、とある海外の国でそれをやっていてロックされたとして、その日付が変わったときにちょうどサマータイムが発生して1時間ずれる。
ということになったっていったときに、それがロックされたまんまになるの。それも含めて5分間って取れるのかみたいな話が、前聴講者から話がありました。確かになるほどなーって思った例ではあります。
開発者の思い込みと追加コスト
こういうふうにいろいろと考えられるんですよね。ここで重要なのは、例えばさっきの許容するかどうかっていう話で言うと、設計とか開発時点でこの許容するっていうところに対して、AさんはBさんがエラー画面担当でいろいろ開発してるっていう。
これチームで開発してるっていう先手ですけど、そうするとこれBさんがエラー画面作ってくれるだろうって思い込んでました。一方でBさんはこれAさんがエラーをボタン制御でやるだろうと。じゃあ自分は他のエラー画面作っていればいいよねって思っていたとします。
このまま開発終わっちゃったらどうなりますかね。実際にテストをするっていう段階で、AさんはいやいやBさんなんでエラー画面作ってないのと、Bさんはいやいやここボタン制御でエラーが管理してると思ったよみたいな言い合いになったりするかもしれません。言い合いになったところで何も解決しないですよね。
そうするとここの部分っていうのは不具合としてやっていろいろと追加のコストが発生しちゃうわけですよね。不具合としてチケットを起票するのもコストだし、開発内容を思い出すのもコストです。
例えば1週間前にそれ開発が終わっていたとしたら、あれ1週間前の自分どういう開発してたっけって思い出すのもちょっとコストがかかるし、もちろん修正もコストがかかります。
さらに修正して終わりではなくて、もう一度テストするのもコストですよね。さらにじゃあそこのパスワードの部分、不具合としてうまく動いてないっていうふうに見つけて、そこをもう一回テストしたら終わりかというとそうではなくて、関連しそうな部分にデグレードがないか確認するっていうところもコストとして発生します。
例えば今回のパスワードの部分でいえば、会員登録の部分だけではなくて、じゃあ同じようにパスワードの登録がかかるような、例えばパスワードを忘れた方はこちらみたいな、そういう画面のほうでももしかしたら確認が必要になってくるかもしれません。
もちろんそれはそういうテストした内容とかも記録して、不具合のチケットをちゃんと完了にするのもコストになる。こういうふうに追加のコストっていろいろ発生するわけですよね。
コードを書かないテストの価値
今回この事例からお伝えしたいこととして、今いろいろな話をしてきましたけれども、実は今回皆さんに考えてもらったお題っていうのは、一文字もプログラム書いてないですよね。
イフ文がどうこうとか書いてないですよね。けど皆さん何テストすればいいんだろうっていうことを考えられたわけですよね。
これがまさに以前のエピソードでも話しましたけれども、テストの目的のときに話しましたけれども、実装する前にテストって考えられるんだよ。
あと今日の最初の復習のスライドで見せたような、実装する前の設計の段階でいろいろとテストしてコストを下げようみたいな話はしたと思うんですけど、それがまさに実現できている事例かなと思っています。
もしもこの時点、この仕様を見てどういうテストをやればいいんだろうっていうところで指摘できれば、総コストって削減できると思うんですよね。
今回の場合、パスワード15文字とか文字数が多い場合ってどうするっていう話し合いをして、ここはエラー画面作りましょうみたいなそういう話を実装の前にしておくわけですよ。
そうするとここテストしますねって予告していたとしても、ほぼ不具合発生しないんですよ。
なんでかっていうと、その設計の段階、実装の前の段階の話し合っているところで文字数が多かった時はちゃんとエラー画面を作ろうかみたいな話をしたなと思いながら開発や実装するので、
その時点で文字数が多かった時にエラー画面を出すを忘れているみたいなことがほぼ発生しないので、事前に考えていた部分に対しての不具合っていうのはほぼ発生しないっていうのが言えるかなと思っています。
これが今回一番伝えたいことかなと思います。
ということで何をテストすべきかっていう話、具体的に何をテストすべきかってこういうテクニックがあるよっていう話を今回は実はしたかったのではなくて、そもそも何をテストすべきかって考えるタイミングですね。
っていうのが実はもしかしたら皆さんが思っている以上に早い段階、プログラム一文字も書いてない段階でこういうふうなことが考えられるよっていうのを今回お伝えしたかったかなと思っています。
お便り紹介：AI時代のQAと相性
ここからはまたちょっとお便りというかコメントいただいてたものに対してのコメント返しを一つにしようかなと思っています。
今回はですね、前回QAのスポーティファイでのやっている番組っていうのは自分ともう一つテストウフキャストぐらいかなっていうお話をしたとは思うんですけれども、
そのテストウフキャストをやっている伊藤芳樹さんから感想のポストをいただいています。
第6回のエピソードのときですね、自分がテストウフキャストのエピソードをもとにしゃべった回のことに対しての話で、テストウフキャストを言及してくださってありがとうと。
ブロッコリーさん視点でAI時代のQAについて考えられていて、個人的に納得感があった。特に相性のあたりっていう感想ポストをいただきました。
ありがとうございます。やっぱりこのAI時代のQAっていうところの相性、AIという品質保証っていうのは相性がやっぱり良くないっていう話を第6回ではしたと思うんですけれども、
そんなにそのエピソードを話した回から1ヶ月以上空いてはいますけれども、その感覚はやっぱりAIが進化していっても今のところあんまりその感覚が変わってなくて、
やっぱり何をもって正しいと考えるのかっていうのを追求するQA、品質保証との相性の悪さっていうのはやっぱりあるなっていうのはすごい思っているところです。
ということでコメントいただいてありがとうございます。
ただ第6回でしゃべったことをもう1回繰り返したような話になってしまいましたが、ぜひ感想のコメント他にもあればもらえると嬉しいです。ありがとうございました。
エンディングとリスナーへの呼びかけ
ではエンディングです。
btesting.fmはリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想は、ハッシュタグbtestingでxのポストをお願いいたします。
今日も1つポストを紹介しましたが、いただいたポストはもう大切にというか、もちろん読みます。
自分の中で読みますし、それをこういうエピソード、ポッドキャストのエピソード放送の中でも紹介したいなと思っています。
もしもこれからも聞きたいという方は、お手持ちのポッドキャストアプリで番組のフォローもお願いします。
最新回が上がったときにすぐ気づけるようになっていると思います。
特に今回の何をテストすべきかっていう話を含めて、
結構テストに対しての、今普段発表とかしているものからちょっと切り出してこのエピソードとして載せていっているんですけれども、
やっぱり切り出している分、何回も何回もいろいろ続きものみたいな感じで話していく中で、
こういうことなのかって理解してもらえることになるかなと思いますので、
ぜひ番組フォローしていただいて、最新回が上がったたびに聞いてもらえると嬉しいかなと思っています。
ということで今回はここまでです。それではまた次回。バイバイ。
