00:07
皆さん、こんにちは。B-Testingのブロッコリーです。このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを約10分間で語っていくポッドキャスト番組です。
今日のオープニングはですね、最近このポッドキャストをどういうふうな話をしていこうかなっていうところについてなんですけれども、結構自分の中である程度先の回まで話すテーマって決めているんですけれども、その中で結構余談とか雑談とかそういう回も結果的に増えていっているかなと思っています。
で、前回の放送のエンディングでも話したんですけれども、結構配信サイクルも毎週月曜って言っておきながら、結構木曜にも配信することが多くなっていっているかなと思います。
なので、なかなかテーマが進まないなと思っていて、なので本当は多分テストの話っていうと結構テスト設計について気になる方が多いかなとは思うんですけれども、テスト設計について話すのはもう春先、もっと先かな、随分先になっちゃうかなと思っています。
今回はそんな中で、そういう雑談会に近い話かもしれないですけれども、とあるブログ記事を取り上げて、それに対する自分の考えも話していきたいなと思います。ということで、今回もbtesting.fmスタートです。
今日はですね、とあるブログ記事を取り上げてということなんですけれども、この失敗の許容度を設計に組み込むというブログ記事、これを読んですごい自分は個人的には共感をしたので、それについて紹介しつつ、自分が共感したところを中心に話していきたいなと思います。
この記事は何かというと、マックスさんという方が書かれた記事ですね。どういう話かというと、AIを用いてテスト設計をするにあたって、どういうスタンスで品質やテストのことを考えればいいのか語っている、すごいいい記事だなと思っています。
AIとQAとかテストっていう話でいうと、2つの文脈が結構あります。何かっていうと、AI for QAっていう話。何かっていうと、QAとかテストをやるにあたってAIを使うっていう話と、QA forAI。
AIを使っているプロダクトをテストするときにどうすればいいかっていう話。2つの話があるんですけれども、今回のこのマックスさんの記事はどちらかというと、AI for QAの文脈ですね。QAのためにどうAIを使っていけばいいかっていう、その文脈で書かれている記事だなと思っています。
03:03
いくつか共感したトピックを紹介していこうと思うんですけれども、まず1つ目がですね、私たちは失敗しないように品質の高いものを作ろうと意識するのではなくて、品質の低い状態を最速で検知し修正できるシステムを設計すべきということなのですっていうふうに書かれていて、これはまさにそうだなと思っていて、
特に昔のようなリリースが最後というか、1回リリースしてそれを使い続けるのが製品だよみたいな形になってしまうと、リリースのときの品質が一番高いものになっているっていう前提になるので、かつ1回リリースしちゃったらそれの修正ができないとかっていうふうな形になってしまうと、失敗いかにしないようにっていうふうに意識になるとは思うんですけれども、
特に最近のSaaSであったりとかそういうもので言うと、リリースし続ける、何回もリリースし続けるっていうふうになっていくので、そうすると品質が最高、すごいコストをかけてまで品質を高くするっていう話ではないんだけれども、リリースをしますと。
ただ、その結果うまくいかなかったときっていうのを最速で検知しようと。だからすぐ修正できるよっていう、この考え方ってすごいいいなと思っています。なので、これは時代変化じゃないですけど、作っているものによっても変わってくるかなと思っています。
その上で、これも記事内で書いてあった話なんですけれども、テストの品質を正解を当てることっていう網羅性とか正確性を定義してしまうと、不確実な実証に直面した際に手が止まっちゃうよと。
追求すべきテストの品質はテストの内容そのものではなくて、テストの間違いを素早く暴き、修正できるプロセスの堅牢さ、復元力にあるのですっていうふうに書かれていて、これもすごい共感しました。
頑張って100パー網羅する。何をもって網羅するって言ってるのかっていう話ではあるんですけれども、頑張って網羅するとか、いかに正確になってしまうと、これ実際にリリースしてみないとわからないよねとか、特に最近のAIを使ったプロダクトとかそうかもしれないですけど、不確実な状況っていうのがあったりします。
また、ちゃんと正しいものをっていうふうにやってしまうと、そもそも仕様とか設計とかがすごいきちんと書かれていて、もうそれどおりにものを作れば絶対それどおりなものができるっていうような完璧に近い仕様書とかっていう前提じゃないと、この網羅できるとか、いかに正確にとか正解を当てるっていうふうなことは作れないと思っていて、
不確実な状況っていうのがあるもんだ、そういう前提に立つのはすごい大事だと思っていて、そのときにすぐにこれちゃんとできてないよねっていうところ、モデル自体の間違いであったりとか、もしかしたらテストもあんまりうまくいってないとかもあるかもしれないですし、
06:10
もしくはテストを作っていく中で、あれ、これってどういうことなんだろう、ちょっと曖昧な部分あるなみたいなのをすぐ気づいて、それをすぐ修正できるっていうところが大事っていうのはまさにそうだなと思っています。
この復元力、素早く暴いて修正できるプロセスの堅牢さ、復元力っていうのに近い話として、また別の資料なんですけれども、これは発表スライドですね。
久市さんという方が発表した、技術力を上げたいというタイトルのスライドの中にこういうふうに書いてあります。プロダクト開発とか運用っていうのは何かっていうと、訂正し続けることだと思うっていうふうに書いているんですね。
訂正し続けるっていうのは経験学習サイクルを回し続けるといってもいいと。これも自分は非常に共感をしていて、ちゃんと正しいものをリリースするっていうことよりかは、ちゃんとそれを運用することによって、これは別にQAであっても開発であっても、リリースしたものが100パー絶対正しいって言い切れないと思っていて、
特にそれを実際に運用している人にとっては、これやりづらいよとか分かりづらいよとか、これよくないよっていう部分が絶対出てくる前提に立ったほうがいいと思っていて、そのときに訂正をし続けるっていうことにつながると思うんですね。
なので、こういうもの使用通り作ったからいいじゃないかではなくて、運用も見据えて考える。訂正し続ける。先ほどのMaxさんの記事で言う復元をする、復元力っていうところ。こういうところはすごい重要な話になってくるかなと思っています。
あともう一つMaxさんの記事内で共感したものとして、テスト実施っていうのは何かっていうと、ただテストを実行するっていう話だけではなくて、テスト設計という名の仮説を検証する一面を持ったアクティビティであると捉え直すことができます。
AIにテスト設計を任せるとしたら、そのAIの仮説と現実の挙動との間に生じるギャップを意図的に明らかにすることで、使用書には記述されていない隠れたエッジケースや人間側の考慮漏れを能動的に炙り出すことができるかもしれないのですと書かれていて、ここも非常に自分は共感をしています。
特にQAエンジニアとかでテスト設計が得意な人、もしくはテスト設計にすごい経験年数がある人っていうのは、一見するとテスト設計で作ったものが絶対正しい、それどおりに言ってないのは全部良くないみたいに思うような人ももしかしたらいるかもしれないですが、そうではなくてテスト設計っていうのはあくまでも自分が想定した仮説である。
09:02
それとの答え合わせをするためにテスト実施があるよっていう話を書かれていて、いやまさにそうだなと思っています。
この後半のAIの仮説であるテスト設計と現実の挙動との間に生じるギャップを明らかにするっていうのも、すごい自分も共感はしているんですけれども。
ただその一つ違うまではいかないんですけれども、加えて言うと自分の場合はAIに仮説としてテスト設計をさせて、それを実際に実施を自分でやってそことのギャップを見るっていう話だけではなくてですね。
そもそもAIに仮説としてテスト設計をやらせて、それとは別に自分もテスト設計をしてみるとか、もしくはAIが作った仮説となるテスト設計を自分がレビューをする立場になって、そうするとAIここうまくできてないなみたいなそういうところが見えてくるんですよね。
それっておそらくAIからしたら、インプットとなる仕様書とかを元に作ったらこういうふうになるんだけどって考えていたことに対して、自分から見るとそれはちょっと違うんだけどっていうのは、これはすなわち仕様書に書かれてない暗黙的な理解をしていたりとか、暗黙的な定義が実はあるみたいなそういうところだと思うんですよね。
人間側の恒例漏れっていう話だけではなくて、そういう暗黙的なところを炙り出すっていうのにも使えるかなと思っています。
ただ概ねここに書いてあるのは非常に共感をしていて、現実とAIのギャップ、仮説っていうののギャップっていうのはすごい自分も注目しているところだなと思っています。
他にもいろいろいいことを書いていたんですけれども、今回はちょっと時間も限りがありますので、その一部を紹介しつつ、自分の共感した部分をずらざらと喋っていきました。
ぜひ気になる方はこの失敗の許容度を設計に組み込むっていう記事を番組の概要欄にもURL貼っておきますので、ぜひそこにアクセスして読んでみてください。
ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストの悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想は、ハッシュタグBテスティング、BアンスコテスティングでXのポストをお願いいたします。
今日の話で言えば、今日紹介した記事ですね。
失敗の許容度を設計に組み込む記事を読んだ感想。
もちろん一番はブログのほうにコメントなり、ブログのURLを貼ってポストしてもらうのが、感想もポストしてもらうのがいいかなと思うんですけど、
12:02
自分はこう考えたよとかっていうのも、ぜひポストなり、もしくは投稿フォームから送ってもらえると嬉しいなと思います。
もしもこれから聞きたいという方は、お手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がった時にすぐ気づけます。
今日のオープニングでも話した通り、最近自分の投稿のペースが速くなったりしているので、
ぜひすぐ気づいてすぐお聞きできると思うので、ぜひフォローお願いします。
ということで今回はここまでです。
それではまた次回。バイバイ。
