この番組は駆け出しエンジニアの順平と先輩エンジニアの海一則が送る駆け出しエンジニアを中級エンジニアにキャリアアップさせるラジオですはいということで本日ですがプロポーザルにプロポーズしてくれた人がプロポーザルにプロポーズえーすごい番組史上2回目ですか

確かに本日ですがQAに関してですね以前不動産検索サイトのテストをどこからどこまで何やりゃいいんだどうしようでも俺らじゃ分かんないプロポーゼルお待ちしてますというくだりがあったんですけどドスペシャリストの人が来てしまったので今日はすごい俺らが勉強してひまプロリスナーも勉強していいテストが書けるようになろうという回になります

楽しすぎます本編楽しみすぎるんで早速紹介させていただきますブロッコリーさんです自己紹介よろしくお願いします

はい、ブロッコリーです。すごいハードルを上げられたところから自己紹介になりますが、株式会社10Xで品質管理部に所属しています。QAエンジニアのブロッコリーです。自己紹介ということで軽くお話しますと、10XというところでQAエンジニアをやりつつ副業もしていまして、いろいろな会社さんでどういうふうにテストをやればいいんだろうというところに壁打ち相手になったりとか、

あとは社外講演とかをしてテストのことをいろいろと話しています今日はよろしくお願いしますよろしくお願いします本書かれてたりコード人で連載されコード人でしたっけコード人で連載されてたり

コード人は講師のことをしていたりとかあとはソフトウェアデザインですねソフトウェアデザインの雑誌の方でちょっと書いたりはしています我々が見るリファレンス作っちゃってる人みたいなすげー確かにちなみに全然関係ないんですけどこの番組一番最初のプロポーザーはほうれん草ボンバーさんという人から来たんですけど結局

比較的野菜の名前を持ってる人からプロポーザル来やすいなと思ってすごい確かに3人目プレッシャーですねそうですね野菜の名前じゃないと本日ですが前お話ししてた不動産検索サイトを例にとって

非常に検索がすごい複雑ですね不動産検索サイトは駅名なのかな駅名とか何分駅何分浴室乾燥機ありなしとかそういう細かいのまでいろいろ検索条件がたくさんある中で全部言いついてやると大変だしというかほぼ無理だしエンジニアとしてどう品質担保していくかというところをブロックロイさんに

ご教示いただきつつ我々もガンガン質問してみんなが分かってみんなテストできるようになるというのを目指していこうと思いますお願いします日本のシステムの品質が上がるんですねこれでそうです素晴らしいすごいどんどんどんどんハードルが上がっていって伝えるというかみんなで作っていきましょうじゃあ早速振っちゃっても大丈夫ですか

はい、じゃあブロコリさんお願いします自分がプロポーザルを応募しようとしたときにそのときに話していたやつで物件検索で大宮駅で検索してそれで期待した物件が出るよねみたいな話とかあとは

先ほどおっしゃっていたように大宮駅から徒歩10分とかあとは家賃の話ありましたけど他にもいろいろ細かい条件の検索が実際物件検索のサイトはあるんですけれどもそこの中でじゃあ例えば

その中で徒歩の話っていうと大宮駅から例えば徒歩10分とかっていうところの期待した物件が出るよねっていう話って多分これおそらく発言会地さんがされてたと思うんですけどそのテストをしたいって思った時に具体的にどういうことを気にしてますかね

どういうことを気にして期待した物件が出るみたいな話をしたのかなっていうのをちょっと掘り下げたいなと思いますそうですね大宮駅徒歩10分の物件を検索したときの期待値として何を期待してテストを書くかって話ですよねもしくは何を気にしたのかどんなバグが出るだろうバグるとしたらどういうところがバグるんだろうなっていうのを予想したのかそういうのをちょっと聞いて

はいそれで言うとそうですね入力されてされたその徒歩10分なんとなくその2つかな徒歩と10分っていうクエリが投げられて検索されるみたいなイメージなんですけどその徒歩の10分っていうのが裏側で動いて検索されて帰ってくるかどうかを気にしてテストを書くと思いますなるほどつまり

今の大宮駅10分っていうのをE2Eとしては10分で入力をしてその結果10分以内の物件が出てくるっていう入力してから結果の画面が出るっていうE2Eで見たら全体

今言った一連の流れなんですけどもう少し細かく区切って考えることができると思っていて今の話で言うと例えば徒歩10分で検索したときに検索条件にデータとして引っかかるかどうかの話例えば徒歩10分以内っていう話だったら10分だけじゃなくて徒歩5分の物件とかそういうのも引っかかるはずで

検索したその条件にデータとして引っかかるかどうかっていう話とそれが画面として表示されるかどうか表示されるかどうかっていうのは例えば徒歩9分の物件Xっていうのがある前提でそれが画面としてちゃんと物件Xで徒歩が9分って表示されるかどうか

っていう風にまず区切ることができると思ってるんですね与えた検索条件に対してデータを引っ張ってこれるかの話とそのデータがあること前提で表示されるかっていう風に2つに分けるとしますと

そうすると検索条件に引っかかったデータが取得できるかどうかは実はこれE2Eで気にしたいことではないと思うんですよねデータを拾えるかどうかっていう話なのでこれはAPIレベルであったりとかもしくはユニットレベルでテストで担保した方が

方がいいと思っています一方でちゃんと表示されるかどうかっていうのは例えば画面で気にしたい画面の表示で気にしたいのってその物件が出てきたときに何とか駅徒歩何分っていうほにゃらら駅っていうのと徒歩

なんとか分っていう風に表示されてることが大事であってそこの中身の数字9分とか大宮駅とかっていうその表示自体はそれはデータとして持ってきてるからそこはもうそっちのちゃんと拾えるかどうかのAPIレベルの方で担保してるから別にいいですとそれがちゃんと

何とか駅で何分っていうそこの表示がされるといいっていうレベルの言い継いでやってもいいんじゃないかなと思ってそうすると何がいいかっていうと物件情報なんてどんどんどんどん更新されていって徒歩9分のものがなくなったりするかもしれないその検索をしたと

その時にE2Eのテストが今まで通ってたけど落ちました徒歩9分っていうのを期待値として取っていると検索した結果E2Eのテストが落ちましたじゃあなんで落ちたんだろうっていう風に調べると実は徒歩9分の物件がそもそもなくなってしまった

とかっていうのはあり得るわけでそれって別にE2Eで失敗にしたかった話ではないと思っていてさっき言った何分っていう表示がされることが重要だとしたら期待値をもう少し緩いというか何分っていう表示が出るかどうかぐらいの期待結果にするっていうので

本当にそもそも何分っていうのが出ないっていうようなバグを見つけたいっていうのを言い継いで担保したい繰り返しになっちゃいますけどそもそもそういうデータが拾ってこれるかどうかっていうのはAPIとかユニットレベルでやればいい

なおかつリクエスト投げてそういうレスポンスが返ってくるっていうのはAPIレベルだしあとはそもそも10分以内っていう徒歩10分以内っていうのを投げたら10分のものは10分は返ってくるけど11分は返さないようにするよっていうのは多分ユニットレベルでテストコードとして書けるはずで

っていう風に実は今まで言いついで何でもかんでもやろうと思えばできるんですけどその中でそこの何を確認したいのかっていうのをもう少し細かく区切って見てみるといやこれ全部言いついでやる必要ないよねっていうのが見えてくるかもしれないなって思ってます楽しい話すいませんちょっといろいろ聞きたいんですけどはいぜひぜひはい

大きく今のテストのどこからどこまでをどのレイヤーで担保するかって話で言うと多分E2かそれより低いレイヤーか多分今大きく分かれてたように聞こえてます何で分かれてるかというと本当に表示かロジックかですかねっていう風に分かれてるように聞こえてて

ここまでって認識あってます?ありがとうございますE2Eの表示で担保すべき部分っていうところがまだ理解しきれてないんで聞きたいんですけどさっきの徒歩何分っていうような話で言うとE2Eなんで全部実システム使ってテストすると思うんですけどそういうE2Eのテストって

テストに使われるデータが消えたっていうことがあり得るみたいな話されてましたけど割と固定されたテスト用データ使うっていうよりは現状の商用データ突っ込んでやるみたいなケースが多いんですかねどっちも全然あり得ると思います実際にテストとして絞って

テスト用のデータを用意するっていうの全然ありますでそこが固定できるんだったらその方がいいんですよただそれが実際の例えば本番環境でのデータを使うときにテストデータを本番環境に入れられないとかあとは実際のテスト用の環境があったとしても

何日かに一度本番環境から同期されてその結果テストデータが消えちゃうとかっていう場合もあるのでその場合はさっき言ったような話ですけどもちろんテストデータとして用意できるとか自動テストE2Eの自動テスト用に環境を用意できるんだったらそういう固定したやつを用意するのは全然アリだと思いますなるほど

そうですねじゃあE2Eで使用するデータがある程度不安定っていう言い方があったのかな不安定の可能性があるから朝後ちょっとゆるくするというかっていうのも考える必要があるんですねでそのさっきの大宮駅徒歩10分の例だとどうゆるくするかっていうと結局どうなんでしたっけ徒歩10分じゃなくて5分が

あるのも想定して徒歩丸分があったらOKにするみたいな意味ですか?そうですさすがに10分以下の物件が全部消滅することはあんまり想定せずにっていうイメージですねそうですね何かしらあるでしょうっていうところでそのぐらいの許されっていう感じですね

じゃあその言い継いテストってスナップショットのテストも取れるかと思うんですけどスナップショットテストというよりはページ全体の中で徒歩丸分の物件が含まれているぐらいの緩さはいはい

あーなるほど少なくとももちろん何分とかさっき言ったように固定されたテストデータでやってその固定されたテストデータは9分とかになってるから9分っていうのを期待値とするのも全然ありだとは思うんですけど少なくとも

まあイーツイートしてやりすぎだろってなるのはさっき言った例えば東北10分以内で調べたときに9分の物件は出る10分の物件は出る11分の物件は出ないみたいなテストをやる必要はないっていう感じですかねうん

教会自分活なんでしょうユニットテストとかでやりがちな教会自分活みたいな間を基調面で見ていくみたいなのはあまりやらないってことですねE2Eでやると何でもテストを実施はできるのでそういういろいろなパターン網羅するパターンを用意したいって思っちゃいがちなんですけどそれはE2Eでやるべきではないというか

基本的な考え方としては言い継いでそれができたとしてじゃあそれってAPIレベルのテストとかユニットレベルのテストで実現できないのかなって考え直すことが大事だと思っていてそっちでユニットとかで

テストできる話だとしたらじゃあそれはユニットの方に持っていってE2Eでそこまでいろいろなパターンのテストはなくそうテストパターンというかテストケースの数を減らそうっていうそういう動きになった方がいいと思うなるほどそれでいうとE2Eでやるべきはやっぱ表示だと思うんですけど表示でも何でしょうねGUIの方のユニットテストとかに

映せるものとかってあったりするんですかそうだろうな

ジェストとかだとスナップショット撮れてHTMLで一応全部撮れるみたいなのはあると思うんですけどあれって使い道何なんだろうとかっていうのはよく分かってなくて全然あるとは思っていてむしろそっちに移せるんだったら移しちゃった方がいいとは思います結局E2Eでの自動テストって一番コストがかかるのでHTMLの構造を

でのテストっていうのができるんだったらそっちに移した方が全然いいん 今後さえコストがかかるっていうのは時間とかロー実装の労力とかって話ですか両方ですねえっと労力もそうだしあとは実際にテストをするってなった時に なんだろうなその

動かすための環境を用意しなくちゃいけないとかっていうのが結構手前になるんですよね確かに確かになるほど実行もめっちゃ重いしねそうですね確かにめっちゃ時間かかりますねHTML構造だとテストでいう単体テストのフレームワークじゃないなライブラリでできるから実行が軽いっていうそうなんですねなるほどはい

その html での比較ができるできないっていうその 運気点はどこなんですかねやっぱ見た目をお客さんが気にするかってお客さんなのか po なのかというところなんですかねうーんそうです スープをだろうの水でのっていうところで言うと8見た目が動向というよりもあとは

実際にボタンをクリックしたりとかの操作のところを疑似的に自動テストでやるっていうところが多分E2Eテストジェストではなくてやるところのメインだと思っているので画面の遷移をするっていうところがメインになってくるかなと思います画面の横断遷移そうですね

まあなんでちょっと今ジェストとジェスト みたいなものと言いついの自動テストの比較とか言いましたけれども まあそれだけじゃなくてユニットとか api の話で言うと ちょっとさっきの物件検索た別の例になってしまうんですはい例えば 会員登録の8

一般的な会員登録をイメージしていただいて会員登録のところのテストっていうのを考えたときに例えば会員登録するときのパスワードが8文字以上とかにならなくちゃいけない7文字になった

7文字になったらえらいになるよ8文字だったら ok になるよあとはメールアドレスがまあなんとか@なんとかっていう形式になってなかったらえらいになるようになってたらえらいにならないよとかいろいろな確認したいパターンってあると思うんですけど極端なことを言ってしまうかE2Eでテストしたいのって何かしら

条件に合わないものが出てきたらそれを登録ボタンを押しても登録できませんっていう画面に映るちゃんと全部条件入れたら登録の画面もしくはこれで登録しますよろしいですかっていう確認の画面に遷移するっていう2パターンでいいと思っていいですねうまくできなかったらできませんよできたら

ok で次に住むっていうにパターンを確認せ ばってじゃあ api の確認はどうなるのって言ったら8パスワードが8うまく8も文字そこまでを文字 いかなかった場合といった場合みたいなやつとかメールアドレスが形式揃わなかった 場合揃ったパンとか8後は ユーザー id がすでにあるかどうか熱

リクエスト投げてレスポンスがどう書いているのところはAPIで確認すればいいしそれがユニットになったらユニットレベルになったらじゃあ今度はパスワードが7文字をユニットレベルでやった時に文字数余計満たしてないですっていうものが書いてくるかみたいなちょっとAPIというユニットはいろいろと

役割分担また考えるところあるかもしれないですけど極端なことを言うと言い継ぎはさっき言ったエラーの画面に行くか次に進むかっていうその繊維のところを気にするみたいな割り切りも全然ありかなとうんうんうんうん

今のお話でフロント側のE2Eとユニットテストあとはバックエンド側のユニットテストの話が出たかなと思ってて例えばなんですけどフロント側でバリデーションかけてないとしてAPI側にパスワード7文字で送ってで

で文字数足んないよってレスポンスが来たからフロント側で文字数足んないよっていう表示を画面に遷移するっていうのをイメージしてお話しするんですけどその時にAPIからはユーザー向けじゃない英語のエラーコードとかエラーメッセージが返ってきてUI側では日本語に直して出すっていうロジックが入ってた時って

それでも言い継いではそれってメールアドレス重複してた時とは全く別の処理が走るとはいえページ内だけ見れればいいから例えばメールアドレス被ってたっていう時の異常異常じゃない純正常の

E2Eだけ書くGUIのユニットではメール重複パスワードの文字列単内っていうユニットテスト書くAPIはAPIでパスワードの文字数とかのロジックのテストを書くっていう何でしょうねロジックがある場所にそれぞれユニットテストを書いてE2Eは本当にページ遷移だけ

っていう整理になるってことですねそれもやり方の一つですかね他にもそこは言い継い他にもやった方がいい今言ってたやつでレスポンスがエラーコードで返ってきてそれはちゃんと言い継いで見た方がいいよっていう風にチームで合意するんだったらそこも言い継いでやればいいと思うんですけど例えば今言ってたエラーコードが返ってきての話だとしたら

やり方はいろいろあると思うんですけどもうテストを始めるときのインプットとしてそういうエラーコードが返ってくるレスポンスがあったらっていうところから始めるっていうのはあれだと思ってそういうレスポンスが返ってきたときの画面表示を確認するっていう要は実際にパスワードが7文字とかっていう入力の操作の

自動テストから書き始めないというもうそういう7文字とかがもうリクエストとして投げられたっていう前提テストのスタート地点が7文字のやつが投げられた時に返ってくるであろうレスポンス

から始めて自動テストその時にエラーコードが返ってきているのをフロント側で変換しているんだとしたらそれがちゃんと変換で出るよねっていうところだけに絞る実際に7文字の入力の操作を自動テストのスクリプトとして書かないっていう方がいいと今言った話で今ページ遷移ってお話されてましたけど

フロントの例えばフォームの周りにパスワードだったら編集中に赤く新たに出すみたいなのもあるじゃないですかそういう場合でもページ遷移がないから文字が出るよねっていうことだけをユニットテストで担保するっていう考え方もあるというかそれで許されるんだったらそっちの方がいいっていうなるほどそうですよねE2Eの自動テストで一番

つらいのはさっきそもそも物件給付のデータがなかったらみたいな話もしましたけれども本当は確認したいのは7文字とかでパスワードの入力文字数が短い

時にちゃんとエラーとして返ってくるかっていうところを確認したいのにそもそも入力操作のところの例えばフォームが仕様変更で変わってそもそも入力できないみたいなことになった時7文字かどうかっていう文字数のところを見たいのにそれ以外のところでテストがエラーになってしまう準備段階の部分が

でエラーっていうのはある気にしたくないんですよねそこの準備段階の入力するところでのエラーのところはおそらくさっき言ったページセインのやつで言ったら全部ちゃんと正常に入力してちゃんとうまくいきましたねっていうハッピーパスとかと呼ばれたりしますけどそっちでもエラーとして出ているはずでそっちでエラーで出てるからちゃんと入力

全部一連の入力してちゃんと通すっていうところができてないよねっていうところでエラーとして出てそのテストを選ぶとして出てほしいわけでパスワードが基準8文字に足していなかったりしたときに赤い文字で返ってくるかどうかのテストではエラーにしてほしくないんですうん

っていう風に切り分けるために前準備のところは操作っていうのを1Eのスクリプトでやるんじゃなくてそういうのがレスポンスとして返ってきましたっていう前提でやりたいっていうのがそういうところになる

なんか恥ずかしながらちょっと勘違いしたところがあってテストについてテストピラミッドとか見ると下からピラミッドがあるじゃないですかユニットインテグレーションE2あれって重なってるじゃないですかなので確認観点が若干被ってるようなイメージをしてたんですよ

めっちゃ細かく見るユニットとそのユニットの項目を一部含んでふわっと見るインテグレーションでさらにその上のE2Eみたいなイメージをしてたんですけどやっぱり今日の話通して聞いてるとそのE2Eとインテグレーションとかユニットとか各テストレイヤーで見るべきところはちゃんと分けましょうねっていうそうですねそう思いますところがすごい

学びすごい学びですちなみにそれをうまく分けるのってどうすればいいかっていうとテストって普通に開発と同じようにテストプロセスっていうのが存在していますと

テストプロセスって何かっていうとよくテストをやるって言った時ってテストを実行するのとその手前にデータを用意する2段階ぐらいしかイメージしてなかったりすると思うんですけどテスト準備とテスト実行ぐらいにしかイメージされないことが多いんですけどそうではなくて例えば

テストプロセスの一例としてテスト分析っていうものがあってテスト設計っていうものがあってテスト実装っていうものがあってテスト実行っていう分析設計実装実行っていう分け方の考え方がありますそうした時に自動テストってテスト実行の自動化

だしその時に作るテストスクリプトってテスト実装のアクティビティなんですどうテストのスクリプトを書くかこれが手動テストだったらテスト手順を書くっていうのがテスト実装にあたるわけですけど大事なのはそれよりも手前の部分でテスト分析とテスト設計っていうのが重要で

テスト分析っていうのは何をテストするのかっていうのを明らかにするっていうテスト設計っていうのはじゃあそのためにはどういうパターンを用意した方がいいのかっていうのを明らかにするのがテスト設計さっき一番最初に大宮駅の徒歩5分の時に何を気にしてますかって質問しましたけどそれってテスト分析なんですよその時に検索条件

検索条件として投げたら期待したデータが返ってくるかどうかなのかそれが画面として適切に表示されるかどうかみたいな区切り方ができるよって言ったのはテスト分析をした結果こういうのも気になるよねこういうのも気になるよねって出てきたものに対して

じゃあこの気になる内容はE2Eでやった方がいいよねこの気になる内容はAPIでやった方がいいよねってそのテスト分析何をテストするのかっていうレベルでいろいろ分けられるはずでそれがテスト実装テストスクリプトとして書いているものを見てこのうちどれをE2EでやろうどれをAPIでやろうって言っても迷うわけですよなんでかっていうとそれがどういう意図を持って

このテストスクリプトを書いているかが分からないからテストスクリプトプログラムコードだけを見てもなので最初にやるのはそのテストスクリプトを見てAPIとかユニットテストにするのはどれがいいかっていうことよりもそもそもこのE2Eのテストって何をテストしようとしたんだっけっていうのを洗い出すところの方が大事かなと思いますうん

その結果例えばさっきの大宮駅の徒歩5分とか9分とか10分以内だったらちゃんと10分以内みたいな徒歩何分っていうところがきちんとできるかどうか検索条件ができるかどうかっていうテスト分析があってじゃあ次テスト設計になった時は10分以内って言ってるから10分は入るけれども11分は入らないよねっていうパターンとして

境界値分析とか言われたりしますけれどもパターンとして10分11分のところは見たいよねぐらいのことを考えるそこはまだ具体的なテストスクリプトとしてどうこうは考えていなくてこの何分っていうところに気にするとそういうパターンがあるよねぐらいにしか考えていなくて実際にテストスクリプトとしてそれがテストするにはどういう風なスクリプトを書けばいいか手動テストだったらテスト手順を書けばいいか

っていう風になっていくこういうテストプロセスを分けることっていうのが重要かなと思っていますちなみにQAエンジニアじゃない僕からするとTDDとかで進めることが多くて

TDDとかで言うと最初のテストを書いている本当にワンシナリオを書いているときがいわゆるテスト分析に当たるってことなんですかねそうですねワンシナリオを書くのもそうだしそれこそT和田さんとかが書いているTDDの最近の翻訳の記事とかにあるんですけれどもTDDってレッドグリーンリファクタリングのループがよく

そこの部分のみが注目されがちなんですけれどもTDDをやっていると

発表であったりとかを見るとレッドグリーンリファクタリングの前にトゥードゥリストを書くっていうステップがあってこれってどういうことをまずテストすればいいんだろうっていうトゥードゥのリストを書くところがあるんですよねその部分がテスト分析に近いかなとちょっとついでにの話になっちゃうんですけど今TDDの話が出てきたのでついでに話すとその

そのトゥードゥリストもそうだしあとさっきのテストプロセスのもう一ついいところがあってテスト分析何をテストするのかっていう話って例えば新機能があったときにまだプログラム一文字も書いてなくてもそこを考えられるはずなんですよTDDのトゥードゥリストと似たようなところではあるんですけれども例えば仮に物件検索をこれから作る

一切まだプログラムコード一行も書いてないっていうところから始めたとしてもじゃあ大宮駅の徒歩5分とかデザイン的なやつがあったときにじゃあその徒歩5分っていう徒歩5分とか9分とかっていうのがあったときに例えば10分以内ってあったら10分は引っかかるけど10分引っかかんないよねっていうところは確認しとこうねっていうのをあらかじめ話せるわけですよ

あらかじめ話すっていうのはすごい良くて何がいいかっていうとそれで10分以内ってなったら10分のところは出るけど11分は引っかかんないかどうかをテストしようって思いながら実装するとどうなるかっていうとまずそこでバグが出ないわけですよ

そうですねよっぽどなことがなければそうですよねこういう話したなとか例えば家賃の話で言えば加減と上限があって加減が5万円で上限が3万円ってなったら逆だからそれはそもそも偉いに履くよねみたいなことそこ多分テストしといた方がいいよねっていうと

そういう議論をしたなってイメージしながら実装するのでそこまずバグが出ないバグが出ないってことはバグチケットを起用してとかあと実装した

例えば数日後とか1週間後とかにテストしてそれがバグ出た時にあれそもそもこれどんな実装してたっけって思い出すのもコストだし修正するのももちろんコストだし修正し終わったらもう1回テストしなくちゃいけないのもコストだしそれで修正してテストすると

出暮れで他の場所もバグってるかもしれないから他の場所もテストしなくちゃいけないっていうのもコストがしっていういっぱいコストがあるのはそもそもここテストしとかなきゃねっていうテスト分析しとくことでそもそもバグが出にくくなるんですよそれがすごいいいところかなとちょっと自動テストとかE2Eのテストとは話がちょっとずれますけど

余談にはなっちゃうんですけどそういう意味でもテスト分析テストプロセスを意識して何をテストするのかっていうテスト分析を考えるっていうのはすごい良いことかなと思っていますなるほどテストプロセスっていうのを今までちょっと意識したことない意識したことないというか知らなかったのでフレームワークが知れてなんかすごい良いなと思って最初に言ってた期待値っていうのが

何を求めるかみたいなところがテスト分析かで当てはめていって無駄なテストをしなくて済むというかそこのプロセスが全然なかったなというのでとりあえず僕今の現場でテストしようしようと

書くみたいな最初は大体新しい機能が入ってきてテスト仕様書書くってなった時にこういう機能増えたなこういう機能増えたなだからこうやってテストしなきゃなってテスト仕様書を書いていってるのでそれが若干テスト分析っちゃ分析かなとも思いつつその前段で他のチームの人たちとこういうテスト必要だよねみたいな要件定義じゃないですけどそういう分析をすると品質上がって無駄なテストとかしなくて

意識というか認識があっていいなっていうのをすごい感じましたねテストプロセスっていうのをちょっと覚えておきますなので自分の今いる現場とか今までもそうだったんですけど自分のQAエンジニアとして入るときは自分のところだとスクラムでやってるんですけれどもスクラムでいうリファインメント

そのチケットを作ってそのチケットの受け入れ基準とか何を持ってこのチケットって完了にすればいいんだろうねっていう話し合いのところにQAエンジニアである自分が結構入っていてこれってこういうことこういうことができればOKなんですよねっていうのを自分から話したりしますこれが何がいいかというと

POとかはこういうことやりたいんだよっていう話が話として出てくるんですよ開発者はこれをどうすれば実現できるかっていうのを注目しがちだと思ってそれはすごいいいことだと思う開発者の特性としていいことだと思いますただ例えばここの関数でこういうふうなことをすればいいっていうふうに書いていたとき

自分がそこでQAとして入ってよくそこで質問するのはなるほどプログラムとしてそこの部分変えようと思っているのは分かったけれどもじゃあそれってアプリ上の振る舞いだとどう変化するのどう変化したらいいのっていうような聞き方をするんですねそうするとアプリ上だとこういう風に変わるはずでみたいな話になったらじゃあそこを確認すればいいですねっていう話になるしそういう話をしてると開発してる人も

アプリの振る舞いを意識しながら開発してくれるのでそこの部分のバグは本当に少なくなるなるほど会話でTDD BDDしてるみたいなそうですまさにBDDの感じこうやって動くんですねって言ってそれに向かって開発してもらうと

意識したことないですねこの機能本当にいるかなばっかり考えてますね大事だと思います結構あと自分の方であるのは開発者に説明とかしてもらった時にそれちょっとよく分からなかったのでもう一度話してくれますっていう話を振ると開発者の人は一言一個同じことを言うのはあんまりなくて

ちょっと詳しく説明してくれるんですそうするとこれってパターンAっていうのがあってパターンBっていうのがあってパターンCっていうのもあるんだけどパターンCのこと忘れてたわって開発者自身が気づいてくれることとかっていうのもあってそういうのが気づいていたりとかあとはパターンAあってBあってCあってDあってEあってこういうのもあってみたいにいろいろ説明をしてもらったりするとQAである自分としては

今回達成したいことってこういうことですよねそれを達成するためにこんなに複雑なことをやりますめんどくさくないですかみたいなことも語りかけますそうするとそもそも実装する機能がシンプルになってくる実装する機能がシンプルになればもちろん開発も工数少なくて済むし

QAとしてもテストするのも少なくて済むのでみんな幸せになるそういう語りかけをするし今言った一連の話って全部プログラムとか一文字も書いてない段階から話せるっていうのを結構してますなるほど思い当たる節ありますね

聞かれるとちょっと詳しく話してこんなパターンあるなって思いつくのよくありますね確かにそれを後から気づくとかテストを実施した段階で初めて気づくだとめっちゃ手戻りかかるので一昔前今はちょっと違うと思うんですけど一昔前の実際の研究データだと要件定義とかで仮に

見つかってここうまくできないじゃんって見つかって例えば1時間で修正できるものがあったとしたらそれが実際に開発し終わった実際のテストをした段階で気づいて修正するとだいたいコストが20倍20時間かかるって言われていますそこのコストは時間数だけではなくて

他にもあるのかもしれないコストとしてはあるかもしれないですけどそれがリリースした後にお客さんに渡してお客さんがこんなんじゃ使えないよね直してよって言った場合は要件定義で気づいた場合の200倍かかるって言われてるんですよ

とんでもないそのコストって単に修正の時間が200時間になるだけではなくてもしかしたらこんな機能を作り上がってみたいな感じでお客さんからの信用失墜のコストとか

そういうのも含めて200倍かかると言われていて最近それこそアジャイルとかになって早いサイクルでとかっていう風になってそもそも200倍かかるっていうのがもう少しコストは削減されてて30倍とかって言われてるんですけどとにかく後ろになればなるほどコストはかかるのでそれをできるだけ早めにさっき言ったプログラム一文字も書いてない時点で

自分は予告するって言ったりするんですけどこういうのテストするからねみたいなそういう活動ができるといいしシンプルになることでテストケースも少なくなるしテストケースが少なくなるとさっき言ってた前回の放送で言ってたようなそもそもテストケースがいっぱいあってみたいな状況をなくせるって思っていますなるほどありがとうございますなんかしばしば

ひも付けたあれですけどQAとデベロップが分かれてると多分TDDみたいな何でしょうねテストケース最低限のテストケースを意識しつつ実装していくっていうのは多分難しくてそれをいかに実現していくか役割が分かれている中で実現していくかっていうところがロッコリさんがおっしゃってたコミュニケーションで

なんでしょうねシナリオを抑えつつやっていくっていう進め方なんだなとすごい聞いてて思いましたし自分でテスト書く人はやっぱり僕はテストケースから書くことを強く推し進めていきたいずっと言ってますね個人的にはTDDずっと押してますねBDDもありますけどあんまりそうですねTDDで書くことが多いかな時間がまあまあ行きつつあるのでだんだんクローズしていこうかなと思うんですが

最後にまとめで僕がさらっとまとめて補足をお願いしていいですか不動産検索サイトにおいてフロントエンドとバックエンド複雑な検索機能がついているような機能で徒歩何分で物件検索しますというようなテストをどこで何を書くかでいうとE2Eはあくまで

表示部分を担保すべき何が実際に出てくるかという確認をするのではなくて検索した結果物件が出てくるよねぐらいの確認ですねしかもスナップショットを撮るわけでもなくこういう情報が含まれているものが出てますっていうのを本当に見た目の部分をE2Eで担保してそれ以外の徒歩10分は出るけど徒歩11分は出ないよね

ロジックが書いてあるところ多分API側ですねとかで出したりとかあとは何でしょうねたまたま徒歩5分以内だったら太字にするみたいなフロントで操作する何かがあったとしたらそこは多分フロントのユニットテストで担保するみたいな形でE2Eをできるだけ減らしていくっていうのが自動テスト作っていく上で非常に重要だよねというお話をブロコリさんに今日していただいたと思ってます

があってますあっていると思いますはいありがとうございますめちゃくちゃ勉強になりましたもう明日明日も絶賛書くんですけどe2imユニットテストも早速取り入れて我が物顔でコードレビューでコメントしておこうと思いますありがとうございました最後にブロッコリーさん宣伝とかあればじゃんじゃんお願いします自分の方から2つ

まず一つがこのラジオと同じような感じでポッドキャストを自分の所属している10Xでもやっています10X.FMというのでやっています今時点での最新のエピソードは自分がホストとなってゲストの方を真似てQAの話を

してもらうというようなQAベアっていうのを企画しているのが多分最新のエピソードにはなっていますTXFMもしよろしければそちらも聞いていただけると幸いですあともう一つ宣伝としてあるのが最初自己紹介のときにちらっと話しましたけれども消費者さんが主催しているコードジンアカデミーというのがあります消費者さん自身は多分デベロッパーズサミットとかっていうイベントをやったりしている

出版社であるんですけれどもそこの所有者さんが主催しているコード人アカデミーという講座がありますその中で自分も講座を持っていまして開発を加速するためのテスト講座というものをやっています自分が実際に講座の題材というかその構成とかから考えて作っている講座があります大体

3ヶ月に1回ぐらいのペースでやっているんですけれども次回が12月18日にあります のでもしよろしければそちらも参加してもらえると嬉しいですまああのこの開発を加速するためのテスト講座っていうそのなんだエッセンス的な話は今日の話の中で結構出てきているかなと思うんですけれどもそういう話をもう少しいろいろな具体例を交えたりとかワークショップ形式でやっていくのでそちらもぜひ

興味のある方は参加していただければと思います宣伝としては以上ですありがとうございますぜひテストめちゃくちゃ詳しいブロッコリーさんにいろいろ聞けたりもしくは別話でいろいろお話ししているということなのでTEN-Xさんのポッドキャストなんて結構な回数いってますよね実は我々より先輩なのであと思ってるんですけど

いや今100回ぐらいだから多分結構前からやられてた気がしてて今118回ですね企業ポッドキャストで118回やってるとこ他にあるのかっていう

ところですけどぜひ聞いてくださいブロッコリーさん改めまして本日ありがとうございましたありがとうございましたまたぜひテストは大好きなんでまたぜひお越しくださいでは締めますハッシュタグひまじんプログラマーでSNSでのXFeedback募集してますのでテストに関する悩みとかあるあるネタありましたらぜひXFeedbackシェアお願いします

お願いしますポッドキャストの説明欄からGoogleフォームでお便り感想要望質問何でもお待ちしてますので

ブロッコリーさんへのメッセージは全部転送させていただきますのでお願いいたしますお願いしますジャンジャンお願いします各種ポッドキャストプラットフォームのフォロー高評価もお待ちしてますNXさんのポッドキャストも合わせてチェック高評価フォローお願いしますでは3人目の野菜の人のプロポーゼルをお待ちしながらも本日楽しかったですありがとうございましたありがとうございましたまた次回

バイバイ