テストの基本的な考え方
あれは結構大事な話っていうのは、この1,2章かなーみたいな気がしますね。そもそものこの本のテストっていうものに対する考え方とか前提みたいなところ。
魅力的なタイトルの章はたくさんあるんですけど。
章は、全部テストしたらいいのでは?って言って、全部テストするってどういうことなんだろうねって。そんな無限に時間がないと無理でしょう、みたいなことですね。
これ、時間かかってるなって言ってちょっとまずいんですけど、ちょっと話しとれますけど。
これ3章の冒頭に引用されているテストは確かにバグの存在を証明するかもしれないが、バグの不在は証明できないっていうのが、江戸川ダイクストラって書いてあって。
これ言ったのダイクストラなんですね。
そうですね。
すごいな。
コンピューター関連のことをこの人がどんだけやってんだよみたいな。
ほんとですね。じゃあ次ダイクストラか。
ダイクストラ言いますか。
重いなー。
すいません、話を戻すと。
大事です。
第3章どうでした?
そうです。
タイトルが全てなんだよな。
そうなんだよな。そうですよねっていう感じでいるけど、多分それってコード書いてるとかソフトウェア作ってる人だからピンとくるような話なのかなっていう気もしましたね。
結局そうじゃない人からしたら画面で入力できるのを全部テストしたらいいんじゃないみたいな。
組み合わせってものとかに発想がいかなかったら多分画面でできることってこれとこれじゃん。じゃあこれ実際操作して問題ないか確認してよって言いたくなる気持ちはわかるなって思いましたね。
画面ソースね。そこらへんは今だと機械的に生成してバーってやれるんだろうな。CPUが安くなったので。
組み合わせが増えた瞬間に文字列が入力できるけどこれは全部の文字列入れるんですかみたいなことになると一緒にして無限大にいっちゃいそうですけど。
でもファジングとかやるためのいろいろなあれこれは存在はするので、全網羅ではないにせよ。全部網羅するのはやめた方がいい。
コストに見合うだけの価値のない情報が出てくるかって言われるとそうでないんでね。
これでもよくある間違いに飛びますかこの章。テストビッフェで食事をしようとか触れずによくある間違いで大丈夫ですか。
そうですね。もう多分全部触れてるとマジで時間がないって思うので。
これまあよくある間違いの1個目に今言ってたような全てをテストすることを要求するとか、サンプリングを理解してない。
サンプリング理解してないっていうのはあらゆるテストっていうのを所詮サンプリングに過ぎないのじゃっていうことを本編で言ってるんでそこを勘違いしてはあかんでっていう話ですね。
コストに見合うだけの価値のない情報に投資しすぎるっていうのがここで出てきているけど、面白いな。
なんか地下室やなやに使わなかっていられるものがあふれてませんか?的なことが書いてあって。
それらにかけた金で他に何ができたかわかっているだろうかって。
つんどくがたくさんあるからあんまり理解してない。
確かに。
横を何回か行けるぐらいには積まれてる気がするな。
何回かっていうか本当にあちこち行けるぐらいな。
あそこに本がたくさん積まれてますよね。
あれを買わなければ車が買えたのに。
車は買えないよさすがに。絶対車検切りの車とかになっちゃうんでちょっと良くない。
でも完璧なテストは人間にできなくてもコンピューターならできると考えるって出てきてますね。
テストのサンプリング理論
ファジングとか言っちゃったな間違いか。
でも結局それって究極的にはバグがないってことをコンピューターでどうやって証明するんですかっていうところに行くと思うんで。
そうっすね。
いやだって実行中にディスクが壊れたらどうしますかとかそんなテストする必要あるのっていうようなこともあるけど全て用とかって言われたら確かにみたいなとか。
そうですよね。太陽の活動が活発になって大沢さんがピュッとカセットのとあるところを通過したおかげでありえないバグが起きてとかありますもんね。
ありますね。それがうまく利用できるとRTAが。
やばいな。一般で温める時点でやばかったのに太陽を操作します。
いやでも本当にそういうことなんですよね。全てをって。別に要求してる側はそんなこと考えてないんだけども。
じゃあ全てって言ってることってどういう所条件のもとをテストするってことですかってじゃあ列挙してくださいって言うと。
本当に無限大のことを列挙する必要があってとりあえずちょっと列挙してから来てくださいって言って、スタックオーバーフロイがあるのを待つしかないみたいなそういう世界ですからね。
じゃあCPUの回路の劣化はどうやって扱いますかとかそういう話になってきますからね。
なのでどうやって逆に言うと結局ここも少ない投資で大きい価値を手に入れるかみたいないうことにつながっていくわけですよねテストって。
あとはそっかリソースに制約を加えてリスクを増やすっていうのはさっき言ったテストってサンプリングでしかないっていう観点だとサンプリングレート減らすとエラーの検出率は当然落ちちゃうので。
そういう話であったりとか。
そうですね。だから結局全てをテストできないからといって極端にテスト減らしても意味がない。
要はバランスってやつですよねここら辺は。
そうですね。投資して得られる情報が一番多いところを狙いに行きたい。銀行店を探しましょう。いやそれが分かってたら苦労しないんだみたいな。
まあでも第三章はそんなところですかね。
そうですね。
第四章テストとデバッグはどう違う。これテストとデバッグがどう違うのかちょっと触れますか?でも違うからな。
違います。以上みたいな。
まとめだけ読むか。
うーん。
様々なスキルを必要とする様々な仕事がテストの名の下に一括りにされることが多い。そのせいで計画見積もり作動割当てに歪みが生じ、プロジェクト全体に悪影響を及ぼす。という章のことです。
うん。
だからまあ階層度が高くない人がテストでしょって言ってる範囲がとてもとても広いんだなっていうことを感じましたね。逆に。
そうですね。
なんかそう思ってなかったからこの章がある意味があんまりピンとこなかったっていうのもありますね。
ではまあなんかテスト工程とかテスト担当者がやれるようなテストっていうのと修正のための原因調査分析試しに動かしてみるっていうデバッグは違うよっていう話で、たぶんさっきの話とつなげると、
デバッグ的な行為までテスト担当者がやってくれよみたいな話をするんじゃないっていうようなことなのかな。
そうだと思いますね。
未知のバグの取り扱い
まあしないしなーってなっちゃうねやっぱり。
でもデバッグはバグを見つけることでテストはそうじゃないから、結果的にテスト担当者がやることを考えたりして、
デバッグを見つけることでテスト担当者がやることを考えたりして、
探し出すのはデバッグに見えているみたいなところがあるのかなとかちょっと思ったりしましたけどね。
でもデバッグはバグを見つけることでテストはそうじゃないから、いや欠陥を発見することではあるんですけどなんか。
欠陥を発見することだけがテストではないというか。
すげーわ昨日甘いこと言ってる気するな。ちゃんと読んだんだけどな。
まあでも行きますか。18章ありますからね。行きません。
そうなんですよ。
どうします?まあ全部の章を振り抜くてもいいかなと思ってて。
8とかが、8の話をしてみますか8章の話。
5、6、7は飛ばすけど8。
良いテストの条件とは。
いやページ開くたびに笑うんだよな。良いテストの条件とはっていう章タイトルで章の扉1ページ目開くとハムレットのね、
シェイクスペアのハムレットの引用で、いわゆる悪いもない本人の考え方次第だっていうセリフが引用されてて。
騙された。
主観的ですみたいな。
そうですね。
でもそう確かなことはわからないとかね、観点によりますとかね、主観でしかないみたいな。
まあそれはそうみたいな感じなんですよね。
で、結局テストってさっきサンプリングの話が出てきて、良いテストっていうのは統計的な推定であるよみたいなところが話として出てますね。
で、まとめとか読んでもテストが成功したかどうかを確実に知る方法はないが、失敗したかどうかを知る、また推定する方法はいろいろありますよっていうところで、
まあ統計的な推定ですよっていうところと、
で、ちょっと自分が触れたいなと思ったのが、86ページにわざとバグを挿入する方法もあるって書いてあって、
一応、バグを挿入する方法はあるんですけど、
わざとプログラム中の中にバグを仕込んでおくと、そのバグの分布と未知のバグ、
がほぼ一致しなければならないみたいな、いうような話があって、
そんな器用なことってできるのかなっていうのはちょっと思ったんですよね。
本当に僕たちのプログラムを使っているだけではないかなと思ったんですけれども、
この訪問の中には、アルゴンがあるときに基本的にアルゴンのスキルをつくる必要があるというふうに考えたのって、
今後のこのプログラムについては考えた方が良いと思っていると思うわけです。
いうような話があって 何ですか ね そんな器用なことってできる
のかなっていうのはちょっと思 ったんですよね でも 一応 私は
コードレビューやユニットテスト などで 開発者自身が見つけたバグ
をそのままにしておいて これなら バグは自然なものになるっていう
話を書いていて 要は分かってて 直さなかった結果 そこを
が見つかったらそうだよね みたいな ことにして 未知のバグと本来
購入したバグが自然な分布になる ようになってるよね だから大丈夫
そうだね 極端な変なことが起き てるってことはないよね みたいな
いうような話をしてるんですけど そんな器用なことできんの 本当に
できなくね みたいなことを言い ましたね
おだしょー 本当にあるんですか ね こういう処方がって思っちゃう
ぐらいにはちょっと疑わしく感じ てるんですけど
楊 そうだいぶ怪しいなって思 ってますね これは
おだしょー 未知のバグの数を推定 するんですよね
楊 そうですね 未知のバグを推定 するために わざと仕込んだって
よりは 途中で見つかったバグで 途中で見つかってるから それは
基地のものに変わっているから その基地のものと同じ分布で未知
のものも出てくるでしょっていう ふうな考え方をしている わざと
間違えて挿入してやろう みたいな 楊 人工的だね 恣意的なものじゃ
なくて 本気で書いて ガチで間違え たやつを直さないでテストに流
そうみたいな 挿入したバグの分布 が未知のバグの分布とほぼ一致
していなければならないっていう 表現が出てくるじゃないですか
意識してないと この手法で得られる 情報データの活用方法がないみたいな
意味がなくなっちゃうみたいな 文脈なんですけど 未知のバグの
分布ってわかるの 未知って言ってる のは何なんですかね 開発者が書いた
時点で分かってなかったけどテスト に見つかったよって話なのか 本当
に潜在的に埋め込まれてる誰も 気づいてないバグの話なのか ただ
誰も気づいてないバグは発見される まではバグじゃないからな
楊 そうですね 楊 未知のバグっていう単語というか
一言で矛盾してるワードの可能性 がある どういうことなんですかね
吉田 自分は読んだっていうのは 基地のバグっていうのが わざと
見過ごしたバグ さっきのコードレビュー とかユニットテストで見つけた
けどもスルーしたバグで 未知のバグ っていうのは テストした結果 自分たち
が見過ごしたやつ以外のものを 未知のバグ
吉田 ってことですよね 楊 で それの傾向性が一致するんで
あれば あとどれぐらい埋まってる かとかが推測できるでしょうっていう
それは統計的に同じ傾向性であるん だったら そういうふうに見つかる
はずだよねっていうようなロジック ってことですね
吉田 うん でもそっか 未知のバグ の確かのサンプルになるとは限らない
とか書かれてるんで どっちかっていう と 本当は少なくとも自分 開発者
ですね コードを書いた人が あと 10個はバグがある 地のバグとして
10個は埋め込んだぞ 埋め込んでない のか そのままスルーパスで出した
ぞみたいな感じなのに そこから 1個しか見つかりませんとかだったら
ちょいちょいレビューとかテスター 大丈夫かいみたいな話にできる
よねっていうことか この方法で 発見されない基地のバグがあれば
何らかの情報にはなるっていう ふうに説明されてるんで
おだしょー でも読んでて そんな うまくいくって気持ちにしかやっぱ
ならなかったんだよな ってか これでうまくいくんだったら
そもそももうちょっとうまくコード を書けたりとか うまくテストできる
のではっていう気がするな
おだしょー そうですね Eテスト 要するに欠陥バグを見つけるための
機能が十分に備わってるテスト っていうふうにニアリーコール
テストの定義と重要性
で言い換えていいと思うんですけど Eテストを定義しようとしたら
どういう話があるのっていうので 1個のアイデアとして書かれてる
っていう感じですかね
おだしょー そうですね
おだしょー だから Eテストを定義 するの難しいっていう話が実は
言いたいことだと思うんだよな 良さっていうのはあんまりちゃんと
定義できないみたいなニュアンス というかスタンスではあるっぽい
ので
おだしょー そうですね
おだしょー 僕 その次のページにある 悪くないことは推定できる
という説があって ここで何個ぐらい だろう10個ぐらいかな過剰書きで
書いてあるんですけど これは少し 面白いなあっていう気がしました
ね 例えばテストは私の知りたい 情報を提供するためのものかとか
誠実かとか理解できるかとか あとテストとデモンストレーション
っていう話がここ以外でも出て きた気するんですけど ここでも
出てきて デモンストレーション はシステムを良く見せるための
ものであるテストは真実の姿を 見せるためのものであるべきだ
って書かれてて ほらちゃんと動く でしょうって言いたいがための
テストでしかないとしたらそれは 悪いものじゃないか 品質として
低いんじゃないかっていうような 話で
そうですね そうですね
みたいなことが書いてて 他にも 何個かあるんですけど ここは少し
内部構造とテスト設計の難しさ
面白いですねって思いました
自分もそこの中だと少なくとも 最も重要な点を網羅しているか
っていうのがいいなと思って 結局 全部 欠陥がないってことを証明
するために全部テストしたいけど それは実際無理なんで
何を結局テストするといいんだ っけってことを考えると 一番
使われるであろうケースみたいな ところをテストしておこうねとか
いうのっていうのはやっぱり大事 だよねと思って そこテストせずに
他テストしてたら何でってなっちゃ うなって思いながら
テストすべき箇所っていうプライオリティ のつけるべきだって話は間違い
なくありますもんね
おだしょー 全部できないんだったら大事な
とこからやろうぜみたいなことに なるはずだよねみたいな それが
結局悪くないっていうとこに繋が っていくよねっていう
最低限必要って感じですよね 悪くないっていうのは
おだしょー そうそう
で そんなのがありつつ よくある
間違いを見てみると ここで5番と6番がそうだよなと思
おだしょー 製品の内部構造を知らずにテスト
するっていうのと 製品の内部構造を知りすぎてテスト
するっていうのに書かれてて ここむずいんですよねっていつも
思うな
そうですね どの帽子をかぶって
今テストしてるのかみたいなこと は思いますよね
おだしょー 内部構造を知ってる身からする
とこういう不安がありますっていう 気持ちとテスト実際書いてみたり
動かしてみたりして これは開発 者の不安に対して都合がいいだけの
テスト持ってないみたいな話とか ってことは変なカップリング起き
てるよなとか
わかる QAロールの人とテスト を設計するときに こっちは内部
構造を知ってて 向こうは知らない っていう状態のタイミングでテスト
設計すると これって因子として 関係ありますかみたいなことを
聞かれたりとかして それはあります ありませんって答えるんだけど
それって結局内部構造を伝えて 内部構造のテストしてないみたいな
気持ちになったりとか ここ不安 なんですけど ここってテストする
価値ありますかみたいなこと聞か れたときに そこは変えてないんで
テストしなくていいですみたいな ことを言いながら 本当にこれで
いいんだっけみたいな気持ちに 本当にないんだけど こういう解消
してるけど 本当にこれでいいんだ っけみたいなことを思ったりする
ことはありますね 逆に内部構造 のためのテストを書くときとか
は どういうふうに観点の荒い出し とか これだと組み合わせばかし
ちゃうから どうやって組み合わせ を減らしていくかとか 代表値どう
しますかとか 境界値ってどういう ふうに見たほうがいいですかね
みたいな相談するときは 内部構造 知りすぎながらテストを書ける
から そういう観点ではすごくやり やすいなって思ったりとかする
ことはありますね
おだしょー なんかとはいえ 自分が 作ったやつで内部構造をしっかり
良いテストの条件と課題
分かってるから 例えば このプロパティ にヌル以外が入っていればオッケー
ですっていうのを単体というか スモールテストとして書いたとき
に 俺はこのプロパティが入っていれば 大丈夫っていうのはすげえ理解
できるし 本当にミニマムで最大の 価値を発見する いいアサーション
だなと思ってるけど 後から読んだ 人 絶対これ気にあからんくない
とかあるじゃないですか
おだしょー ありますね
コメント書いておけばいいんですけど コメント書くと負けた気持ちになる
からな いつも
おだしょー 分かる 分かる コメント がなくても分かるように書いて
コメントを書かないと分からない ようになってるってことは これ
構造が間違ってるんじゃないみたいな 気持ちになりながら とりあえず
コメント書いてお茶を濁すかみたいな 構造はありますから
おだしょー そうなんです それこそ 必要な情報を適切なコストで届ける
っていう意味では それで十分だし それが正解なんですけど いや コメント
じゃなくて構造でやりたいよな でも だからといっていつもカスタム
アサーション作るかっていうと やりすぎるよなみたいな
おだしょー そうですね
おだしょー 動詞 振る前に名前を付け れば確かに可読性は上がるけど
可読性か 本当にかみたいな わざわざ このメソッドの中身を見
に行って 結局そこでこれは何ですか 状態が起きてるみたいな
おだしょー うん しかもテストコードでそこまで
やると 何に投資してるんだろう かみたいな こういう気持ちになって
くるんですよね おだしょー だから 針の穴を通すような見事な
クリティカルなアサーションを 書くだけだと伝わりづらいかって
なると さっき言ってたクソデカ ゼーソン アサーションになって
いくので 全体の位置を見ますみたいな 絶対に全体が見たいわけじゃない
のに 悩ましい
おだしょー 悩ましいですね なので いいテストってとてもとても
難しいですね おだしょー そこで言うと4番の状況を考慮
してないっていうのがよくある 間違いの一つでしたね 出てきて
そうですね 等しく重要なテスト などありません とのような状況
で使用される可能性があるか パターン を考慮しないとテストは取ろう
に終わる 本当そうなんすよね
おだしょー そうするとどこまで 備えておくべきかなっていう未来
とのトレードオフがまた発生します からね
おだしょー ありますね このケース ほとんどなくないみたいなこと
そのケースが起きたことによって ほとんどないと言ってたケース
が起きたことによって どれぐらい 損失があるんですかみたいなこと
をトレードしながら 最初のリリース のブロッカーとしてそこのテスト
はしなくていいけど リリースした 後にそんなすぐ使われるわけじゃない
んだから 後で後追いでやりましょう とか いろんな戦略は多分考えられる
はずなので 状況を考慮しながら いいテストっていうものを考えて
いく必要はありそうな気がします ね
おだしょー いいテストの条件とは すごい考えさせられるといいですね
7ページぐらいしかないのに 難しいんだよな本当にPHPユニット
でこういうふうに書いてほしい みたいなことをサンプルみたい
なのを作りたいなと思ってるんですけど おだしょー ってか下手したら
いいコードとはより全然難しい ですからね
難しい難しい 文脈を固定しながら こういうのは書かないでくれ
みたいなのは言いやすいんです けどね やっぱり悪いものは分かり
やすい 例えばロジックがただの 欠端に対してテスト書いてもしょう
がないよねとか おだしょう お前はPHPのVFテストしてる
のかみたいなのありますよね そうそう引数の戻り値で型
決まってんだから アサートインスタンス オブでわざわざやんなくていい
よとか そういうものは多分ある と思うんですけど じゃあ結局いい
テストって言われたときに何を 保証してますかってちゃんと答え
られますかとか 機械的にチェック できるもんじゃなくて あなたの
コールに直接語りかけています みたいな そういうものが出来上が
って じゃあそれを人間は果たして ちゃんと読んで理解して書いて
くれるのかって言われると 難しい ねみたいな
そうですよね 意味とかいう すごい曖昧なものをやっぱり理解
しないと難しいですからね コード は最悪動けばいいんですけど テスト
を動くっていう概念がそもそも ないので
おだしょー そうなんすよ ローカバレッジを100パーにする
ことが動くってことですかっていう と うーんってなるし
おだしょー そうですね あとトゥルートゥルーって書いて
メソッドだけ起動してるテストケース を見たことがありますからね そう
ですか
おだしょー そうですかってなっちゃう やつですね AIとか書いていきそう
ですけどね
まあでもあれなんですけど PHPで言うとさっきPHPスタン PHPユニット
がそこら辺の無駄なアサートさ あのさっき言ってた戻り値の方
が決まってんのにアサートインスタンス を呼ぶなよとかは弾いてくれる
んである程度AIにも言うこと聞かせ られるんですけど難しいんだよな
おだしょー そうですね
これはいいテストですかって 最近気強にしてるんですけど大体
一発目に書かせたやつはいやこういう 漏れがありますっていうふうに言い
かしてくるんで最初からやれって 言ったの
おだしょー 本当にそりゃそうっていう 感じだななんか人間に近づいてる
感じがしていいじゃないですかAI も
でもあれですよねうずら さんが前言ってた成長しないジュニア
みたいなのはすげえいいエテミオ だなと思って記憶と学習の積み重ね
がない状態なんで毎時間退職する って言ってたら面白い
おだしょー そうねそうね
めちゃくちゃわかる
おだしょー そう新人として入って きましたってまた来てでもその
くせなんかテクニカルタウンは すげえ伝わるんだよなみたいな
新人なのに
そうあと実は早いですから 100秒のコードをなんか5秒ぐらい
考えたのにバッて出してくるから これは俺がタブを連打するより
早いと思う
おだしょー そうそうそうそう いや不思議な不思議なものですね
やっぱり
まあレチューショー面白そう ですよねレチューショー面白そう
なんだよな
おだしょー そうですね
テストに関する主な語尾 は
おだしょー なんかいっぱい話し そうな感じはありながらじゃあ取り
拾おうかって言われるとどうしよう かねみたいな気持ちになったんだ
よな
これでその反面でこの本一冊 通して言ってることが何か繰り返し
というか
おだしょー うん
これ緩末まとめでもいいん じゃないぐらいの感じで書かれて
ますね
おだしょー 確かにそうですね何か試しにちょっと
書いてあるものを挙げると完全な テストみたいな話とかテストが品質
を作るよとかあと分解の話があった りとか構成の話があったりテスト
なんてどれも同じみたいな今言った ようなことっていうのはテスト
なんて誰でもできるとかいうような ことっていうのはよくある間違い
ですよっていうふうに言ってます ね
これ読んでて付箋貼ってなかった から今思い出したんですけどここ
読んでて印象残ったのが三人の 登場人物の会話劇みたいな感じ
で展開されるんですよねこの章 悪いワインマグその章ごとに全然
やり方変えるみたいなのやりすぎ なんですけど1人がシステムテスト
というか結合テストみたいなもの をやってあるんだからモジュール
単位のテストってそれでカバー されてるでしょっていうふうに
主張しててもう1人がいやモジュール のテストをやる必要があるよね
って話をしててそこの矛盾を主人 公的な人が仲裁してくんですけど
なんて言ってたっけなユーザビリティ テストとか受け入れテスト結合
テストって言ったけどそれより 大きいレイヤーのテストに関して
テストの役割と誤解
は要求仕様に対してそこがない かっていうのをテストしてるんですよ
って話と確かにそれってシステム エンドツーエンドで大きく動か
してるからモジュール内部の部品 とかも正常に動作してるっていうこと
をある程度保証してるかもしれない けどモジュールレベルのユニット
テストとか結合テストとかっていう のは単純に実装が合ってるかどうか
っていうのを見てるだからそれぞれ やってる動作原理的にはやってる
ことが重複してそうであっても 目的が違うんだから別々で必要
でしょっていうようなことを言 っててまあまあそういうもんだよ
ねわかりやすい説明だなっていう ふうに思いましたね要求仕様
と意図とインプリメンテーション っていう言葉が出てきて
そうなんですよね
意図って挟んでるのがワインバーグ っぽいというか要求仕様を読んだ
人がどういうふうに解釈したか その人の頭の中で何が描かれてる
かっていうのが意図で実は要求 仕様に基づいて実装されるんじゃなくて
要求仕様を読んだ人の頭の中に 解釈されたビルドされた意図っていう
のに基づいてインプリメンテーション されてるよねっていう言い方
されててだから実装されたもの に対して要求仕様と合致するか
っていうのは別途テストする必要 があるよねっていう話でしたね
そうですねいやめっちゃわかります ね
うんわかるなって
そうなんよね結局できました テストも通りましたって言ったけど
いやそもそも要求仕様見出して おらんやんけみたいなことを言う
オチとかありますからね自分が 昔よくやってしまったことである
んですけど仕様書に書いてある ことを何か思い込んじゃって実装
して作って後でテストで何かおかしい ですって言われたことがあってあれ
何か仕様書に書いてあることと 自分が書いてあること全然違う
実装してるなみたいなことが度々 あったりとかして人間ってやっぱ
そんなにちゃんと物事見てないん だなっていうことをよく何ていう
か感じることがあったんですよね なんか数学の文章問題で数字だけ
拾って解いて間違ってて読み返したら ああなんだそんな言葉かみたいな
みたいなことをよくやっててそう なんだよなーみたいな
ありますよねここにメソッド あるじゃんって言ってやってから
しばらくして気づくみたいなテスト 書き始めたぐらいであれ要求しよう
と書いてること違うかって思って そうそう出て戻りをしてしまった
りとかして そこら辺で言うとやっぱりあれ
ですよね一回動かしてみるという か他人の目に晒してみるという
か完璧にする前にやってみるっていう のは効果的他人のリソースを強
いに借り入れてるって話ではあるん ですけど擦り合わせ大事ですよね
そうですねとりあえず動く もの作ってデザインはまだできて
ないけどこういう入力与えてこういう 結果が返ってくるってことだけど
合ってるみたいなことになった 時にそもそも違うんだけどって
先に分かったらもっと早くいろいろ 直せたのになみたいなことって
よくありますからね不確実さが 高いところとかの場合はよりそれ
が必要だったりしますからね でこの章のよくある間違い
の4番にソフトウェアをいい加減に 開発しっからテストの品質を高め
ればいいと思っているって書いて あるんでそういう考えじゃよくない
のかもしれない いい加減にがねいい加減で
作ってやるといいんですけどね メディアリがついてどこが大事
かみたいなところが分かって大事な ところから順番に潰していって
ちゃんとできたねっていうふう になるといい加減にできてる
気がするんですけど でもそうですよねここの
不安があるからテストではっきり させたいっていう見立てを持って
やるのと分かんないけどテスト を通せば全部見つかるんでしょう
っていうのは全くと言っていいぐらい 違いますからね
違いますね 今のAIとか機械学習とか出力
が一定にならないものとかって まさに不確実さが高いと思って
て AIに要約させる機能を作りましょう
とかでやるときにとりあえずデザイン とかどうでもいいからこういう
インプット入れて要約させたら 一旦こんなふうになったんだけど
こういうことで価値があるもの になるかなみたいないうような
ことって先に検証しようと思 ったらそれはテストで品質を高め
ようと思ってるわけではないけども みんなで触ってみてでもそういう
意味ではテストかもしれないな みんなで触ってみてこれちょっと
いまいちだねとかプロンプトに こういう指示を追加しないといけ
ないかみたいなことを考えると ある意味ではいい加減に作って
いると言えるかもしれないけど 結構大事だよねっていうのはあります
ね
おだしょー これよくある間違い の中で源井さん的に他に好きそう
なのありました
源井 そうですね よくある話なんだと思いながら
テストが品質を作ると思ってる とか昔はそう思ってたなと思い
ながら最近はテストする前に品質 を作り込みましょうみたいな話を
聞いたりするなっていうのを思 ったりするから 多分この本が出て
この本じゃないものとかの専門性 を持ってる人たちの専門的な本
の逆の観点とかで見ていくと多分 きっとまたテストが品質を作る
っていうか品質を作り込んでテスト をしましょうみたいなそういう
順番になってたりするとかあるん だろうなとかって思ったりしてます
ね
おだしょー ソフトウェアテスト 徹底指南書を早く読まないとですね
おだしょー 積んでありますね
おだしょー 積んであるっていう の
おだしょー 厚い
おだしょー 厚いやつ
おだしょー そうですねお粗末な テストの整理品質がお粗末になる
ことはあるがプロセスの他の部分 が全て正しく構成され実行されない
限りいいテストを行っても品質 を良くすることはできない 品質
を良くすることはできないか合 ってるか
おだしょー そうですねユニット テストをすごく素晴らしく書いて
いてもそもそも高経験の要求を 満たしていなかったら何の意味
もないですからね
おだしょー そうですね綺麗に動く クソができるだけだからな
おだしょー そうそうそう高速で ゴミをアウトプットする機械になって
いく
おだしょー でもこの章そんなとこ ですかね
おだしょー そうですね
おだしょー で10章はテストはキーを打つだけ
情報伝達のプロセス
ではないっていうすげえタッチ な章がありつつ
おだしょー ありましたね
おだしょー だからあれですよね これは糸を持ってサンプリング
しましょうっていうような話ですよ ね
おだしょー そうですね
おだしょー 11章からが情報伝達 のプロセスっていう話が始まるん
ですけどそれはですね査基谷さん の話を
