テストの意義
エコーストが早めの方が早くつくっていうのが、ソフトウェア以外もあるから、そっちも大事だと思うんですけど。
てな感じで、第1章から盛り上がってますが。
そうですね、これ多分第1章だけで、無限にここから連想ゲームしたら話せるなって気持ちになってきたな。
第2章行きますか、早めに。 第2章行きましょう。
第2章もでも面白いからな。そもそもテストの役割とはですね。
で、ここでさっき言ってたテストとは情報収集するための行為だみたいな。
情報収集、あと提供することも含まれてるか。
っていうのが改めて語られてる章ですね。
そうですね。
最初から結構飛ばしてるんですよね。
なんかプロジェクトマネージャーとその上司のある日の会話みたいなところから始まってて。
で、プロジェクトマネージャーに進捗どうですかって聞いたら分かりませんって答えました。あなたが上司ならどうしますか。
で、3択あるんですけど。A、拷問にかけたらどうだろう。
B、ごますりを昇進させる。
イエスマンみたいなね、人は分かれませんとか言うアマちゃんじゃなくて、ちゃんとはい順調ですっていうやつを部下にするとか。
で、C、情報を集めてみては。
AとBいらんやろっていう気するんですよね。
これでAを進めますだったらめっちゃおもろいんだけどな。
それだとこの本の価値がないからな。
完璧なソフトウェア作るための拷問について話す。
怒られるな。
デマルコに怒られそう。
で、情報を集めてみるっていうのはテストの話ですね。
そうですね。
しかもその次はね、情報を集めたらいいんだね、よしって言ったら、情報によってリスクが減るとは限らないって書いてあっていいですね。
これはね、情報を集めるのにコストもかかるしねっていうのも15ページの真ん中ぐらいに書いてますね。
テストはゼロ時間ではできないし、タダでもできない。
で、また次があれですからね、コストかけて手に入れた情報を使ってない場合もあるよっていって、せっかくテストしてるのにそこ全部無視してたら意味ないよねっていう話も載ってますね。
そうですね。
実際現場でテストして、そこから得られた情報で自分たちがやってることって何なんだろうなって考えると、リリースしていいかどうかみたいなところは多分結構やってるっていうか、一個を判断するってやってるけど、あと何なんだろうなとかちょっと思っちゃったりしましたね。
テストの実践と課題
そうですね。ユニットテストに限らずか、ソフトウェアテストの定義で言うと欠陥があることを証明するものじゃないです。
それをパスしたってことはそれを否定するんですけど、コストをかけて、こういう欠陥があったら見つかるはずです。
言い方難しいな、欠陥がないことを保証するものじゃないからなテストは。
まあ、こういう欠陥はなかったですっていう。
それは今で言うとね、だいたいCIで回して全部パスしてるかだと思うんですけど、だから乱暴な話で言うとCIがパスしてるっていう情報は使ってません?
そうですね。なんかデグレが起きてないよねみたいなこととかは確かに。
あと、まあ開発プロセスのより具体の話で言うとテストが書かれてないプールリク辛いじゃないですか。
はい。辛いですね。
だからテストをしてるっていうのとは少しずれそうな気もするんですけど、テストが書かれてることによって掃除できる価値っていうのはありそうな気するかな。
確かに。何を担保しようとしてるとか何が大事そうかとか。
じゃあコードレビューするときにこのプールリク見てテストがこういうことを書いてるってことはここが本質的な実装一番大事そうなとこなんだなとか。
そういうのはありそうですね。
あとユーザビリティテストみたいな方向に行けば本当にこれって使えるんだろうかとか、戸惑わずに使えるんだろうかとか。
そういうようなテストをして情報、フィードバックを得て、実際にじゃあもっとブラッシュアップすべきなのか、このままリリースしていいかみたいなこととかはつながってきそうですね。
だからある意味プロトタイピングとかもテストですよね。情報収集のためにやってるから。
ソフトウェアのテストっていうよりか要求とか要件のテストになるはずなんですけど、まさにリスクを減らす手段。
意外とやってるな。意外とやってるけどでもびっくりするような、そういえばそれってこういうふうに使えるねとかっていうことはやっぱりないというか当たり前にやってるなみたいな感じになっちゃうな。
手に入れた情報を使ってない。確かにな。
結局現代においてテストっていう言葉ではなくて、早くフィードバックを受けて改善しようとか、早く失敗して次につなげようみたいな、そういう言い方に変わった気もしますね。
そうですね。
ただ失敗すればいいのかって言われたら、何の仮説もなく失敗すると本当に情報が得られないから、ちゃんと仮説を立てようねとかいう話が出てて。
でも結局その仮説を立てようねっていうのは、どういう情報を収集したいから、どういうテストをしてもらいたいから、実装したりとか、ペーパープロットなんか、フィグマだったりとか、実装するのか、AIにやらせるのかとかいろいろあるけど、そういうようなものを作ってフィードバックを受けるみたいな、そんな感じになってますね。
そうですよね。きちんとテストはされたのだが、誰もその情報を生かさなかったのかもしれない。その結果何が起こっているかっていうと、例えば受入テストぐらいまで、要するに最後の方まで進んでやった時に、インストールすらできないじゃんとか、
起動、ローリングで5分、10分止まったままなんだがみたいな話になると、それ見た人、このソフトはちゃんとテストされてないに違いないってすごい思っちゃうかもしれないよねとか。
そうですね。
各人とテストする人と直す人が全部、今時のウェブ経営の企業だと自分というか自分のチームだったりするので、チームの中にいろんなロールがあったりする場合もあるかもしれないですけど、
そうですね。
同じチームでも確かに起きなくはないけども、同じチームだと顔も見えていて、誰がどういうことをやっていてってことが見えてる状態ではあると思うんで、起きにくくなりそうだけど、ある種フロントエンドチーム、バックエンドチーム、テストチームみたいな職能で分けちゃったりとかすると、
テスト担当者とかテストの人がさ、とか言ってバイネームじゃなくてロールで呼ばれたりとかして、だんだん経営を払わなくなっていくみたいな話っていうのはあるあるとして言われるから、そういうとこにイメージは行きますね、こういう話を見てると。
そうですね。コストをかける人とそれを生かす人っていうのが他人ごとになってきちゃうと、せっかくコストをかけてきたのに無視というか軽視したりとか、別に自分は困らないしなーって言って、すごいよわからんテストをして結果レポートだけ書いたりとか、そういう話に繋がってきそうですね。
嫌な話ですね。
そうならないように組織構造をいじりましょうっていうのが、なんか昨今ずっとこの10年ぐらい言われてるような気がしますね。デブとオプスを分けるんじゃないとか、クロスファンクショナルなチームを作りましょうとか。
プロダクトオーナーが社外に行っていいわけないだろうみたいなね。
そうですね。
あとは第2章はあとはありますか。今話したのが前半っていう感じで、後半見ると人間の決定は合理的ではない感情的であるとか、下手なテストをするぐらいならテストしない方がマシなこともあるとか、製品がテストする段階にないのかもしれないが後半に書かれてる。
そうですね。下手なテストするぐらいならテストしない方がマシなこともあるを見て、ちょっと違うんですけど、PHPユニットのテストとかで、モックばっかりされててこれ何テストしてるんだろうとか見るとむしろテストない方がこれ明定しなくていいからいいんじゃねって思ったこととか。
テストの価値とリスク
企業これ何のテストしたかったんだっけみたいなやつは自動テストとかではたまに見かけたりとか過去に書いてしまったなって思ったりとかいうのはあったりしますね。
あとなんかでけえJSON2つ比べてアサートセームというかアサートイコールズJSONストリングズ、違うか、なんか名前が長いJSON比較のアサートに入れてオッケーみたいなテスト書かれてると、どこがオッケーだみたいな。
メリハリがないというか。
けっこうどこが壊れてないことが知りたいんだろうみたいな。全部ですみたいな。
全部なわけないだろうって。
そうですね。
そうなんかテストされてるんだなーってなっちゃうのがよくないですよね。
うんうんうん。本当にテストされてるのかな。
いやなんかそれこそLLMとかコーディングエージェントとかにドキュメント書いてて言うとすげえ立派なリード名書かれて、いやこれ使い捨てのスクリプトマンナーみたいな気持ちになったり。
ここまでやられると俺がすげえメンテしますみたいな雰囲気出るじゃんとか思ったりしますよね。
いやー。
勝手にロードマップを書くんじゃない。
作らん作らんみたいなね。
バージョン2なんて作らんから。
いやー。
うんうん。
まあでもそうですねそうですね。
あとテストそうですね。やっぱテストの意図みたいなところは全部大事だなってなって、下手なテストをするくらいしない方がマシみたいなのも。
なんかこういうユーザーが全くやらなそうなことをやって、まあ確かに不具合が見つかるかもしれないけどそもそもそんな使い方しないんだったらそのテストする、そこを担保したいってどういう意図なんだろうみたいなことがあったりとか。
それでまた不具合が見つかって、それを一生懸命直してみたいなことをやってるとすごい時間とお金をかけてるなみたいな気持ちになったりとかして。
そういうのを見ると、確かにそれは直した方が500エラーが出ないようになるとか、ユーザーが期待したものとは違うものが出ないようになるんだけど、どこまでそれをコストかけて直すのかとか、
いや別にリロードしたら復帰可能なんだから、リロードしてくださいでアナウンスして終わりでいいんじゃないみたいなとか、そういうのとかはたまにこう、確かに壊れることを見つけようと思っていろいろやるっていうのはあるんだけど、
そのテストにどれくらいの価値あるのかな、なんならテストしない方がマシだったりするんじゃないかなみたいなことをちょっと思うことはありますね。
プロダクトコード側で、なんかその防御的な書き方やめて事前契約とか明確にしておいた方がきりするんじゃないとか、そもそもそんなに防御的になる必要があるってことは使い方を間違われやすい設計、デザインになってる。
だから設計が良くないのにテストでそんな頑張るなよみたいなね。
ますね、無限の歩いて帰れた瞬間に無限のパターンがあるじゃんみたいなこと言われても、まあそうだけどみたいな。
で、さっき言ってたテストがリスクとかを中心に情報を収集して提灯することっていうのが本質的な目的だよっていう話で言うと、やっぱり下手なテストであってもそれだけそこから提灯される情報っていうのが増えるので、ノイズが増えるっていうことにはなるんですよね。
そうですね。
って考えると確かにない方がいいなみたいなあってもなくてもいい情報で溢れて本当にフォーカスするべきところにフォーカスできてないってなると非常になんかだるいので。
テストの役割とリバクター
そうですね。難しいですよね。でもそれって一回いろんな情報を見てきたからこれはノイズになりそうとかわかるけどとか、実際やってみてノイズだったなってなってから減らすものであって、ノイズになると思うんでこれはやりませんでしたっていきなり最初に言われると本当にみたいになっちゃいそうだし、
ちょうどいい塩梅とか、なかなか難しいよなとか、あとはその観点では確かに必要なかったんだけどちょっと状況が変わって違う観点になった瞬間に、なんであの情報ないんだろうみたいなこととか起きそうだよねとか、そういうのも含めてやっぱり完璧じゃなくてテストって何のためにやってんだろうねとか、このテストの役割ってなんだろうねみたいなことを考えておく必要がありそうですね。
そうですね。そうだからテストもちゃんとリバクターの対象なんだよっていうのは意識しておかないといけないんだけど、プロダクトコードはなんかそろそろリバクターすべきタイミングだなって見やすいけどテストは、
テストは有定CIAをずっと突破させ続けてるから、あんまり腐ってる腐ってないが判断しにくいというか、それを放置することによってどのくらい困るかっていうのが見えにづらいので、テストのリバクターのタイミングちょっとプロダクトコード側よりかは難しかったりするなとか今話を聞きながら思ってました。
なんか極端に遅いテストとかはね、このテストがなければ早くできるのになとかは目に見えてわかりやすいんですけど、じゃあ0.1秒で終わるテストどうしますかって言われたら、あってもいいんだけどこれなくていいんだよなみたいになった時にその消す理由をちゃんとこう作らないといけないっていうのが難しいというか、相手がそうだよねって言ってパッと話が分かればいいんだけど、
みんながみんな同じ視点に立って喋ってるわけじゃないんで。
パフォーマンスならね、まだ定量化されてるからわかりやすいですけど、意味的にここダブついてるよなーとか、特に勝ちないよなーっていうのが難しくて、しかもなんか好みの問題になりがちだったりするので、余計にムムムってなりつらいっていう。
そう、ほんとそう。しかも例えばそれはあるフェーズにおいてはとても役に立つ。例えばモジュール単位で設計してて、本当に最初の頃にこういう値が返ってくることを保証したいと思ってテスト書いて、良かったねって。でももうちょっと大きいコンポーネント単位でテスト書いてるから、それいらなくないってなった時とかって
消せばいいんだけど、でもそのフェーズが違ったよねみたいな認識を揃えるっていうことをまず最初にやらないといけないとかなると、消すコストがめちゃくちゃ高いんだよなーみたいな。
そうですよね。 今にはそれが手動テストとか回帰テストとかシナリオテストの中に紛れ込んでいたら、なんかもっと大変ですよね。
そうだからチェックリストがだんだん分厚くなっていく問題と同じことが起きますからね。 そうそうそう。いやーいいですね。テストの役割だけでやっぱテストいっぱい喋れるな。面白いな。
よくある間違い触れてきますか。さっき言ったテスト担当者に敬意を払わないとか、テスト担当者に敬意を払いすぎるっていうのもあると。 逆もありますね。
これはあれじゃないですか、サティアさんの自分他人情報のやつに。 うんうん。確かに。
感情の話触れてないか。合理的ではなく感情的な決定を下すっていうのがよくある間違いに書かれてますが。
でもなんか俺別に人間ってそうじゃねって思ってるから、よくある間違いっていうか、そんなもんじゃないって思っちゃうんだけど。 なんですかね、共有できる論とがない、ひとりよがりっぽいみたいな話なのかな。
これはもしかしたらカーネマン以前以降で人間の見方が変わってる可能性がある。 本当に変わったかどうかが怪しいやつ。
まあでもそうですね、例えばなんかもうリリース日決まっちゃってるんで、この日まで作らないといけないけど、クリティカルな不具合が見つかっても、いや、ええやつってリリースするみたいな。
まあ確かに、いやなんか最近はそんなものを見ない気がするけど、しれっと出して見て爆発して、プロダクトが1週間後には停止になりましたみたいなとかありそうですよね。
ゾッとするの。でまだこの話であった、大井に語るかな。大井に語るより前に読んだ本でもあった気がするんですけど、何だっけ、欠陥を見つけたら報酬、インセンティブがあるっていうので、開発者とテスターで結託して。
バグ埋め込んで報告をするみたいなやつ。
とかもあれも感情っていうよりかはすごいロジカルな、実際にインセンティブの最大化みたいな話ではありますけど、多分この本でいう感情的な判断っていうのにはああいうのも含まれるかなっていう気がしますね。
製品がうまくいくかどうかっていうよりは自分の感情を一番優先した結果そうなるみたいな。
すごいな。よくある間違いが12個もある。
よく間違いすぎだろみたいな。
自分と考えが違うからといって他人の決定を合理的でないと決めつけるっていう間違いがあるらしいですよ。
そんなテストって。
チーム内の協力とプロセス
テストっていうか人間の話なんだよ。だからここら辺の話になってくるとあんまりテスト担当者っていうのが別にいる状況をちょっと僕は当事者的に想像が、経験がないのでしづらいので、ちょっとピンとこないんだよな。
自分は今のチームでテストがメインのロールの人が同じチームにいたりとか、最初の現場がいわゆるSIみたいなやつだったんでテスト部隊みたいなのがいて、
エクセルにそのテスト不具合があると不具合レポートが書かれてそのエクセルが飛んできて、再現手順はこうなっていて直してくださいみたいなのがあって、直してまたその担当者にそれを返してテストしてもらうみたいな。そういうのやったことありますよ。
なるほど。
部屋が仕切られてたりとかしてね。協調を促されないなみたいなことが起きてたりしましたね。実際は隣の部屋だったんですごい行ったり来たりして仲良くしてましたけど。
セキュリティチェックとか監査的な話は結構こいつ何言ってるんだろうっていらつかされたりしたから、あれと同じなのか。同じなのかな、わかんないけど。
あとはもしかしたらあれじゃないですかね、脆弱性診断みたいなやつはちょっと近い形かもしれないのかな。
そう、それのイメージでした。でもあれだな、セキュリティチェックシート記入してくださいもいらつくから。
出た。
セキュリティチェックって言うとそっちか。
うん。
監査めんどくさいんだよな。
まあめんどくさいけど第三者の視点が全く入ってないっていうのも。
いやそう、大事ですからね。プロセスとかルール作りからコラボレーションするのにミスると非常にめんどくさい。
そうですね。対立行動になっちゃったりとか。
あの人たちは別に敵じゃないんでね、基本的に。
そう、そうそうそうそうそう。身構えちゃうんだよな、でも。
なぜファイティングポーズを取るんですかみたいなことがね、多分いっぱい起きてると思うんで。
嫌われ者ガチですからね。
そうそうそうそう。やばいですね。我々たぶん2章に入るとこまででもう1時間喋ってますね。
まあでも結構大事な話はこの1、2章かなみたいな気がしますね。そもそものこの本のテストっていうものに対する考え方とか前提みたいなところ?
うん。魅力的なタイトルの章はたくさんあるんですけど。
章は…
章は振れるか。
全部テストしたらいいのでは?って言って、はい。
全部テストするってどういうことなの?
