# タイトルコール テスティングジャーニーへようこそ。 このチャンネルでは、ソフトウェアテストの世界を探索するコンセプトに、 エンジニアリングマネージャー兼QAリーダーのサミーが、 ソフトウェアテストのコツや品相性の奥深さ、ソーシティビューを考えていることをお話しします。 # AI時代のソフトウェアテストは引き算│何をテストしないのかを決める こんにちは、さみぃです。今日もテストしていますか? なんか今週一気に涼しくなりましたね。皆さんの住まいの地域はどうでしょうか? 熊本もね、なんか絶妙なんですね。 夜はもう半袖で寒いんですけど、ちょうど部屋が日差しめちゃくちゃ入るところで、午前中はね、まだ。 部屋の中は29度とかになっちゃうんですよね。 でも風もすごいもう秋の風で、という感じなので、ちょっとね、体調崩さないように気をつけていきましょう。 ということで今回はですね、AI時代のソフトウェアテストは引き算。何をテストしないのかを決めるという話をしていきます。 きっかけはですね、Xの投稿とかでチラッとたまになのかな。 ユニットテストそんなにたくさん書かなくてもいいのでは、みたいな話とか。 あとテストピラミッドですね、のバランスがいわゆるユニットテストが一番多くて、 やっと1位は一番少なくて、みたいなところが逆なんじゃないか、みたいな。 そういう考え方も最近よく見るようになってきて、本当にそうなんだっけってちょっと私は疑問を感じているという話をしていきます。 まず最初に、そもそもテストピラミッドとはというところを頑張って、ソフトウェア開発に携わっていない方にも伝わるかな、頑張って説明していきたいと思います。 テストピラミッドというのが、そのテストをどう組み合わせるかという量のバランスを図に表した有名な考え方があるんですね。 このテストの種類というのが、ざっくりユニットテスト、インテグレーションテスト、E2Eテストというふうに一般的には言われております。 下からピラミッドを3等分というのかな、3段に分けたときに、一番下の多い部分ですね。 ユニットテストというのが、プログラムの単位で動作を確認するんですね。 サービスを使っているユーザーからは目に見えない部分のテストになります。 プログラムの、例えば1たす1やったら2になるよね、みたいな、またそういう電卓の足し算のロジックがあったとして、 その1個のプログラム、1個のメソッドの単位での行うテスト、ユニットテストというふうに言います。 誘導というかな、とても小さな単位なので、高速で実行しやすいというメリットがあります。 続いて、ピラミッドの2段目はインテグレーションテストです。 インテグレーションという言葉の通り、何かと何かを結合、統合させた状態でうまく統合できてるんだっけ、 統合というのはやめようかな、結合できてるんだっけというテストになります。 ポイントとしては、複数のコンポーネントとかをつなげた状態で、 例えばデータのやり取りが意図したものになっている方が、データの型とかですかね、 が合っているかみたいなところも含めて確認するのがインテグレーションテストです。 超雑に話しています。 一番ピラミッドの上の小さい部分が、E2Eテストです。 エンドとエンドの略なんですけれども、 一般的には実際にユーザーが利用するのに近い形でシステム全体を確認するというのですね。 ここのE2Eテストが一番ユーザー視点ではイメージがつきやすいと思います。 かぼやしの収録の例でちょっとお話ししてみましょうか。 E2Eテストが一番イメージしやすいと思うんですけれど、 録音ボタンを押します。 自分でこういう風に音声を喋って入れます。 停止だったり完了、収録完了と行った時に音声のデータがゴニョゴニョされて、 データベースに保存されて、 また自分のスマホの方で視聴というか再生としたら再生できる、 みたいな一通りの流れを確認するのがE2Eテストになります。 一方でインテグレーションテストというのは、 例えばこの音声入れてましたよね、この音声のデータの型っていうのかな、 とかがちゃんとVCサーバー側でとか、 VCのプログラムの中で想定したデータの種類として保存されて、 例えばデータベースに保存されているとか、 モバイルアプリとバックエンドのサーバーとのやり取りがうまくいっているかとか、 あるいはバックエンドのサーバーとデータベースのやり取りがうまくいっているか、 みたいなのを確認するのがインテグレーションテスト。 これだけじゃないんですけど、分かりやすく言うとね。 最後、ユニットテストは、 入力された音声のデータをゴニョゴニョ処理するっていうプログラム自体のテスト。 ざっくり言うとそんな感じでしょうか。 ニュアンス伝わりましたかね。 本題に戻ってくるんですけど、 テストピラミッドをこれまでというか一般的に用意とされているのが、 ユニットテスト、一番ちっちゃくて高速に回せるテストが一番量を多くして、 よりコストとかがかかってくるインテグレーションテストとか、 いずれテストについては量を少なくするというのが、 一般的なテストピラミッドの考え方でした。 これがAIになってどうなったかというと、 テストコードをガンガンかけるようになったということですね。 プログラム自体っていうのかな、 プロダクトコードをどんどんかけるようになったという話は聞いたことあるんじゃないかなと思いますけれど、 それはつまりそのプロダクトコード、プログラムに対応するテストコードも、 同時にたくさん作れるようになったということになります。 正確に言うと作れるようになったというか、 テストを追加する多数格、コストが下がったというだけではあります。 その追加されたテスト自体の価値があるのか、 意味のないテストがどんどん増えちゃってるんじゃないかという議論がまた別途あるんですけど、 ちょっとそれは置いておきまして、 AIによってどんどんテストの数を増やせるようになった結果、 どうなったかというと、 わけは分からないんだけど、とにかくたくさんのテストができました。 以上みたいな感じになってしまったんじゃないかなというふうに、 これも予想も入っています。 実際今自分のかかっているプロダクトでも、 どんどんテストコードっていうのは足しているんですけど、 じゃあトータルとして何を担保できているかっていうのを、 ちゃんと説明できますかっていうことですよね。 本来はテスト計画とか、テスト戦略でもいいですし、 組織のテストの方針でもいいんですけど、ポリシーでもいいんですけれど、 それぞれのテストの種類で何を担保するのかっていう責務を明確に分けて、 じゃあこの部分、テストコードというかインプテストはここまでをカバーしましょう、 っていうのがあって、方針があって、それにのっとってテストを作っていくっていうのが、 あるべきの姿ではあるんですけれど、 プロダクトコードベース、プログラムベースで、 このプログラムに対するユニットテストをこういうふうに足していきましょうみたいに、 どんどん足し算足し算でテストを追加していくと、 もう数だけ増えていって、 結局何を担保できているのかが分からなくなってしまう、 管理もできなくなってしまう。 じゃあ自分たちが管理しやすい、いいついテストを拡充していこう、 っていう思考になってないかなっていうのが、 最近そのXのとことか、いついか増えたほうがいい、 みたいな考え方の根本裏側にあるんじゃないかな、 っていうのを予想していたりします。 じゃあどうしていくべきなのっていうところで、 ここはまだ結論は出てないんですけれど、 今今私が考えていることをお話ししていきます。 SAIによってテストコード、テストケースもそうですけれど、 追加するコストっていうのはどんどん下がってきました。 そうなってくると、やっぱり何を作るかっていうのが大事になってきますよね。 どんなテストを作る必要があるのか。 これは逆を返す、裏を返すと、何をテストしないのかを決めることだったりもします。 ソフトウェアテストの考え方として、 全数テストは不可、無理であるという考え方がありますので、 全てのパターン、組み合わせを網羅させてテストするということは現実的ではありません。 もしかしたら、テストの作成するコストだったり、 実行するコストが下がってきているので、 無理という度合いが減ってきているのかもしれないんですけれど、 実際今起きているのは、人間の認知負荷っていうんですか、 認知の範囲を超えてしまって、キャップオーバーになってしまって、 管理できていないというのがポツポツ、そういう実証が起き始めています。 もしかしたら、結局どういうことを担保しているの? っていうふうに部屋に聞いたら教えてくれるかもしれないんですけれど、 今はちょっと私はそこまでは考えられていなくて、 何をテストしないのか、このテストは本当に必要なのかというふうに 追いかけながらどんどん引いていくということが大事になってくるんじゃないかなというふうに思います。 やれたらやったほうがいいなんてものは腐るほどあるので、 そうではなくて本当に必要なものは何なのかというところを考えて、 どんどん引き算をしていかないと、テストもプログラムの行動もそうですけど、 メンテナンスコストがかかっていくので、 足し算の、足し算コストが低くなった今、 引き算をどんどんしていくということがより重要になるというふうに考えております。 半編以上です。 # #658のコメント返し🥰 コメント出しのコーナーです。今回は658話目。 Taking Testing Seriously 12週目よりのコメントを開始します。 コメントはなっせひさんからいただいております。 プロポーザル採択おめでとうございます。 思考を解剖する。もっと書いて思考をしなければなりませんね。 ということでありがとうございます。 お祝いコメントありがとうございます。 めっちゃ嬉しいですね。 今回初めてワークショップをちゃんとしたカンファレンスでやるので、 はい、気合入れて準備していこうと思います。 ありがとうございます。 もしよかったらスクランプス沖縄にいらしてください。 はい、ということで以上コメント開始でした。 # 今日のほっこり話 今日の誇り話です。 髪飾りの話をしようかなと思います。 今だいぶ髪伸びてきたので、 髪の毛上げるやつ、何て言うのかな、名前がわかんないな。 ワシッて髪の毛を挟んでくれる 髪飾りがあるんですけど。 で、いつだろうな。 一番人生で髪長かったのが多分結婚式に向けて 伸ばしてた時かな。 だからその時ぐらいに夫が一個可愛いやつ買ってくれたんですよ。 何だったかな、誕生日じゃないかな。 とにかくプレゼントしてもらったやつがあって、また最近も髪伸びてきたんで ちょうどいいやと思って使ってたんですけど、 どうやら無くしてしまったようです。 で、それをね、いつ夫に伝えようかと思って タイミングを見計らって、ついこの間行ったんですよ。 そしたら、またやっぱり優しい人なんですね。 全然怒るとかなくて、えーって言いながらですね、 また無くしたの?みたいな感じですね。 そんな反応だったので、よかったなと思ってるわけなんですけど。 でもそれよりもね、見つからないのがとても悲しくてですね。 私の頼りない記憶によると、洗面所のその髪飾りとかをいっぱい入れている ボックスに入れたつもりなんですけど、そこになくて、もうそこにないとですね、 あともうわからないですね。どっかで外して置いてきてしまったのか という感じですが、本当最近忘れ物が本当に多くてね、なくし物とか多くて困っております。 何か良い対策がありましたら教えてください。 以上、今日の誇り話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございます。 明日の放送は書籍の紹介になっていきます。 テイキング・テスティング・シリアスリーの13章を読んで、 感じたことや心が良かったなというところをピックアップしてご紹介をしていきます。 今回の放送が役に立った、今日も聞きに来たような人で ハートマークいただけますととっても励みになります。 是非是非フォロー、コメントお待ちしております。 この放送良かったら是非周りの同僚の方とかにも紹介、シェアしていただけますととっても嬉しいです。 それではまた明日お会いしましょう。ごきげんよう。