00:05
はい、みなさんこんばんは。株式会社ゆめみでチャレンジ取締役をしておりますキースことくわはらです。
Web 業界のなんでも雑談室へようこそ。この番組ではWeb 業界に関することや様々な雑談などの情報を発信していきたいと思います。
日曜日の夜っていうか、日付が明けて、実はもう月曜日なんですけども、今日も収録していきたいと思いますが、前回ですね、
自動テストのお話、e2eテスト、エンドとエンドの略ですね。e2eテストのフレームワークのツールの名前をいくつか出して、
タイトルにもありますけど、Cypressっていうフレームワークがとても良いぞっていうお話をさせていただきましたし、
自動テストの素晴らしさっていうところの魅力をお話しさせていただいたんですけど、一方で今回はですね、その続編と言いますか、
とはいえ、テストは素晴らしい、そうするとじゃあテスト絶対書けばいいじゃんとか、テスト書けば信頼性とか品質もどんどん上がっていくじゃんみたいな
風に聞こえたような話になってしまったので、ちょっと補足と言いますか、一方でその難点と言いますか、
ネガティブなところもちょっとお話をして、どこ付き合っていくかみたいなところに終わらせていきたいかなと思っております。
前回はe2eテストだったんですけど、あとソフトウェアテストも自動化っていうところでいくと、ユニットテストも自動化というのがありますね。
他にインテグレーションテストとかファンクショナルテストとかテストの種類がたくさんあるんですけども、その話はまた別途、もし需要があればやろうかなと思いますが、
大きく分けてそのユニットテストっていわゆる単体テストですねっていうものと、あとはe2eとかですかね、エンドデーのテストのところを自動化することが僕らプログラマーではよくやる自動テストなんですけども、
あとユニットテストのところをしっかりガッツリやれば、別にe2eとかとかのテストに関しては品質は担保できますよみたいな風な方針を取っている会社さんもあって、僕はそれはそれで一つの答えとしてはいいと思っています。
要するに所詮ですね、僕らがやること、アプリケーション、ウェブアプリもそうですけど、システムとか管理したいことっていうのは基本データなんですよね。
データをどう管理してどう渡してどう表示していくかっていうところに尽きるわけなんですね。
つまりデータの整合性が取れていれば、極論言ってしまえばシステムとかアプリケーションの品質の担保はできるっていう話なんですね。
ちなみに余談ですけど、品質イコールバグがゼロっていうわけではないです。
別にバグがちょっとだけ残ったとしても、お客さんとかエンドユーザーのユーザビリティが拡大に高いならばそれは品質高いって話になるので、そんな感じで品質って一言で言うといろんな面があるので、
今回はテストなのでバグの少なさっていうところが品質っていう言葉の意味だと思っていただければ良いですが、話戻しますと、
テストを書いたりすると品質が高いかっていうところなんですけども、
一方でそのテストそのものを書くのもやっぱり人ではあるので、そういう意味でテストそのものが信頼性が高いかっていうと実はそうではなかったりするわけですね。
03:08
というのも、例えばテストケース1000件書いたとするじゃないですか。
アプリケーションの2、3画面のテストを書いたら合計満数、例えば1000ケース入りテストケースになったとしましょう。
実行すると赤色、いわゆるテストが5桁っていうケースが例えば3件ぐらいあったとするじゃないですか。
3件バグがあるので、もちろんプログラマーとしては直さなきゃいけないんですけど、
その時判断できることとしてテストが間違っているのか、そもそもアプリケーションがバグっているのか、
もしくは仕様そのものが本来間違っているのかっていうことが3点あるわけなんですよね。
ということはテストが5桁って時点でその3点について観点の調査をしなきゃいけない。
そうなってくるとテストコードそのものの品質をそもそも考えていかなきゃいけないんですよ。
なのでテストを書くこと自体に割とコットはかかるんですよ、実際問題。
ビジネスインパクトとしてそのテストの工数をかけるとエンジニアが動かなきゃいけないのでお金もかかるんですよね。
時間もかかるしお金もかかるんですよ。
その上、お誘導をかけるように言うんですけども、テストコードが正しいかっていうとだからといって品質が正しい。
テストの選権を書いたとしてその選権が全部グリーン、つまり全部テストが通ったとなったとして、
本当にそのテストって信頼できるのかっていうとそうではなかったりするんですね。
というのもテストが通るような行動をエンジニアがかけちゃうわけなんですよ。
だから本当はコケてるかもしれないですけどエンジニアが年をごまかすというか悪意を持ってそこは通すような行動を書いた可能性はあります。
もしくはエンジニアが書いたテストコードがたまたま間違ってるんですけどたまたま渡ってきたデータには通ってしまってるから見えてない。
潜在バグみたいな可能性もゼロではないんですよね。
ということを考えるとテストそのものの信頼性でどうやって担保するのかってものすごく難しいというか永遠の課題なんですよねと僕は思っています。
もちろんケースバイケースでこれに関してはちゃんと担保できますみたいな話もあったりするので一概に言えないですけど、
テストっていうソフトウェアテストの自動化っていうところでどんだけ信頼できるかっていうとやっぱり同じプログラマとしたら
そこってあなたたちはそれ全部通ってるって言うけどその通ったっていうテストそのものの信頼をどうやってあなたたちは担保してますかって結構突っ込むと痛い質問だと思うんですよね。
逆に疲れてもやっぱり痛くてですね。僕らもそれをどう答えるかっていうのはものすごく難しいんですよね。
というのもあってお客さんにテストコード書かせてくれって言ってそのコースでお金もくれって言うけど、
お客さんからするとそこってプロダクトの開発のコードじゃないわけですからそこにお金をかけるってなんで端子になるわけで、
それだったらもう僕らの自分たちっていうお客さんの方でできあがったシステムをしっかり叩いてバグ見つけたりとかテスト確認はしますよっていう風にお客さんもおっしゃるわけなんですよね。
06:08
それは正しいしその意見は間違ってないんですよ。
ただテストを実行するっていうのは前回言った通りですけどテストする人間そのものがバグっているというか間違う可能性がよくある話で、
人間ほど複雑系かつ間違いやすいものもなかなかないと思っているので、やっぱり自動的にテストを実行してくれるっていうのは本当にいいことだと思いますね。
実行速度が圧倒的に人型より早いですし。
その兼ね合いもあってどっちに舵を切るとか、この先の長い店を見た時の端子をどうするかっていうのを試してテストを書くか書かないか決めたり、
書くとしてもどうやって品質を担保するかってところを試していければいいのかなと思います。
僕がやることとしてはテストを実行するんですけど、実際エラーがあったりしたらそのエラーはやっぱりお客さんには共有するのがいいのかなと思います。
で、コケたとしてもそのテスト実行の日付とかをどっかでメモっておいたりとか、そのカバレッジっていうものを書き出すんですよ、テストを実行すると。
いわゆるそのテストの結果のドキュメント化することですね。
カバレッジって言うんですけど、広い意味でね。
厳密な意味はちょっと違いますけど、そういうふうに思ってもらえればいいです。
そのカバレッジを取ったときに、その日付とかを出して、そのときに全テストケースを流して、OK、NGとかっていうのをちゃんと記録しておくところが大事ですね。
その後に修正して、もう一回テスト全部実行したらこんな案件、バグで案件通りましたっていうのを一個一個記録していくわけですね。
その実行した回数とか、あとはそのエラーの件数、テストケースの件数とかっていうところを加味して信頼性っていうのを担保していくってところだと思います。
ちなみにテストコードも書こうと思ったら無限に書けるんですよ、テストケース自体無限に書けるんで。
ただ単に数が多いからといって信頼高いかっていう層ではないんですけど、
ただ数が多くテストを書くことってやろうと思うと結構難しかったりしてて、
無限に書くって明らかに無駄なコードは書けるんですけど、そういう無駄じゃなくてテスト件数を増やすっていうのは結構難しいんですよ。
それだけちゃんと叩いたよってことなんですね、アプリケーションとかシステム。
という意味でやはり件数が多いっていうのはありかし無視できないなっていう風に観点としてはあるんですね。
なのでそういう件数が多くて、なおかつエラーとかがあったとしてもそのエラー件数何件だっていうのも全部記録しておく。
その何回も実行したっていうその過程が信頼性につながっていくのかなと僕は思ってます。
なので人が1,2回テストしたよりも自動テストにして10回以上叩いて修正をとかいうサイクルを繰り返したって言われたら、
その10回も繰り返した方が絶対に信頼高いっていう風に思われると思うんですよね。
というのがあるので僕は結構テストってそういうところで品質を保っていくのかなと思ったりします。
最終的には性善説に乗っからざるを得ないところはちょっとありますね。
09:00
このベンダーさんとかこの開発会社さん、もしくはこの担当者の人だから信頼できる、
その人が実行した、もしくはその人が管理した、もしくはその人が実際に書いたテストコードだから信頼できるみたいなところもあると思うので、
最終的には性善説にちょっとつながると思うんですけど。
それでもやらないように絶対やった方がいいと思いますし、自動化っていうところのメリットは本当に大きいですね。
今後リリースした後にも機能を追加したりとかいろんなものを回収したりの時に、
もともとあった機能が本当に動くんですかってそういうリグレッションテストとかをする時も、
もともとのテストコードがあったらもう一回それをガッて流した結果OKだったら、
基本的には通るはず、動くはずなんですよね。
っていう信頼性は一気に上がるんですよね。
というのもあるので、長い目線で見てもやはりテストコードを書く、
それを自動化するっていうのは私はメリットが大きいと思うので、
できればテストコードを書くようにした方がいいんじゃないかなと思っております。
そういう話をしたかったですね。
もちろんデメリットもあるけど、メリットも大きいですよっていうのを加味して、
今後プログラムとかエンジニアの目指す方、今やられてる方はTEDと付き合っていければいいのかなと思っております。
そんなところで今日はお話ししたいと思います。
また何か聞きたいことや話してほしいことがありましたらいつでもレッターをお待ちしておりますので、
気軽に投げていただければなと思います。
ではまた次回の主力でお会いしましょう。
次回は一旦エンジニアと話から外れて、
久しぶりにただの雑談というか、自分の趣味についてちょっとしゃべろうかなと思いました。
洋楽の話ですね。
では次回の主力でお会いしましょう。
バイバイ。
