E2Eテストの役割と高コスト
ここ2、3日で、くりあきさんのXで、エンドツーエンド関連の話題でちょっとバズってましたよね。
今回ちょっとその話していけたらなと思ってるんですけど。 はい、そうですね。2つ、まあでもどっちもエンドツーエンドテストに関わる話で、
1つは、エンドツーエンドテストを全振りしている人の話でしたね。 全振りしているっていうことが別にいいんじゃないかっていうふうな話っていうのが1つと、
もう1つは私の持論で、エンドツーエンドテストの立ち位置、どこなのかとか、どういうふうにしてテストの設計をしていくべきなのかみたいな、そういうふうな2つのツイートがそれなりに好評いただいたみたいですね。
はい、じゃあ今回ちょっとその話していけたらなというのと、まずはあれですね、エンドツーエンドテストを全部寄せた方がいいんじゃないかっていう主張に対して、
まあちょっとそれは違うんじゃないみたいな感じで、国明さんが突っ込んだやつが、まあだいたい今見ると393いいねと、あとは5万インプレッションって言うんですかね。
インプレッションぐらいされてるみたいな、まあちょっとバズってるっていうようなところなんですけど、これについてちょっと説明してもらってもいいですか、詳細。
いや、なんでみんなこんなエンドツーエンドテスト好きなんですかね。 エンドツーエンドテスト好きすぎるなと思ってて、いや私の考えだとエンドツーエンドテストってそんなにいいものではないんですよね。
なので、なんでみんなそんなにエンドツーエンドテストに関心があるのっていうのはちょっとよくわからないっていうところはちょっとあるんですけど、
ちょっとエンドツーエンドテストっていうのがどういう立ち位置なのかっていうのを一度整理したいなと思います。
エンドツーエンドテストは元々は、エンドって一体何かというと端っこですね。端っこ。端っこという端っこってことは、つまりシステムを全部くっつけて、
端っこ、隅から隅まで、要するにユーザーインターフェースからデータベースまで一気通貫でテストをしましょうっていう全てを結合したテストのことをエンドツーエンドテストと呼びます。
今回のツイートの文脈だとさらにこれが自動で行われるエンドツーエンドテストを意図されていることが、本当はマニュアルベースのシステムテストとかシステム統合テストって呼ばれてるのもエンドツーエンドテスト
なんですけど、
それは一旦今回は考えない。マニュアルベースは考えない。自動のものとして想定してくださいと。
人が実行するエンドツーエンドUIのボタンとかを押すんじゃなくてCIとかで実行するようなテストですね。そういうものがあって、よく聞くのはウェブドライバーとか
プレイライトとかっていうのがウェブとかだとよく使われているやつかなと思います。それがよく知られているエンドツーエンドテストだと思います。
このエンドツーエンドテストで見つけられる問題が何かってことをよくちょっと慎重に吟味した方がいいなと思っています。
エンドツーエンドテストで、いくつかエンドツーエンドテストにもバリエーションがあるんですけど、一つはビジュアルリギュレーションテストと呼ばれている
前と比べてスクショが変わってないかと調べるテスト。これは画面崩れた顔を見られるんですけど、
一番最初のサンプルは人間が見ないときで、人間が一個一個写真を見て、これ崩れたね、オッケーオッケーオッケーオッケーってお墨付けを与えると、それからずれてないよねっていうふうなことを与えるテストになる
っていうふうなものもあるんですけど、
でも典型的なビジュアルリギュレーションじゃないテストっていうのは、基本的にボタンが押せるか押せないかとか、
いいとした場所にそういう表示が出てるかとか、その程度のことしか見られないっていうのが普通のエンドツーエンドテストです。
見られるものが少ないってことですかね?
いや、少ないわけではないんだけれども、人間に比べるともちろん少ないです。人間の方が例えばここの言い回しに変であるとか、
あとは例えばここだけ日本語フォントじゃなくて中国フォントが使われてるとかっていうのとか気づくじゃないですか。でもエンドツーエンドテストだと気づかないんで普通は。
そういうところとかはやっぱり人間の方がいい感度を持っている。
なるほど。人間がチェックするときの感度的に、多分今までの経験とかそういったので気づくところが機械的なテストだったらすり抜けちゃうよねっていうところかも。
そうです。じゃあそういうふうに人間のエンドツーエンドテストと比較するとそうなんですけど、他のテスト、例えば結合テストとか単体テストと比べるとどうかっていうことを考えてみると、
基本的に単体テストで見つけられる問題ってエンドツーエンドテストでも見つけられるんですよ。
ちょっとすごく細かい言い回しをすると、他にはいくつか前提はつくんですけど、それはちょっと細かいところ置いといて。
基本的に単体テストで例えば失敗する、例えばある入力を与えると例外が起きてしまうっていうふうな入力がどっかのコンポーネントテストで起こっていたとしても、エンドツーエンドテストで同じようにそこを踏んであげ
れば例外が起きてクラッシュするということをエンドツーエンドテストで確かめられるので、
基本的に単体テストの上位互換なんです。エンドツーエンドテストって。
再現できるってことですね。単体テストで発生するフェイルっていうのはエンドツーエンドテストでも条件揃えられれば発生するよね。
なので検出感度って意味だとエンドツーエンドテストは完全にユニットテストの上位互換なんです。
じゃあなんでみんなエンドツーエンドテストだけにしなかったか、みんな単体テストとかしようとかって言い出したかっていうと、エンドツーエンドテストはコストが高い、本当に高いっていうのが最大の問題点なん
ですね。
ここで言っているコストって、もうちょっと詳しく言うと、2つ言うと保守コストと実行コスト。この2つです。
保守コストっていうのは維持していく。そのテスト、エンドツーエンドのテストが正しいことを保証していくというのがとても大変だというところと、実行コストっていうのは単純に時間ですかね。
実行時間です。そうです。この2つがとってもとっても高いので、エンドツーエンドテストって本当に贅沢品なんですよ。
いっぱい揃えて全部エンドツーエンドテストで回してやるみたいなことっていうのは普通はできないんですね。
無限に時間があって、無限にお金がかけられるんだったらできる。そうできる。そしたらもうユニットテストなんていらんのやっていう話になるんですよ。
理想的にはそうだね。理想的にはそう。だけど実はそうじゃなくて、私たちは有限のコストと有限の時間と有限の保守コスト、保守要因しかいないわけですよ。
なのでどこかで妥協することになるわけですね。私はエンドツーエンドテストだけで1本で行くテストのセットと、単体テストとかいろんなものと組み合わせるセット、どっちの方が同じコストでバグを多く見つけられるか
FizzBuzzで見る結合バグとテスト分担
っていうと、組み合わせた方が多く見つけられると思っています。
その理由を説明していこうかなと思います。まずコンポーネントって結合していくやはしていくほどテストケースが増えていくって話をまずしようと思います。
まず関数が1個あります。こいつは m 通り、n 通り、5通りってあるとします。
5通り。でもう一つは10通りのコンポーネントがあるとします。これをその5通りのやつを呼び出して後に10通りのやつをその出力を使って入力させると何通りになりますか?
5×10ってか50通りですよね。そう50通り。じゃあこれ単体で見た時ってどうなりますか?
単体で見た時は5通りと10通り。15通りですかね。これだけで何が起こっているのかわかりますよね。テストケース数が全然違うんですよ。
爆発的に増えていってしまうっていうのがあって、なので例えばエンドツーエンドテストでその C0 カバレッジとかを取る。
C0って言ってるのは命令カバレッジって言われてる。全ての行が実行されたみたいなやつなんですけど、あれ取るのはめちゃめちゃ難しいです。
組み合わせ爆発になってしまう。すごく難しいんですよ。なので普通は全ての行を実行したいじゃないですか。最低限よく実行しろって言われるのがこの C0って呼ばれてるカバレッジなので、それをエンドツーエンドテ
ストだけで取るのは非常に困難なんですよ。
だけど単体テストを使うとそれがあっさりと実現される。 じゃあ単体テスト全部単体テストでええなって話になりませんか。
これがそうはならないんですよ。なぜ組み合わせって話になるかっていうと、先ほどエンドツーエンドテストの感度は単体テストの上位互換だって話をしたと思うんですけど、
ってことは単体テストで見つけられないんだけどエンドツーエンドテストでは見つけられる。そういうものがあるってことなんですね。
これはじゃあどういうものかっていうと結合バグって言われるものです。 組み合わせた時に何か発生する問題って。
例えばちょっと例を見てみようと思うんですけど、フィズバズ、私フィズバズがみんな大好きなんで、フィズバズでよく例えるんですけど、フィズバズって
数を入れたらそれがフィズかバズかとかあるいは数字かみたいなとか出してくるようなやつですよね。 これで例えばそのターミナルのプログラムで数字をポチって入れてエンター押すとフィズとか返ってくる。
そんな感じのプログラムをフィズバズだとしましょう。 こうした時に私は2つのコンポーネントに例えば分けるとします。
1つは入れられた文字列っていうのがちゃんと数字かどうかを判定して数字だけ返すってやつ。 バリエーション的なやつですね。
ともう一つはその与えられた整数っていうのがフィズなのかバズなのかあるいは普通の文字列なのかっていう風に変換するやつ。
これは例えばその文字の部分のバリエーションは簡単ですよね。Aとか入れられたら弾く。 1って入れられたら1を通す。
でもう片方は1って入れられたら1を返すし3って入れられたらフィズを返すし 15って入れられたらフィズバズを返す。
いいじゃん。それぞれテストかけますよね。テスト通った。くっつけた。そしたらエラーになりました。なぜか。なぜかというと
1とかそのバリエーションする方が文字列で返しちゃってた。
だけどもう片方は整数を期待していた。 これ両方ともコンポーネントテストは通るんですよ。そういう仕様だったんだねっていう話。
単体だったら通るけどそれらを組み合わせて使った時には落ちてしまう。
落ちてしまう。片エラーで落ちることになるわけですけど。性的な型検査がない言語だと実行時エラーで落ちますね。
ということが起こるわけで。じゃあこれは何だったのかというとこれがまさに結合バグって言っているもので
一個一個は正しいんだけどその一個一個の仕様がくっつかないんですね。
くっつかない。馴染みが悪いって言うんですかね。そういうふうなことが起こるっていうのが結合バグです。
エンドツーエンドテストはこの結合バグを見つける親玉です。全てがくっついてるんで。全てがくっついてるんで全てのところの結合バグを見つけられるっていうのがこのエンドツーエンドテスト。
そういう感じですね。なので単体テストでは見つけられないんだけどエンドツーエンドテストで見つけられるのはこの結合バグっていうのが主なフォーカスになってくるわけですね。
ってことは使い分けとしてはそのただの条件分岐のミスとかそういうものとかっていうのは全部単体テストで見つけたい。
コンポーネントテストで見つけたい。それじゃなくてコンポーネントとコンポーネントをくっつけた時に何が起こるのかがよくわかんない。それをエンドツーエンドテストで確かめる。
結合テストで確かめる。それがエンドテストの使い分けって言ってる部分ですね。
なるほど。今の話であればエンドツーエンドのテストで全てのユースケースっていうか全てのインプットをモーラ的にテストするのではなくてそのコンポーネント単位でちゃんと仕様を決めてその仕様が満たしているって
いうことを保証するのがエンドツーエンドのテストってことなんですかね。
で実は階層構造があって一番上にあるのがトップレベル仕様って言われているもので私たちは例えばウェブサービスとかを扱うんだったら画面遷移図みたいなものがトップレベル仕様です。
今一番最初に何もない状態でログイン画面が出てログイン画面でログイン入れて正しいやつを入れるとokでとかそういう風な画面遷移図があるじゃないですか。
これを通りにエンドツーエンドテストって大体組むわけですよね。
なのでこの画面遷移図っていう仕様がエンドツーエンドテストにとっての仕様だし、
例えばユニットテストとかそのコンポーネントテストって言われているのはもっとJavaDocとかに書かれるような例えば1たす1が2になるみたいなそんな感じの仕様が書かれている。
関数単位での仕様。
そうそう関数単位での仕様が書いてある。
なのでこれはもっともっとちっちゃい分解された仕様なんですね。
なのでどっちも仕様なんだけどちょっとその間には区別が必要ですね。
トップレベルの仕様なのかそれともコンポーネントの仕様なのか。
なるほど。
そこまでいくとこの使い分けエンドツーエンドテストを使うべきところと単体テストを使うべきところの分けっていうのが結構難しくないかなと思っちゃったんですけど。
この仕様っていう話がそのコンポーネント単位による仕様であれば単体テストで行けますと。
ただプロダクトレベルの画面単位とかプロダクトレベルの仕様であればエンドツーエンドテストの範囲なんだけど
全体を見て俯瞰しているエンジニアでないとこれを使い分けるって結構難しいんじゃないかなと思っちゃいました。
いい質問ですね。それは本当にその通りで。
そうなんですよ。難しい。
それは本当はテスト設計とかテスト計画とかやったりするようなテスト戦略とかやったりするようなものでそれ自体がすごく難しいことではあるんですよね。
ただ現実にはほとんどの人はQAっていうかマニュアルテストする要因とコンポーネントテストする要因は分かれちゃっていて
お互いがお互い好き勝手やってるっていうのがよくある現場での例ですよね。
なのでそこに戦略もヘッダクレもないんですけど本当はインテストで担保していることはエンドツーエンドテストでテストしなくていいし
というふうな本当はそういうのがあるって感じですね。
お互いが強調し合ってどちらもどちらをちゃんとテストケースを見た上でちゃんと分けて管理した方がコスト的に安いし時間も節約になるし健老になるしってことなんですね。
これはすごく端的に本当にその通りでエンドツーエンドテストって先ほど事故コスト高いって言ったんですけど2倍とか3倍とかだったら全然いいんですよ。
それだったらエンドツーエンドテストに私も全部寄せるんですけどそういう単位じゃないんですよね。
100倍とか1000倍の単位で遅いんですよ。
だからエンドツーエンドテスト1個通してる間にユニットテストのテストケースだと100件とか1000件とか普通に通せちゃうんですよね。
なのでそれはもう圧倒的に違うじゃないですか。
エンドツーエンドテストとか5個もたもたシナリオテストしてる間にユニットテストは5000件のマトリックスできるって言ったら全然遥かにテストできる範囲が違うんで。
だからエンドツーエンドテストでマトリックスとか組んで24時間経っても終わらないんだけどこのテストみたいなの作らずにユニットテストでそういう細かな条件分岐は拾いましょうという風な使い分けの方がより多
くのバグを見つけられるという風に私は思っている感じですね。
最終的な目標としてはバグを見つけるもしくは壊れていないことが保証できるテストとして。
そうですね。ただテストはバグを見つけることはできるんだけどバグがないことを保証するってことはちょっと特殊な方法を使わない限りはできないんですね。
あくまで証明みたいな。
さっき言った通り結合すればするほどテストケースが増えていってその全部をテストしたんだったらバグがないってことのお済みつきが得られるわけですけど。
E2Eシナリオの選び方と25分の実体験
実際ちょっと考えてみると簡単なんですけど設定画面行って戻って行って戻って行って戻って100回繰り返すみたいなことができるわけですよ。
それでクラッシュしないことって言われたらそれ1万回でもできるじゃんってことは無限にテストケースあるのがわかりますねと。
なので普通はこれをテストしきることはできない。
なのでどこかで諦めてこの範囲ではバグが見つからなかったとかいう言い方になる。
現実的にそうなってしまう。
そうなってしまう。
でその上で諦めるということがある限りその理想は理想でありコスト的に有限なコストを抱えている現実においてはその理想ができないのであればエンドとエンドテストだけでは絶対的にできないという話に結論としては
なる。
なるってことです。
でじゃあ当然ここで気になるのは現実テストってなるべく書いた方がいいっていうのはわかった。
だけどエンドとエンドテストも書かないと結合バグ見逃しちゃうよねって話を言いましたわけです。
じゃあ一体エンドとエンドテストのテストケースつまりそのテストのシナリオとかっていうのはどう選べばいいんだって絶対疑問に思うと思うんですよ。
これはもうだいたいそのある程度答えは決まっていてユーザーにとって価値があったりその運営部隊にとって価値があるその2つのどっちかのケースっていうのを選ぶべきだとよく言われています。
それはなぜかというとお客さんにとって例えばそのXとかツイートしてそのいいねもらってそういうのが嬉しいサイクルなわけですよ。
それは当然テストしますよね。
他の人にいいねされたらちゃんといいねの通知が出てくるとかっていうことをテストする。
一方でお客さんにとっては嬉しくないんだけど企業にとって嬉しいのは当然あります。
それはお金を使う当然です。
例えばXでプロモーションするっていうのがつい最近プロモーションのぬってしたから手が出てきてみたいな。
話題になってましたね。
あれは別にユーザー嬉しくないわけですけど運営部隊にとっては大事なわけですよ。
なぜかというと収益源になってるお金が大事なわけなので。
なのでどっちかに当たるようなテストケースっていうのは最低限のものだけをいくつか選んで
ハッピーパスだけやりましょうっていうのがエンドツーエンドテストの原則になると思っています。
ちなみに最低限はやりましょう。
お金の部分と運営部隊として一番重要な部分と
あとはサービスとして最低限保証しておかないといけない部分。
Xだったら投稿するだったりとか
いいねが通知が来るとか
いいねボタン押せるとかそうかもしれないですけど
そういう最低限のところをカバーするっていう他以外に
エンドツーエンドとしてやっておく
今のって最低限って言っていたので
最低限じゃなくて
できる限りやっておいた方がいいは真なんですかね。
できる限りそれが難しくて
エンドツーエンドテストっていうのは保守コストが高い理由のうちの一つが
結合しているものが多いので
仕様に振り回されるっていうのはすごくあるんですね。
ぶっ壊れやすいということですね。
例えばコンポーネントテストだったら
そのコンポーネントに対応するテスト直せば
あとはすがなく全部グリーンになるわけですけど
エンドツーエンドテストっていうのは巻き込まれて
いろんなものがレッドになるんですよね。
いろんなコンポーネントを通って
結合されたコンポーネントを通っていく中で
その1個にでも何か仕様が変わったものとかがあると
そのテストは全部修正しなきゃいけないことになってくるんで
芋づる式に広がっていっちゃうわけですよ。
なんでエンドツーエンドテストが多ければ多いほど
例えばAIとかに任せるじゃないですか
これ実装しといてっつって
そしてエンドツーエンドテストとかまで
AIって聞きを聞かせて回してくれるわけですけど
なんか最近機能追加遅いなと思ったら
エンドツーエンドテストにほとんど時間を費やしていたり
みたいなことが起こるわけですよ。
それはとてももったいない。
それが保守コストが本当にバカにならないってことなんですよね。
今個人で作っているツールあるんですけど
今エンドツーエンドのテストを書かせてるんですよ。
今実行に25分くらいかかってますねローカルで。
単純に多すぎるし
1個機能追加するのにそれだけ時間かかってしまうっていうのは
個人開発だったら別に
自分の時間その間ゲームとかしてればいいだけかもしれないんですけど
これが企業とかだったら
長すぎないみたいな話になってくるっていうことですよね。
でもユニットテストだったら
普通はユニットテスト1分以内とか5分以内とかに終わらせるべきものなので
それぐらいで終わるわけですよ。
それってもう全然遥かに違うって感じのものになるわけですよね。
だからなるべく分岐とかマトリックスとかでテストを
マトリックスっていうのは例えばこの条件この条件この条件みたいな
パターンがいくつかあるじゃないですか
そのパターンを行列みたいな形でテストする
表を書いてそれを1個1個全部埋めていくみたいな感じのテストが
マトリックスのテストなんですけど
マトリックスのテストとかは明らかにコンポーネントとかユニットテストでやるべき
それをエンドツーエンドテストでやるのは終わってるって感じですね。
理解しました。
AI時代のE2Eテストとテストファースト
くにあげさんの主張としてはかなり理解できたかなと思うんですけど
ちょっとひるがえってもうちょっと
一番最初のXでのバズった投稿の
大元を書いてくれた人の主張としては
AIがコーディングすることにおいて
エンドツーエンドに全部寄せてしまった方が
楽というかちゃんとテストできるんじゃないかという主張で
大前提そのAIというものがあるわけじゃないですか
さっき言ってくれたエンドツーエンドテストのコストとして
実行時間が長いというのは確かにその通り
運用保守の部分ですね
テストの保守の部分はAIが何とかしてくれるのではないかという
疑問に関してはどうですか
それはとてもいい質問だと思います
これに関しては緩和化されるが
根本的な解決はしていないというのが答えになっていて
もちろんそのAIが保守コストっていうのは
だいぶ安くやってくれるようになったわけですよ
しかも並列度をカットスケールさせて
直すとかいうことができますからね
でもちょっとよくよく考えてほしいんですけど
エンドツーエンドテストが直ったことってどうやって確認しますか
って言われると実行するしかないんですよね
試してみるしかないってことですね
実行して落ちるかどうか成功するかどうかを見るしかない
もちろんテストセレクションって呼ばれてる
テストケース実行すべきものどれかっていうのを
賢く選ぶ方法ってあるわけですよ
例えばここの部分しか触ってないから
ここだけテストすればいいのみたいなのあるじゃないですか
それが上手にできていればエンドツーエンドテストでも
すごくうまくその部分だけ見るってことができる
ですけどテストセレクション誰がやってますかって話なんですよ
テストセレクションって論文書かれるぐらい
すごい難しい分野なんですよ
だってそれ依存関係によっては大元のところをいじったら
もちろん全部再実行しないといけないし
それで枝葉の部分上位のコンポーネントをいじったから
じゃあそこの部分のエンドツーエンドテストだけでいいよね
っていう話になればいいですけど
それって枝葉の部分だけであって
そんなことないですよね現実
そうそんなことないんですよ
グローバル変数1個触るだけで
本当は全部やり直しになっちゃうんですよ
そんな風になっちゃうんで
そのテストセレクションっていうのはやっぱり
まだちょっと人類で有名なところがまだちょっとあって
エンドツーエンドテストはやっぱり結構関連する部分
大きく大雑把に回さざるを得ないっていうところがあって
そこで実行コストが乗ってくる
これはAIがいくら賢くなっても解決しない
エンドツーエンドテストが遅いっていう
実行によってしまうからってことですね
正しいかどうかっていうところを実行してみないとわからないので
そこが時間的なコストがかかってしまうんだったら
あんまり意味ないよね
あとはさっき言った通り
いきだるま式に関係するコンポーネントシナリオ
結合するものが増えてるってことは
ユニットテストはちっちゃく直せばいいのに
エンドツーエンドテストは結構まるっと
何パーセント直さなきゃいけないレベルになっちゃう
ってことがよくあることで
それもやっぱり振り回されるって意味ではそうですね
なるほど
なのでAI時代においても若干は緩和してきてる
とはいえ大元として
大元の課題感は特に変わらないんじゃないのか
そうなんですよ
いくらコンピューターが速くなっても
N事情とかのオーダーで動くものってのはやっぱり遅いと
そういうのと同じレベルの話だということです
なるほど
ちなみに次の話題というか
ちょっと疑問点として
エンドツーエンドテストに寄せたらいいんじゃない論調の場合
AIにもしかしたら
エンドツーエンドを書いてもらうみたいな話になってるのかな
とは思うんですけど
それが正しいかどうかみたいなところでどうなんですかね
これは非常に難しくて
多くのエンドツーエンドテストを自動で書かせた人の事例を見ていると
実装の追認にしかなってないなって思う
追認っていうのは要するに後から実装はこうだから
こういうのが正解なんじゃねって推測して書いてる
なるほど
振る舞いじゃなくて
推測というか
こう書いたからこうなってるのが正しいよね
でしかないっていうことになってる
パスワードフォームがあって
データベースにチェックしてるから
多分これに正解のデータ入れればいいんじゃねって
推測してるってことですね
これ私ちょっと思うんですけど
実装の追認のテストって何か意味あるんですかねって思ってて
正直あんまないよねって思うんですよね
私たちがViveコーディングとかで作った
ソフトウェアに対してエンドツインのテストをした最大の動機って
糸通りにできてるかなですよね
ちゃんと動いているか
ちゃんと動いてるかそれ本当に糸通りに動いてるか
ちゃんとバグがないかって言い返すと
ちょっと言い方を変えると糸通り動いてるかって
糸通り動いてるか
糸通り動いてないのをバグっているわけですからね
その糸通り動いてるかっていうのを
実装からリバースしたら
そりゃ実装が正しいになっちゃうじゃん
実装が正しい
やっぱり糸っていうのがどこにもない
出てきてないわけですよ
だからその作業者の方
Viveコーディングとかやっている
作りたかった人の考えっていうのは
そこに入ってない
入ってない
フロントとかにはたぶん散りばめられてるわけですけど
だけどそんな結果
AIの解釈を挟んだ結果が実装としてあるわけで
その解釈前のデータどこにも残ってないんですよね
だからAIの解釈が正しかったかってことが
どこにも現れてない
どうやっても確かめられることができない
っていう意味で私は
AIに実装が先にあって
その次にAIでエンドツールテストがって書かせるぞ
みたいのは絶対やめた方がいいと思ってます
ちなみにそれ逆にしたらどうです?
先にエンドとエンドを書かせる
いいですね
これはある意味筋がいいと思うんですけど
もうちょっといいやり方があるかなっていうのが
私の答えですかね
このエンドツールテストを先に書くっていう流儀が実はあります
これはテストファーストっていうのは
よくテスト駆動開発とかで
TDDとかで出てくるやつなんですけど
このテストファーストで
先にユニットテストを書くか
エンドツールテストを書くかっていう流派があります
このうち先にエンドツールテストを書くっていう流派が
まさに今おっしゃったような例になっていて
先に私たちはこんなの作りたいんだよねっていうのを
いくつかの例を書いて
例えばECサイトだったらカートみたいなのがあって
商品選んでカート入れて掲載して
届くみたいな
そんな感じのシナリオを一番最初に書いて
当てずっぽうで書いてそれを満たすように
埋めていくっていうやり方を取るわけですよね
これはすごく
良い意図が現れているパターンだと思います
なのでこの順番はすごく良い着眼点で
それはすごく良い
と思いますね
なるほど じゃあ先に
作業として
こういう挙動を
こちらは意図しているよ
考えているよというのを
プロンプトとして渡しつつ
エンドツーエンドテストを書いてもらって
それをちゃんとエンドツーエンドテストを
確認するという作業を挟めば
ある程度の精度は出そう
そう精度は出ると思います
ただここでもやっぱりエンドツーエンドテストが遅いという話が
いつまでも出てくるんですよ
最終的にはね
例えばカートを追加するときに
プレミアム配送オプションとかを追加した
っていうときにエンドツーエンドテストのテストシナリオを
一個追加するのかって言われたら
さっき私が言ったマトリックスでエンドツーエンドテストするな
というものに引っかかっちゃうわけですよ
そこはエンドツーエンドテストで
書くのを諦めてコンポーネントテストで
プレミアム配送オプションのときは配送Bの表示が
こうなるみたいなのを入れてあげる
逃がしてあげないといけないという意味で
ちょっとなかなか
難しい部分がある
どっちにしろはやっぱり
実行の遅さというところが
どうしても出てきてしまう
ずっと足を引っ張るということです
テスト戦略とテストオラクル
最後に
聞きたかったのが
であれば
今ずっと言ってたのって
実装をして
じゃあ後から追認する
もしくはエンドツーエンドのテストを
先に書いて
書いてもらって
意図通りのシナリオを書いてもらって
それを確認しつつ実行していく
ただどっちにしろ遅いよねというような
話なんですけど
そこに対してエンドツーエンドテストだけではなくて
例えば単体テストとか
そういうユニットテストだったりとか
そういう
いろんなテスト手法を交えた
テストの設計を
先にさせるというのはどうなんですかね
それはとってもいいと思いますね
ただAIってやっぱり
結構平均的な技術者に
合わせてしまうところが結構あるなと思っていて
だからその手段を
って言われたら普通にユニットテストと
エンドツーエンドテストと答えちゃうと思うんですよ
実際はもっといろんな手段があるんですよ
例えば本番環境だとオブザーバビリティみたいな
話とかもあるしもっともっと
手前の上流の方になると形式手法とかで
使用を
形式手法とか使って記述する
形式使用記述って言われてるものがあって
そういうのとかっていうのも方法があって
それも全部使いこなすんだったら素晴らしいと思います
それはただAIは支持しないとやってくれないはずです
そうですね
そういうことをしてよって言わないと
そもそも選択肢に入らない
そこは引き出しを持って
どこに何か聞く
どんなバグが出るかもしれないから
どこに何を当てるかっていう風なやっぱり
戦略が求められるってことですね
それは結構サービスごとに違うんですよ
なるほど
例えばおみくじサイトに形式手法を使うなんてバカげてるわけですよ
バグったところで
ずっとバグじゃないですか
だけど航空宇宙とかのやつだったら
やっぱり形式手法とかは使わないと
損害が本当に運をくどるみたいな感じになっちゃうわけなんで
人命がかかるとか
人命がかかるとかってことになっちゃうんで
なのでそれは形式手法を使おうねって話になってくる
っていうのがあるんで
これはすごく難しい今も戦略
テスト戦略どういう風にテストを構成
ユニットテストとか形式手法とか
いろんなのを構成するかってのは
今も難しいとても難しい話ですね
そこはすごく今もシニアエンジニアとしての
センスが問われている部分だと思っています
なるほど
今の話ってもしかすると
分野によっても違うし
あとフェーズによっても違うよね
っていうところが
結構絡み合っていて
何がこうすればいいって話でもないってことですよね
そういうことです
本当におっしゃる通りフェーズによっても
分野によっても違って
例えばちょっとハードウェアが入るの
IoTみたいな分野になったら
今度はハードウェア交渉とかまで
入れてこなきゃいけない
ハードウェアにもユニットテストみたいなのを
考えることができて
基盤に針当てて
ここちゃんと通電してるか
見るとかっていう
ユニットテストできるんですけど
そういう風なやつとかも
考慮してこなきゃいけないっていう意味で
本当にいろんなことを考えなきゃいけない
なるほど
じゃあXで
いろいろレスバー
してるかもしれないんですけど
ああいうのは
この特定分野に関しては
みたいないうコンテキストが
大前提ちょっと
共有されてないと
見る人によって違いそうだよなっていう
のがありそうですね
全部エンドツネルテストにするのは
例えばエンターテイメントのやつとかだったら
すごくちっちゃなサイトとかだったら
成り立つんじゃないですかっていうのは
思いますね
やっぱり多くの事業者はそんなに単純なサービスを
扱ってると思っていなくて
ゲームとかもすごい複雑ですよね
その話では相場になりたたなくなる
と思っていて
いっぱい寄りに合わせたつもりで
話をしたところです
主語がでかいと
お互い主語がでかい
すべてエンドツネルテストでできる
いや違う
主語のでかさのバトル
っていう感じのことになってるし
本当にマジで分野によるし
適用範囲によるし
何が最適かっていうのは
そのサービスごと
システムごとに全然違いがない
中ででも
だからといって
エンドツネルテストだけが
銀の弾丸ではないから
ちゃんと考えてテスト設計しようよっていうのが
栗明さんの主張ですね
そうですねテスト設計テスト戦略を決めよう
っていうところですね
本当にそうだと思います
そこに関してちゃんと
自分的に
形式手法を使うのであれば
ちゃんと知識として
学んでいったりとかしないと
AIは使ってくれないので
使ってくれないし
最近バイブ形式手法
みたいなのが話題になってて
バイブ形式手法
つまり何を検証されてるか
分かんないけど検証されてるだけだよね
ってちょっと思っちゃうところがあって
表層的なところのみ
ちょっとやってみているだけで
それは表層的な
ところのみなので
確信の部分は
やってないしプラスアルファ
ちゃんと確認もできないよね
実装の追認じゃないですか同じですよ
形式手法に起こしたところで実装の追認
なことには変わりはないんですよ
結局これよくテストオラクル
って言い方をするんですよ何が正しいとして
何が正しくないかってことを決める
このテストオラクルを実装にしちゃったら
おしまいなんですよ
だって何も見つからないんですよね
だって
変なことが見つかったとしても実装はそう書いてあるんだから
そうって言っちゃえばそうですよね
それが正しいかもしれない
実行したらそうなるんだからってことですよね
明らかにクラッシュするとかメモリリークとかするとか
っていうのは確かにそれはおかしいってのは分かるんだけど
そういう一般的なことしか見つけられないわけですよ
だけどメモリリークしてないけどクソなアプリケーション
はいくらでも作れるわけで
それが保たれたところでっていうところで
やっぱり本当に
大事な部分を見抜けてないんですよね
だからテストオラクルは絶対に実装にしちゃダメで
本当は仕様とか
あるいはちゃんと人間がそのテストオラクルを
ちゃんと制御できる状態に置くことがすごく大事
実装じゃないとですね
あれですね
そのサービスは
何が一番重要ですかってところをですね
そう
本当にそう
あとはどれだけ
バグが見つかってほしくないかとか
どれだけアグレッシブに攻めるかとか
いろんなパラメーターがある中で
一つのテストの組み合わせ
テストをどこまでするかっていうのの答えを
決めていくっていうのが今私たちの
AI時代の人間の仕事ですね
人間がやることっていうのは
やはりサービスと
機械との接合点を
いい感じに回していかないといけないし
そこに対して
人間独自の考えを入れていかないといけない
じゃないと
AIさんは80点ぐらいの答えしか返ってこないから
80点にもならないんじゃないですか
科学的には80点にもなってないですね
5点にはなってないと
全然足してないと
現時点においては
だからこそ
テストの部分に関しても本当にちゃんと考えましょう
1個だけやってればいいって話じゃないんだよ
そうなんですよ
だからやっぱり
人間が今やってる以上
旗振りの精度を上げていく
っていう活動をやっぱりしなきゃいけなくて
その精度を上げていく活動が一番の
その活動何かっていうと
やっぱりテストを勉強したり形式書を勉強したりとか
そういう理解にあると思うんですよね
その理解があるから
初めていいジャッジをすることができる
私はその理解を捨てたら
方式性でしか
うまくいかないって感じになって
最終的にはあんまりいい結果にならないんじゃないかな
っていう風には思っています
ちゃんと勉強しろってことですね
結局は人間もそう勉強し続けなきゃいけない
そこは変わりがない
いい話だな
最終的にいい話に落ち着いたなって感じなんですけど
AIだけで全然できるものじゃないし
そうですね
セキュリティとサービスごとの設計
多分そこら辺はあれですかね
昨今問題になっている
セキュリティ的な観点でも
同じことは言えるんですかね
そうですね
セキュリティ的な観点もまあ難しいですよね
セキュリティってやっぱり
いくつものレイヤーでの
攻撃があり得て
守りたいものも
サービスによって違いますよね
個人情報を守りたいのか
それともそうじゃなくて
例えば
信頼できる情報をやり取りしている
みたいなそういうのが守りたいのかとか
いろんな守りたいプロパティがあって
サービスによって違うんですね
それによって攻撃手法が変わってくるわけなので
ちょっと
そこも押しきせだと
難しい部分の一つなんじゃないかなって思いますね
あと
セキュリティで難しい部分が
全部を塞ぐことはできないみたいな
ところもあるのかなと
どうでしょうね
私は結構全部を塞げるんじゃないかなと思っていて
よく有名な逸話に
DNSのサーバーでバインドっていうすごくデカいやつがあるんですけど
あいつは結構カオスなサーバーで
かなりコード的にも
難しくてバグがいっぱい出てる
っていうのがあるんですけど
一方でDJBって人が書いた
DNSがあるんですけど
そいつからはほとんどバグが
見つかっていないのがあって
このAI自体にですよ
単に使われてないっていう可能性はもちろんありますけど
でもやっぱりそれって
どれだけセキュアにかけたかっていう話が
最初からあるんだと思ってるんですよ
だからそれくらい堅牢に
作ることもできるんだろうとは思っています
なるほどね
じゃあ単体に関しては
そのツール単体DNSサーバー
単体に関してはセキュリティは
問題ないけども
おそらくそれを運用していく
例えばPCの
デバイス部分に脆弱性が
他の部分であるとか
それはもういっぱいありますね
そういうことを現実に落とした時に
全てを塞ぐことはできないっていうのは
そこら辺あるんじゃないのかな
それはあると思いますね
単体単体で見たら
一番最初の話に戻るかもしれないですね
単体テストだったら簡単に
理想の状態できるけど
エンドテストになった瞬間
全てを塞ぐことはできないみたいな
それはありますね
そういう話なんですね
結局のところ
やっぱりセキュアなところに
あんまりリッチなものを持ち込むと
偉いことになるって話はあると思っていて
セキュアなところにはなるべく
限定的なことしかできないものを
持ち込んであげるってことも
結構大事かなと思っていて
それでも少しは
セキュアになるんじゃないかな
それはその通りだと思います
できる限り依存なく
シンプルに
分かりやすいものを
入れていくっていう
それはセキュリティ的な観点で言うと
Mac OSとかWindowsみたいな
巨大なシステムを使っちゃうと
それはいくらでも脆弱性が入ってくるわってのは
それはその通りで
なるべくちっちゃなコアのものに
出せれば脆弱性はだいぶ減りますよね
それはそうって感じですね
本当に最低限しか入ってないLinuxの
ディストリビューションを使うみたいな
そういうことをしないと
むずいだよねって
全然使ってても
Candle関連のバグはどうしても使っちゃうから
Linuxよりもっと小さいOS選ぶか
そうなっちゃいますね
結局
テストの話から結構離れてきちゃった
ここまでにしたいなと思うんですけど
人間が担うテスト戦略
やっぱテスト
何が正解かっていうのは本当に
サービスによるし
フェーズによるし
それがプロトタイプだったら
全然関係なくてもいいかもしれないし
テストなんてなくてもいいかもしれないし
っていう世界線になるかもしれないし
やっぱちゃんと人間が
ジェッチすべきですね
これ1個でいけるって話ではないんで
ちゃんと考えようし
あとは勉強しましょうっていうようなところですね
まとめとしては
ありがとうございます
ということで今回ここまでにしたいなと思います
もっと詳しく教えてください
ラジオ略意したくばラジオではですね
スーパーエンジニアである国明さんに
一般エンジニアである遠徳が技術的な質問していく
番組になっています今後もいろんなこと
聞いていけたらなと思ってますので
お聞きのプラットフォームで高評価フォローや
チャンネル登録のほうをお願いします
またこんなこと聞いてほしいとかありましたら
コメントいただけると
話しますのでよろしくお願いします
Xなどで感想などもお待ちしております
それでは今回もありがとうございました
ありがとうございました